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

[Ian Romanick]

(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?

>   -ilia