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 <imir...@alum.mit.edu> wrote: > >> On Tue, Feb 17, 2015 at 4:34 PM, Ian Romanick <i...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
