On Aug 13, 2015 12:33 PM, "Marek Olšák" <mar...@gmail.com> wrote: > > On Wed, Aug 12, 2015 at 11:23 PM, Thomas Helland > <thomashellan...@gmail.com> wrote: > > 2015-08-12 18:56 GMT+02:00 Kenneth Graunke <kenn...@whitecape.org>: > >> On Wednesday, August 12, 2015 06:32:50 PM Thomas Helland wrote: > >>> 2015-08-12 17:48 GMT+02:00 Ilia Mirkin <imir...@alum.mit.edu>: > >>> > On Tue, Aug 11, 2015 at 1:48 PM, Thomas Helland > >>> > <thomashellan...@gmail.com> wrote: > >>> >> Signed-off-by: Thomas Helland <thomashellan...@gmail.com> > >>> >> --- > >>> >> This adds a section for the extensions nvidia has chosen to > >>> >> call the "GL ARB 2015 Extensions" unveiled at SIGGRAPH. > >>> > > >>> > There are ARB extensions released every year (or more often, not > >>> > sure)... we don't track all ARB extensions. Why are these so special > >>> > vs e.g. the ones released along with GL 4.5 but that weren't included > >>> > in the spec? Or any of the other ones... > >>> > > >>> > >>> Well. They're not really special I guess. This just follows from the > >>> discussion that went down on irc between me, glennk, fredrikh, ++. > >>> > >>> > Should GL3.txt just become extension-implementation-status.txt and > >>> > list all non-vendor-specific extensions? So far it has stuck to actual > >>> > GL versions (and more recently GLES). > >>> > > >>> > >>> We can keep it GL / GLES versions only. Or we can extend it to a > >>> extension-implementation-status.txt thing. Or we can split it > >>> into two different files. I really don't care to much either way. > >>> > >>> If we end up adding these extensions to the file then a rename > >>> and adding other ARB's is probably the way to go. There are > >>> positive and negative sides to both approaches, and its not > >>> my call to decide how, and if, we want this. It gives a nice overview > >>> but at the same time it has PR- and "needs-to-be-kept-updated"- > >>> implications that we may not want. I'm all ears for suggestions. > >>> > >>> -Thomas > >> > >> I like the idea of adding an "ARB Extensions" section and listing all > >> the ARB extensions that aren't part of a particular GL version - simply > >> in addition to the existing content, rather than reorganizing it. > >> > >> GL3.txt has been a misnomer for a while, but I don't care whether we > >> rename it or not; it doesn't bother me. > >> > >> --Ken > > > > I've assembled a list of extensions I *think* are not demanded by > > any current openGL specs, but I may have missed some. > > (I find it weird that I VAO's in any of the specs, for example) > > I could add all of them to a separate section to track them, > > or I can leave it as is and drop this patch. Up to you guys. > > > > 2. GLX_ARB_get_proc_address > > 4. WGL_ARB_buffer_region > > 8. WGL_ARB_extensions_string > > 9. WGL_ARB_pixel_format > > 10. WGL_ARB_make_current_read > > 11. WGL_ARB_pbuffer > > 15. GL_ARB_vertex_blend > > 16. GL_ARB_matrix_palette > > 20. WGL_ARB_render_texture > > 24. GL_ARB_shadow_ambient > > 36. GL_ARB_fragment_program_shadow > > All extensions above are considered old crap. Also, WGL extensions? Seriously? >
There's a revised version of the patch with only 2012 and onwards extensions listed. I sent it in reply to the last patch, but should've probably nested it in this discussion. Sorry about that. I really need to set up a mail client that allows me to see the message headers. > I personally think adding a list of non-core extensions to docs is > useless and will only distract people. > That is a completely valid point. I'm not gonna push to get this merged, I was just proposing a solution after some irc'ing about the newly released extensions > Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
