Almost all of our BO export paths were already properly marked the BO as
external and added it to the handle table. Most export use-cases go
through a prime fd or flink where we have a brw_bo export helper that
does the right thing. The one missing one happens when you call
queryImage and ask for __DRI_IMAGE_ATTRIB_HANDLE. We just grabbed the
gem handle out of the BO (because it's really easy to do that) and
handed it off to the client; what could go wrong? As it turns out, this
path is used by basically every compositor that wants to turn around and
call drmModeAddFB2 on it so it can hand it off to display. The result,
as of
4b1e70cc57d7ff5f465544644b2180dee1490cee, is that we no longer set
MOCS_PTE on those surfaces and the kernel's attempts to disable caching
fail and we scanout gets corruption.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103759
Fixes: 4b1e70cc57d7ff5f465544644b2180dee1490cee
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
return 0;
}
+uint32_t
+brw_bo_export_gem_handle(struct brw_bo *bo)
+{
+ brw_bo_make_external(bo);
+
+ return bo->gem_handle;
+}
+
int
brw_bo_flink(struct brw_bo *bo, uint32_t *name)
{
struct brw_bo *brw_bo_gem_create_from_prime(struct brw_bufmgr *bufmgr,
int prime_fd);
+uint32_t brw_bo_export_gem_handle(struct brw_bo *bo);
+
int brw_reg_read(struct brw_bufmgr *bufmgr, uint32_t offset,
uint64_t *result);
*value = image->pitch;
return true;
case __DRI_IMAGE_ATTRIB_HANDLE:
- *value = image->bo->gem_handle;
+ *value = brw_bo_export_gem_handle(image->bo);
return true;
case __DRI_IMAGE_ATTRIB_NAME:
return !brw_bo_flink(image->bo, (uint32_t *) value);