On Sun, 2010-01-31 at 04:31 -0800, Keith Whitwell wrote: > Userbuffers get hit in the traditional GL vertex array paths, which is pretty > common usage. I've been thinking about buffers and uploads a bit recently, > and I'm pretty sure we can do better than the current mechanisms. > > Also, it makes sense to make the BUFFER_USAGE_ flags stronger - I think it's > been a grey area whether they are hints or not. I've been (rightly or > wrongly) thinking of them as guarantees for a while, so I certainly won't > argue to keep them as hints. I'm pretty sure the SVGA driver treats them as > guarantees, for instance, and uses malloc for constant buffers.
Actually SVGA interprets them as hints. It just uses them to choose whether the initial storage should be in a malloc buffer or hardware buffer. If any buffer (user or not) is bound then a host surface and dma upload will happen automatically. This all happens in svga_buffer_handle(). > ________________________________________ > From: Corbin Simpson [mostawesomed...@gmail.com] > Sent: Saturday, January 30, 2010 4:06 AM > To: Mesa3D-Development > Subject: [Mesa3d-dev] Grab bag of random questions (whoo) > > 4) user_buffer_create doesn't appear to see an incredible amount of > usage. user_buffer_create is exposed by the APIs to the application. It is used as often as the apps use it. My understanding is that old GL and D3D apps use it a lot. > Would it be too horrible to make *all* buffer allocations > delayed, transparently? You mean, make the state tracker's responsibility to create a hardware pipe buffer and copy the contents when the buffer is about to be bound? What about software renderers or software vertex processing fallbacks done by the draw module? They would incur unnecessary extra copy, as they can read the user memory directly. Furthermore Thomas devised at some time the possibility to create DRM buffers from user memory on demand, so even real hardware could potentially do similar things. In summary, yes it will be possible, but it would damage > I ask because apparently the PIPE_BUFFER_USAGE > flags (PIXEL, CONSTANT, etc.) are "optimization hints" and not > guarantees, which is very annoying since I need to prevent > constantbufs from ever becoming BO-backed... That's why pipe_screen::buffer_create should be != pipe_winsys::buffer_create and pipe_winsys should die. The winsys should worry only about DRM BOs. The pipe driver should implement user buffers internally, do whatever it needs to be done, and never pass them to the winsys. Jose ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
