On Tuesday 04 March 2014, 02:08:58, Marek Olšák wrote: > Could you please do this without changing u_upload_mgr? You can still > use u_upload_alloc to allocate buffer memory in the driver and the map > buffer read/write flags are not important with persistent coherent > buffer mappings anyway.
Since 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 we allocate CPU -> GPU streaming buffers (i. e. those with PIPE_USAGE_STREAM) in VRAM. We should therefore set buffer.usage to PIPE_USAGE_STAGING in u_upload_alloc_buffer when we use u_upload_mgr for downloads - otherwise we won't get any performance improvements. Would it now be OK to change u_upload_mgr or do you have a better proposal? Ole > Marek > > On Mon, Mar 3, 2014 at 9:29 PM, Niels Ole Salscheider > > <niels_...@salscheider-online.de> wrote: > > Using the DMA engine for buffer downloads vastly improves performance. > > This is because reads from VRAM by the CPU are slow because of the high > > latency of the PCIe bus. > > > > The first patch allows u_upload_mgr to be used for downloads, too. The > > second patch then uses u_upload_mgr in the radeon driver for downloads. > > I considered to rename u_upload_mgr to u_transfer_mgr since it might be > > confusing that an "upload manager" can be used for downloads. But then > > again we also have "transfers" so that u_transfer_mgr might also be > > confusing. Thus, I decided not to rename it for now. > > > > Without these patches, the buffer_bandwidth benchmark from uCLbench gives > > me: > > > > ./buffer_bandwidth --size=20000000 --iterations=100 > > # device 0: AMD BARTS // type gpu (192 MB global memory, 64 KB constant > > memory,> > > 32 KB local memory) > > > > 1/1 direct 20000000 Bytes 759.29 MB/s(HD) 17.13 MB/s(DD) > > > > 14.61 MB/s(DH) > > > > With these paches, the read performance is much better: > > > > ./buffer_bandwidth --size=20000000 --iterations=100 > > # device 0: AMD BARTS // type gpu (192 MB global memory, 64 KB constant > > memory,> > > 32 KB local memory) > > > > 1/1 direct 20000000 Bytes 759.90 MB/s(HD) 613.49 MB/s(DD) > > > > 1841.07 MB/s(DH) > > > > Judging by these numbers, it might even make sense to use the DMA engine > > for larger buffer downloads... > > > > Niels Ole Salscheider (2): > > util/u_upload_mgr: Allow to also use it for downloads > > radeon: Use transfer manager for buffer downloads > > > > src/gallium/auxiliary/hud/hud_context.c | 3 +- > > src/gallium/auxiliary/util/u_blitter.c | 3 +- > > src/gallium/auxiliary/util/u_upload_mgr.c | 49 +++++++++++----- > > src/gallium/auxiliary/util/u_upload_mgr.h | 13 ++++- > > src/gallium/auxiliary/util/u_vbuf.c | 3 +- > > src/gallium/auxiliary/vl/vl_compositor.c | 3 +- > > src/gallium/drivers/ilo/ilo_context.c | 3 +- > > src/gallium/drivers/r300/r300_context.c | 3 +- > > src/gallium/drivers/radeon/r600_buffer_common.c | 78 > > +++++++++++++++++++------ src/gallium/drivers/radeon/r600_pipe_common.c > > | 14 ++++- > > src/gallium/drivers/radeon/r600_pipe_common.h | 1 + > > src/mesa/state_tracker/st_context.c | 9 ++- > > 12 files changed, 136 insertions(+), 46 deletions(-) > > > > -- > > 1.9.0 > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
