Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse: > 2011/3/29 r6144 <rainy6144@xxxxxxxxx>: > > å 2011-03-29äç 10:22 -0400ïJerome Glisseåéï > > > >> Killer solution would be to have no mapping and a decent > >> upload/download ioctl that can take userpage. > > > > Doesn't this sound like GEM's read/write interface implemented by e.g. > > the i915 driver? But if I understand correctly, a mmap-like interface > > should still be necessary if we want to implement e.g. glMapBuffer() > > without extra copying. > > > > r6144 > > > > > glMapBuffer should not be use, it's really not a good way to do stuff. > Anyway the extra copy might be unavoidable given that sometime the > front/back might either be in unmappable vram or either have memory > layout that is not the one specify at buffer creation (this is very > common when using tiling for instance). So even considering MapBuffer > or a like function i believe it's a lot better to not allow buffer > mapping in userspace but provide upload/download hooks that can use > userpage to avoid as much as possible extra copy. > > Cheers, > Jerome > Wouldn't this give us a performance penalty for short lived resources like vbo's which are located in GART memory? Mmap allows us to write directly to this drm controlled portion of sysram. With a copy based implementation we would have to allocate the buffer in sysram just to copy it over to another portion of sysram which seems a little insane to me, but I'm not an expert here. -- Lucas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
