glshim
glshim copied to clipboard
lunixbochs
glesv2
I have found that glshim normally sits on top of glesv1. This is a problem because a lot of extensions (like framebuffer object or shader programs) are not always possible depending on the driver.
I wanted to know the plan for glshim to switch to glesv2.
Does it mean we have to generate a shader program? Does it mean we need to write a routine to combine our own glsl with a user's glsl to make this work correctly?
Outright switching to GLESv2 isn't correct, because GLESv2 cannot do all of the operations available in GLESv1 (like glLogicOp). GLESv2 will also be slower on some platforms, which is a pretty big problem on already-limited mobile devices.
At some point I'm going to create a backend module system, where I serialize rendering down to simple blocks representing all of the features in GL and implement those in GLES v1, v2, or v3, passthrough to actual OpenGL, or with a fast software renderer (which I've been working on for a while). This also means I can mix and match backends where it makes sense, so stuff like GL_SELECT can just always be provided by the software renderer.
These are some examples of previous wrappers supporting ES2 as a backend:
- https://code.google.com/p/gl-wes-v2/
- https://github.com/p3/regal
I'm not aware of any programs that use both shaders and the fixed pipeline even in OpenGL land. I can't imagine that would work well.
Programs targeting only the fixed function pipeline will need a very simple ES2 shader written to handle lighting, fog, etc (which is the whole premise of gl-wes-v2, but I don't want to steal any code from there because it has an incompatible license).
Programs targeting the shader pipeline will need a shader recompiler to port them from the desktop shader API, and will additionally need some missing features emulated. Regal is currently the best reference on this.
If it's actually slower on some platforms, then it would be best then to target both. Maybe some platforms can support glLogicOp quickly for glesv1 but I imagine many others would be very slow for this operation. I would have no real issues with just stubbing it out, but it's a good reason to choose glesv1 or glesv2.
There are applications which use shaders combined with the fixed function pipeline which is why I am suggesting we need a way to patch shaders together.
Do you have an example of an app using both shaders and fixed function pipeline?
Xash3D for example. Engine uses GL1.3, but custom renderers may use shader extensions.
GLES2 works faster on many devices. For example, tegra has worse performance in GLES1. It is possible to implement GLES2, but most functions must be implemented with shaders. It's very difficult
Okay, so glUseProgram(0) will mean "emulate fixed pipeline". I'll think about the design a bit. I'm also not sure what happens when you load vertices while a shader is active. I think oldschool shaders still let you call glBegin() and such.
I have found that glUseProgram(0) will be as without a shader. If you do use a program, then it is combined with the fixed function pipeline. So for example, you can still use GL_BLEND, or glRotate etc, and these are applied to the results of the shader.
On 10/13/15, Ryan Hileman [email protected] wrote:
Okay, so glUseProgram(0) will mean "emulate fixed pipeline". I'll think about the design a bit. I'm also not sure what happens when you load vertices while a shader is active. I think oldschool shaders still let you call glBegin() and such.
Reply to this email directly or view it on GitHub: https://github.com/lunixbochs/glshim/issues/142#issuecomment-147769557
if glRotate() happens after the vertex shader, then we just need to append relevant matrix ops to the output of each vertex shader.
GL_BLEND is supported in ES 2.x so we probably don't need to mess with that for now.