<div class="gmail_quote">On Mon, Jan 31, 2011 at 9:17 PM, José Fonseca <<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote: > On 31.01.2011 19:46, Marek Olšák wrote: </div><div class="im">> > With this manager, the drivers don't have to deal with user buffers when they are bound as vertex buffers. They only get real hardware buffers. > > Please do *not* take away my user buffers and put user vertex arrays at the mercy of a state tracker ! > In the DrawArrays case I usually use util/translate and interleave them letting it write directly into my command buffer for immediate mode vertex data submission. </div>Christoph, Is there any reason for not wanting to the same optimization for non-user buffers? If the buffers are small and used only once, wouldn't you still want to write them directly into the command buffer? Because eliminating user buffers does not imply eliminating these optimization opportunities -- the driver can still know how big a buffer is, and the state tracker can set a flag such as PIPE_USAGE_ONCE to help the pipe driver figure out this is a fire and forget buffer. Perhaps we can have a PIPE_CAP for distinguishing the drivers that can inline small buffers, vs those who can and prefer them batched up in big vbos. And lets not forget the user arrays are a deprecated feature of GL. Applications will have to create a vbo even if all they wanna do is a draw a textured quad, therefore small vbos are worthwhile to optimize regardless. I'm not saying we must get rid of user buffers now, but I can't help feeling that it is odd that while recent versions of GL/DX APIs are eliminating index/vertex buffers in user memory, Gallium is optimizing for them... </blockquote><div> </div></div>FWIW, the fact that something is deprecated in GL shouldn't concern us. Some deprecated features are only removed in the Core profile, which is very rarely used by developers. The GL4/Compatibility profile still contains everything, no features have been eliminated there. And we have to implement both the profiles, because people use both. The deprecation mechanism in OpenGL really doesn't make our lives easier at all. Whether user buffers should be exposed via the Gallium interface is an entirely different question though. I see my effort as moving towards eventually eliminating user buffers by simplifying the logic around them. The section "1)" in my previous email is about eliminating any user-buffer-related code from drivers (though this step is optional). The section "2)" talks about removing some user-buffer-specific code from st/mesa, optimizing things in the process. I can see nothing wrong with those. ;) Marek