On 07/09/18 13:36, Timothy Arceri wrote:
On 07/09/18 11:49, Ian Romanick wrote:
On 09/06/2018 06:08 PM, Timothy Arceri wrote:
On 07/09/18 11:00, Ian Romanick wrote:
On 09/06/2018 03:24 PM, Timothy Arceri wrote:
On 07/09/18 06:18, Ian Romanick wrote:
So... this game that requires at least OpenGL 3.2 (by virtue of using
core profile) is checking for an OpenGL 1.4 feature?  That makes me a
little sad.

Its a little odd it creates both a compat profile then some core profile
threads. It also looks for GL_EXT_framebuffer_object in core but I'm
still checking if this is ok to enable, as far as I can tell it should
be ok because our core implementation shares objects which is what the
EXT implementation is supposed to do. Maybe you could comment of this as
it seems you were the last one to edit that code.

I'm not 100% sure it's valid to expose either of these extensions on
core profile.  Pretty much all of these old extensions explicitly allow
behavior that was deprecated and removed (e.g., user generated object
names).  EXT_fbo had some differences with ARB_fbo, so there are some of
the entrypoints that aren't shared.  I don't know whether or not any of
those functions check (or need to check) the extra core profile
restrictions.

The spec covers the differences in:

Dependencies on ARB_framebuffer_object and OpenGL 3.0

It seems like it should be fine to me. The only issue is it says ARB
should share across contexts but currently it does. However this is an
existing bug.


Do the closed-source drivers expose these legacy extensions in core
profile?  This seems like a mess...

Yes the Nvidia driver does I haven't checked AMD but I assume it does or
the game would have failed to launch there.

Boo.  This patch is grudgingly

Reviewed-by: Ian Romanick <[email protected]>

Apologies I need to send a v2 of this.

Buried inside _mesa_handle_bind_buffer_gen() it seems the aliasing works because of assumptions that the ARB functions will never be called in core.


Meh nevermind. After checking Nvidia they do indeed just alias the functions so the assumptions that buffer objects wont be generated for user defined names are fine I was confusing myself with the EXT_fbo stuff about no alias being allowed. This patch is fine as is.



On 09/05/2018 08:45 PM, Timothy Arceri wrote:
This extension is required by "Wolfenstein: The Old Blood".

All the functions are just alias of the core functions so
there should be nothing more to do.
---
    src/mesa/main/extensions_table.h | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/extensions_table.h
b/src/mesa/main/extensions_table.h
index f3727cdb08d..09bf923bd0e 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -182,7 +182,7 @@ EXT(ARB_vertex_array_bgra                   ,
EXT_vertex_array_bgra
    EXT(ARB_vertex_array_object                 ,
dummy_true                             , GLL, GLC,  x ,  x , 2006)
    EXT(ARB_vertex_attrib_64bit                 ,
ARB_vertex_attrib_64bit                ,  32, GLC,  x ,  x , 2010)
    EXT(ARB_vertex_attrib_binding               ,
dummy_true                             , GLL, GLC,  x ,  x , 2012)
-EXT(ARB_vertex_buffer_object                ,
dummy_true                             , GLL,  x ,  x ,  x , 2003)
+EXT(ARB_vertex_buffer_object                ,
dummy_true                             , GLL, GLC,  x ,  x , 2003)
    EXT(ARB_vertex_program                      ,
ARB_vertex_program                     , GLL,  x ,  x ,  x , 2002)
    EXT(ARB_vertex_shader                       ,
ARB_vertex_shader                      , GLL, GLC,  x ,  x , 2002)
    EXT(ARB_vertex_type_10f_11f_11f_rev         ,
ARB_vertex_type_10f_11f_11f_rev        , GLL, GLC,  x ,  x , 2013)


_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to