[Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

Marek Olšák maraeo at gmail.com
Mon Jan 31 12:54:47 PST 2011

On Mon, Jan 31, 2011 at 9:17 PM, José Fonseca <jfonseca at vmware.com> wrote:

> On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote:
> > On 31.01.2011 19:46, Marek Olšák wrote:
> > > 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.
> 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...

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. ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110131/c7495c66/attachment.htm>

More information about the mesa-dev mailing list