gl_generator: implement fallbacks based on aliases #204
Conversation
These aliases are already present in the XML, so we might as well use them! As OpenGL evolves and is extended, it frequently occurs that a vendor introduces an extension, giving a function a name like `glFooNV` or `glFooAMD`. Then, it gets proposed to the ARB and is renamed `glFooEXT`. Then, this extension gets standardized and is placed in the core profile and is once again renamed to its final name, `glFoo`. For Mesa, they implement various extensions and then finally support an OpenGL version once all extensions have been implemented. Many OpenGL features can be implemented entirely in the driver, or on most hardware even if the hardware doesn't support enough features for a specific OpenGL version. So you get situations where older GPUs only expose OpenGL 2.1, but implement almost every extension that is present in OpenGL 3.3. So, when `glFoo` can't be loaded but it has known aliases, try also loading those aliases before giving up. Closes brendanzab#150
|
The code looks good (r+), however I'm wondering if it's really that useful. For example searching for |
|
Maybe a test could be added, with a closure that gives null for a real function and a real function pointer for an alias. |
|
@tomaka it's useful at the very least for gfx-rs/gfx#231 |
|
@tomaka I suspect the DSA stuff is just a bug with the xml |
|
@tomaka I'm not sure how to differentiate the real function and an alias for the test, what exactly do you mean? (Note that at least on mesa, the EXT and regular function have the same address since they are the same) |
|
Something like this: extern fn dummy() {}
let loader = |name| -> *const libc::c_void {
match name {
"glMyFunction" => 0,
"glMyFunctionEXT" => dummy,
_ => panic!()
}
};
gl::MyFunction::load_with(loader);
gl::MyFunction(); // should call `dummy` |
|
Oh, duh! Will add :) |
| for (k, v) in b.into_iter() { | ||
| match a.entry(k) { | ||
| Occupied(mut ent) => { ent.get_mut().extend(v.into_iter()); }, | ||
| Vacant(ent) => { ent.set(v); } |
There was a problem hiding this comment.
I love the new entry API exactly for this :)
|
Ok, this looks good to me. I am just not following the back and forth between you guys. Are you talking about redoing some of the internal logic, or exposing something else in the API? Also, could you add some documentation to the README saying that this is going on behind the scenes? |
|
@bjz Revised the docs to say what you suggested |
|
Oh, it would also be nice if aliases were written in the doccomments of each function. But that doesn't have to be part of this PR. |
|
@tomaka adding... |
|
Alright, |
?
gl_generator: implement fallbacks based on aliases
These aliases are already present in the XML, so we might as well use them! As
OpenGL evolves and is extended, it frequently occurs that a vendor introduces
an extension, giving a function a name like
glFooNVorglFooAMD. Then, itgets proposed to the ARB and is renamed
glFooEXT. Then, this extension getsstandardized and is placed in the core profile and is once again renamed to
its final name,
glFoo.For Mesa, they implement various extensions and then finally support an OpenGL
version once all extensions have been implemented. Many OpenGL features can be
implemented entirely in the driver, or on most hardware even if the hardware
doesn't support enough features for a specific OpenGL version. So you get
situations where older GPUs only expose OpenGL 2.1, but implement almost every
extension that is present in OpenGL 3.3.
So, when
glFoocan't be loaded but it has known aliases, try also loadingthose aliases before giving up.
Closes #150