[Piglit] [Mesa-dev] DSA for core profile only? (was Re: [PATCH 2/2] arb_direct_state_access: New test for GetCompressedTextureImage.)

[Kenneth Graunke]

On Tuesday, February 17, 2015 02:25:05 PM Ian Romanick wrote:
> (Cross posting to mesa-dev.)
> 
> On 02/17/2015 01:54 PM, Ilia Mirkin wrote:
> > On Tue, Feb 17, 2015 at 4:45 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> >> On Tue, Feb 17, 2015 at 4:34 PM, Ian Romanick <idr at freedesktop.org> wrote:
> >>> "Dependencies
> >>>
> >>>     OpenGL 2.0 is required."
> >>>
> >>> This means Mesa will need a flag for the extension because there are
> >>> pre-2.0 drivers.  Every DSA function will need to check the flag and
> >>> possibly generate GL_INVALID_OPERATION.
> >>>
> >>> If we only support core profile (and always enable it in core profile),
> >>> the functions won't even be put in the dispatch table for non-core.  No
> >>> flag, and no checks in the functions.
> >>>
> >>> So, the $64,000.00 question is: Do we care to support DSA on the few
> >>> cards that can do 2.0 but not 3.1?
> >>
> >> Here's a view of some of the hardware that's stuck in GL2-land... not
> >> exhaustive:
> >>
> >> http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html#p=compat
> >>
> >> So that's basically pre-gen6 intel, NV4x (GeForce 6000 / 7000 series),
> >> AMD/ATI r300-r500, and the Adreno gpu's. (And presumably VC4.) Click
> >> around the diff mesa versions, I don't have every hw for every mesa
> >> version.
> >>
> >> What's the downside of enabling this in GL1.x drivers BTW? e.g. nv3x
> >> won't report GL2 (in Mesa) due to NPOT, and all the GeForce <= 4
> >> series due to lack of... features. Not that I really care either way,
> >> but just want to make sure there's a reason for it.
> 
> There are a large number of functions added for features that only exist
> in 2.0 and later (all the shader related functions, all the occlusion
> query related functions, etc.).
> 
> In addition, a bunch of the functions have slightly different behavior
> between core and compatibility profile.  For example:
> 
>         void VertexArrayElementBuffer(uint vaobj, uint buffer);
> 
>     <vaobj> is
>       [compatibility profile:
>        zero, indicating the default vertex array object, or]
>     the name of the vertex array object, and <buffer> is zero or the name of
>     the buffer object. If <buffer> is zero, any existing element array
>     buffer binding to <vaobj> is removed.
>     Errors
> 
>     An INVALID_OPERATION error is generated by VertexArrayElementBuffer if
>     <vaobj> is not
>       [compatibility profile: zero or]
>     the name of an existing vertex array object.
> 
> Not only would we have to implement the different compatibility
> behavior, but we'd also have to implement tests for it.
> 
> > Oh, and an additional thought, if we make it core profile-only, then
> > it will not be available in compat profile on any hardware, even the
> > latest. I think people are far from done using compat contexts, and
> > this would unnecessarily restrict the software that can make use of
> > this extension.
> 
> Generally "newer" applications already require some 3.1+ feature, so
> they're either running on core profile or not running on Mesa already.
> The last time I surveyed applications on Steam, which I realize is very
> specific subset of applications, there were basically two kinds of
> applications.
> 
> 1. Games that were basically OpenGL 1.x or 2.x with a tiny set of extra
> features that were absolutely necessary for some effect.  These games
> use no "convenience" features... even ones that would improve performance.
> 
> 2. Games by vendors that are really mad that we don't already support
> 4.5.  They use everything modern, and they never look back.
> 
> The folks in group 1 aren't going to use DSA, and the folks in group 2
> mourned the loss of compatibility profile ages ago.
> 
> So... is there are 3rd group, and do we care enough to do the work
> necessary to support them?

I'm inclined to simply support it for core profile, at least until an
application developer requests compatibility support.  It's part of
OpenGL 4.5 - I suspect people using legacy GL aren't going to want to
use features that are so new they've barely even shipped on the major
proprietary drivers.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20150218/473d0dcc/attachment.sig>