On Mon, 2009-01-12 at 09:47 -0800, Younes Manton wrote: > 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 higher level just passes down an additional flag which allows the backend to legally make the decision. > 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 wasn't intending to suggest that. > 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 is what I was trying to say - sorry for the confusion. The winsys will do the work, but only when told it's ok by a higher level. Keith ------------------------------------------------------------------------------ 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
