search for: busy_placements

...ent *pl = &nvbo->placement; + uint32_t flags = TTM_PL_MASK_CACHING | + (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0); + + pl->placement = nvbo->placements; + set_placement_list(nvbo->placements, &pl->num_placement, + type, flags); + + pl->busy_placement = nvbo->busy_placements; + set_placement_list(nvbo->busy_placements, &pl->num_busy_placement, + type | busy, flags); } int @@ -199,7 +206,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t memtype) { struct drm_nouveau_private *dev_priv = nouveau_bdev(nvbo->bo.bdev); struct ttm_buffer_object...

...uveau_bo.h > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.h > @@ -9,6 +9,7 @@ struct nouveau_bo { > struct ttm_buffer_object bo; > struct ttm_placement placement; > u32 valid_domains; > + u32 valid_caching; > u32 placements[3]; > u32 busy_placements[3]; > struct ttm_bo_kmap_obj kmap; > diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h > index 2a5769f..4948eee2 100644 > --- a/include/uapi/drm/nouveau_drm.h > +++ b/include/uapi/drm/nouveau_drm.h > @@ -36,6 +36,7 @@ > #define NOUVEAU_GEM_TI...

qxl surfaces (used for framebuffers and gem objects) can live in both VRAM and PRIV ttm domains. Update placement setup to include both. Put PRIV first in the list so it is preferred, so VRAM will have more room for objects which must be allocated there. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_object.c | 4 ++-- 1 file changed, 2 insertions(+), 2

qxl surfaces (used for framebuffers and gem objects) can live in both VRAM and PRIV ttm domains. Update placement setup to include both. Put PRIV first in the list so it is preferred, so VRAM will have more room for objects which must be allocated there. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_object.c | 4 +++- 1 file changed, 3 insertions(+), 1

qxl uses small buffer objects for qxl commands. Allocate them top-down to reduce fragmentation. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_object.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c index 927ab917b834..ad336c98a0cf 100644 ---

.../nouveau_bo.h index 653dbbb..2ecf8b7 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.h +++ b/drivers/gpu/drm/nouveau/nouveau_bo.h @@ -9,6 +9,7 @@ struct nouveau_bo { struct ttm_buffer_object bo; struct ttm_placement placement; u32 valid_domains; + u32 valid_caching; u32 placements[3]; u32 busy_placements[3]; struct ttm_bo_kmap_obj kmap; diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h index 2a5769f..4948eee2 100644 --- a/include/uapi/drm/nouveau_drm.h +++ b/include/uapi/drm/nouveau_drm.h @@ -36,6 +36,7 @@ #define NOUVEAU_GEM_TILE_32BPP 0x00000002 #define NOUVEA...

Hi, > This misses the call to drm_gem_vram_placement(), where > drm_gem_vram_push_to_system() enforces placement in system memory. Ah, missed that detail. > We > could build a common implementation out of both interfaces, but that > would obfuscate the code IMHO. I'd just leave it as it is. Ok. > >> +struct drm_gem_vram_object { > >> + /* Supported

This is the first set of patches to make Nouveau work on Tegra. Those are only the obvious correctness fixes, a lot of optimization work remains to be done, but at least it's enough to get accel working and let the machine survive a piglit run. A new BO flag is introduced to allow userspace to hint the kernel about possible optimizations. Lucas Stach (6): drm/ttm: recognize ARM arch in

Create virtio_gpu_object_params, use that to pass object parameters to virtio_gpu_object_create. This is just the first step, followup patches will add more parameters to the struct. The plan is to use the struct for all object parameters. Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is unused and always false. Also drop "pinned" parameter. virtio-gpu

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code.

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v5:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code.

. On Wed, Jun 19, 2019 at 11:08 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > virtio-gpu basically needs a sg_table for the bo, to tell the host where > the backing pages for the object are. So the gem shmem helpers are a > perfect fit. Some drm_gem_object_funcs need thin wrappers to update the > host state, but otherwise the helpers handle everything just fine. >

Hi Thomas. Some minor things and some bikeshedding too. One general^Wbikeshedding thing - unint32_t is used in many places. And then s64 in one place. Seems like two concepts are mixed. Maybe be consistent and use u32, s32 everywhere? I did not read the code carefully enough to understand it. I cannot give a r-b or a-b - as I feel I need to understand it to do so. Sam On Mon, Apr 29, 2019 at

Hi Thomas. Some minor things and some bikeshedding too. One general^Wbikeshedding thing - unint32_t is used in many places. And then s64 in one place. Seems like two concepts are mixed. Maybe be consistent and use u32, s32 everywhere? I did not read the code carefully enough to understand it. I cannot give a r-b or a-b - as I feel I need to understand it to do so. Sam On Mon, Apr 29, 2019 at

It has been a couple of months since v4 - apologies for this. v4 has not received many comments, but this version addresses them and makes a new attempt at pushing the critical bit for GK20A and Nouveau on ARM in general. As a reminder, this series addresses the memory coherency issue that we are seeing on ARM platforms. Contrary to x86 which invalidates the PCI caches whenever a write is made by