search for: writecombined

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 +++++++++++++++++- 1 file changed, 17 insertions(+),

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 +++++++++++++++++- 1 file changed, 17 insertions(+),

...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 intercon...

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 > &g...

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> > --- >

...,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, Luca...

Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > 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

Hi On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian K?nig wrote: > > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > > > 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 > > >

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

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

On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian K?nig wrote: > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > > 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

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

Hi Christian On 15.10.20 16:08, Christian K?nig wrote: > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: >> 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

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