OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

gbm/dri: Flush after unmap

Browse Source 
Drivers may queue dma operations on the context at unmap time so we need
to flush to make sure the data gets to the bo. Ideally the application
would take care of this, but since there appears to be no exported gbm
flush functionality we need to explicitly flush at unmap time.

This fixes a problem where kmscube on vmwgfx in rgba textured mode would
render using an uninitialized texture rather than the intended
rgba pattern.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This commit is contained in:
Thomas Hellstrom
2017-03-28 21:32:22 +02:00
parent 3df410069a
commit ba8df2286a
1 changed files with 8 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/gbm/backends/dri/gbm_dri.c
View File

@@ -253,7 +253,7 @@ struct dri_extension_match {
};
static struct dri_extension_match dri_core_extensions[] = {
{ __DRI2_FLUSH, 1, offsetof(struct gbm_dri_device, flush) },
{ __DRI2_FLUSH, 4, offsetof(struct gbm_dri_device, flush) },
{ __DRI_IMAGE, 1, offsetof(struct gbm_dri_device, image) },
{ __DRI2_FENCE, 1, offsetof(struct gbm_dri_device, fence), 1 },
{ __DRI2_INTEROP, 1, offsetof(struct gbm_dri_device, interop), 1 },
@@ -1239,6 +1239,13 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
return;
dri->image->unmapImage(dri->context, bo->image, map_data);
/*
* Not all DRI drivers use direct maps. They may queue up DMA operations
* on the mapping context. Since there is no explicit gbm flush
* mechanism, we need to flush here.
*/
dri->flush->flush_with_flags(dri->context, NULL, __DRI2_FLUSH_CONTEXT, 0);
}