On Mon, Jan 12, 2009 at 5:04 AM, Keith Whitwell <kei...@vmware.com> wrote: > > > On Sun, 2009-01-11 at 23:00 -0800, Ben Skeggs wrote: >> Module: Mesa >> Branch: gallium-0.2 >> Commit: df266471b1f0eae54cf23fd59a741fa3be9b93df >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=df266471b1f0eae54cf23fd59a741fa3be9b93df >> >> Author: Ben Skeggs <skeg...@gmail.com> >> Date: Mon Jan 12 13:27:13 2009 +1000 >> >> nouveau: return buffer map to something sane. >> >> Sorry, but no, we're not doing this.. Correctness always takes precedence >> over speed. Implement this higher up where you know it's safe to do so, >> and doesn't break other things in the process. > > Agreed, > > This is a general facility that makes sense to add at the gallium API > level -- there's nothing hardware-specific about this idea, so > implementing it within a driver or winsys is putting it at the wrong > level. > > I'd be happy to see a patch that adds something similar at the API > level, eg an extra flag to map() like _DISCARD or similar. > > Keith
I don't see how you can implement that functionality (nicely) at a higher level because there's no way to know if the mapping of a buffer will block or not. The current alternative at a higher level than the winsys is to recreate *every* write-only pipe_buffer that we touch in the state tracker and block+retry later on out-of-memory if we're allocating faster than the GPU is consuming. This is what jrfonseca suggested when I brought up the possibility of adding flags and/or offset+len params to map(), and he pointed me to src/gallium/winsys/drm/intel/common/ws_dri_*.c and src/gallium/auxiliary/pipebuffer/*. I've tried that in various ways and it's a lot more code than the above and is overkill in cases where buffers are not actually busy and can be mapped immediately because we're rendering faster than we're mapping. I'd be happy with a DISCARD flag and/or offset+len params to map, to allow the above to be done safely. (But that still means implementing it in each winsys even though its not hardware specific, but it is winsys and pipe_buffer implementation specific -- in this case it relies on the nouveau BO that backs each pipe_buffer. I don't see how a state tracker calling winsys->map() on a pipe_buffer could hit generic code with the current setup.) ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
