search for: writecombine

virtio-gpu uses cached mappings. shmem helpers use writecombine though. So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak vm_page_prot accordingly. Reported-by: Gurchetan Singh <gurchetansingh at chromium.org> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 18 +++++++++++++++++...

virtio-gpu uses cached mappings. shmem helpers use writecombine though. So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak vm_page_prot accordingly. Reported-by: Gurchetan Singh <gurchetansingh at chromium.org> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 18 +++++++++++++++++...

...org/msg13557.html are up-to-date? Would you mind if I include the relevant patches of yours in the next iteration of this series? > > It does so by doing the necessary manual cache flushes/invalidates on > buffer access, so costs some performance. To avoid this you really want > to get writecombined mappings into the kernel<->userspace interface. > Simply mapping the pushbuf as WC/US has brought a 7% performance > increase in OpenArena when I last tested this. This test was done with > only one PCIe lane, so the perf increase may be even better with a more > adequate interco...

Hi Konrad, Sometime ago i reported this one at boot up: [ 3009.778974] mcelog:16842 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus [ 3009.788570] ------------[ cut here ]------------ [ 3009.798175] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0xa1/0xb0() [ 3009.807966] Hardware name: MS-7640 [ 3009.817677] Modules linked in: [ 3009.827524] Pid:

On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote: > Signed-off-by: Lucas Stach <dev at lynxeye.de> > --- > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++ > drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c > index

...te? Would you mind if I include the relevant patches of > yours in the next iteration of this series? > > > > > It does so by doing the necessary manual cache flushes/invalidates on > > buffer access, so costs some performance. To avoid this you really want > > to get writecombined mappings into the kernel<->userspace interface. > > Simply mapping the pushbuf as WC/US has brought a 7% performance > > increase in OpenArena when I last tested this. This test was done with > > only one PCIe lane, so the perf increase may be even better with a more > &...

Hi Am 10.12.19 um 09:57 schrieb Gerd Hoffmann: > virtio-gpu uses cached mappings. shmem helpers use writecombine though. > So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak > vm_page_prot accordingly. > > Reported-by: Gurchetan Singh <gurchetansingh at chromium.org> > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- > drivers/gpu/drm/virtio/virt...

...,6 +411,10 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible, > > { > > int ret; > > > > + if (nvbo->bo.ttm && nvbo->bo.ttm->caching_state == tt_cached) > > You don't want to do it also for tt_wc ? > No the point of using writecombined memory for BOs is to explicitly avoid the need for this cache sync. An uncached MMIO read from the device should already flush out all writecombining buffers and this read is always happening when submitting a pushbuf. > > + ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt *)nvbo->bo...

...au on ARM series. Most of it never made it upstream, as I lacked the time to work further on this, but it solves the coherency issue from the kernel. It does so by doing the necessary manual cache flushes/invalidates on buffer access, so costs some performance. To avoid this you really want to get writecombined mappings into the kernel<->userspace interface. Simply mapping the pushbuf as WC/US has brought a 7% performance increase in OpenArena when I last tested this. This test was done with only one PCIe lane, so the perf increase may be even better with a more adequate interconnect. Regards, Luc...

...n: > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel > address space. The mapping's address is returned as struct dma_buf_map. > Each function is a simplified version of TTM's existing kmap code. Both > functions respect the memory's location ani/or writecombine flags. > > On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), > two helpers that convert a GEM object into the TTM BO and forward the call > to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object > callbacks. > > v4: > * dro...

...}() map and unmap a TTM BO in > > > kernel address space. The mapping's address is returned as struct > > > dma_buf_map. Each function is a simplified version of TTM's existing > > > kmap code. Both functions respect the memory's location ani/or > > > writecombine flags. > > > > > > On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), > > > two helpers that convert a GEM object into the TTM BO and forward the > > > call to TTM's vmap/vunmap. These helpers can be dropped into the rsp > > &...

The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's location ani/or writecombine flags. On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), two helpers that convert a GEM object into the TTM BO and forward the call to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object callbacks. v4: * drop ttm_kmap_obj_to_dma_buf() in favor o...

The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's location ani/or writecombine flags. On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), two helpers that convert a GEM object into the TTM BO and forward the call to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object callbacks. v5: * use size_t for storing mapping size (Chri...

...functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel > > address space. The mapping's address is returned as struct dma_buf_map. > > Each function is a simplified version of TTM's existing kmap code. Both > > functions respect the memory's location ani/or writecombine flags. > > > > On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), > > two helpers that convert a GEM object into the TTM BO and forward the call > > to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object > > callbacks....

Hi everyone, Here is the second batch of patches to add GK20A support to Nouveau. This time we are adding the actual chip support, and this series brings the driver to a point where a slightly-tweaked Mesa successfully runs shaders and renders triangles on GBM! Many thanks to Thierry Reding and the people on the #nouveau IRC channel for their help without which we would not have reached this

When using Xen Hypervisor, the video goes very slow after module load in console. Xorg does not run. My boot process (in kernel 3.7.1 from elrepo, my default kernel.): 1. Hypervisor is loaded (from here, the screen resolution is 640x480 - text scrolling fast) 2. Kernel is loaded 3. mgag200 module is loaded 4. Screens enter native resolution (from here, the screen resolution is 1280x768 - text

...new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel >> address space. The mapping's address is returned as struct dma_buf_map. >> Each function is a simplified version of TTM's existing kmap code. Both >> functions respect the memory's location ani/or writecombine flags. >> >> On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), >> two helpers that convert a GEM object into the TTM BO and forward the >> call >> to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM >> object >&gt...

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:

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use