PDA

View Full Version : Sort out the shader issues



Stainless
09-12-2011, 05:48 AM
You NEED to specify that target devices WILL support source code shaders.

If you don't, just don't bother doing a new version.

The current standard, isn't.

The spec basically says ...

you may or may not have source code shaders
you may or may not have binary shaders
you may or may not have oes extensions for shaders

How are you supposed to support all devices with this as a standard?

Either... sell out to a mobile phone company and become <insert company name here>gl instead of OpenGL, or do it right and make platform independence important.

This sort of thing is why Java is such a dog. Start out with a platform independant VM then start buggering about with it creating pJava and Midp, and all the rest of the sub species, make it impossible to write code that will work on all platforms and wonder why people stop supporting it.

Gedolo
11-02-2011, 07:14 AM
I agree source code shaders should be mandatory included.

Binary/Compiled shaders are handy for buffering the already done work,
however they are no replacement for the usability/adaptability of source code shaders.

Gedolo
02-15-2012, 12:26 PM
Source code shaders should be mandatory.
Fix this Khronos, seriously, this isn't even funny any more!!

cob
02-16-2012, 07:28 PM
Most implementations of OpenGL ES 2 do support loading shaders as source. For example, I do not know of any tablets or phones that support OpenGL ES 2 but do not support source shaders. You are correct that it is very difficult (or impossible) to write portable code using binary shaders!

However, there are implementations of OpenGL ES 2 which run on small embedded systems and are not designed to run general purpose portable programs. These platforms usually run only programs that are written specifically for the platform. Some of these platforms have very limited memory and low powered CPUs. Including a shader compiler on such a system may be impractical. This is the main reason that binary shaders are allowed and that source shader support is not required.

So in general you can assume that source shaders will be supported. This should only be a problem if you need your code to run on pretty obscure systems. Have you run into any systems that do not support source shaders?

-Acorn

sean.ellis
02-17-2012, 02:50 AM
I have one additional observation: Any platform which supports HTML5 with WebGL must have source code shader support, as WebGL does not allow binary shaders.

Gedolo
02-27-2012, 09:42 AM
Most implementations of OpenGL ES 2 do support loading shaders as source. For example, I do not know of any tablets or phones that support OpenGL ES 2 but do not support source shaders. You are correct that it is very difficult (or impossible) to write portable code using binary shaders!

However, there are implementations of OpenGL ES 2 which run on small embedded systems and are not designed to run general purpose portable programs. These platforms usually run only programs that are written specifically for the platform. Some of these platforms have very limited memory and low powered CPUs. Including a shader compiler on such a system may be impractical. This is the main reason that binary shaders are allowed and that source shader support is not required.

So in general you can assume that source shaders will be supported. This should only be a problem if you need your code to run on pretty obscure systems. Have you run into any systems that do not support source shaders?

-Acorn

Those obscure systems do not have a problem with not being able to run arbitrary code from third parties thus also no need for certification or validation seems to me.
Isn't the whole reasons for standards being able to run third party code on a system? Or running code on a third party system without having to test it specifically for that system?

Gedolo
03-02-2012, 07:02 AM
I have an idea.

Let the spec say that you have to have at least or source code shaders or binary shaders and being able to do both is allowed!
(If both are present we need a default for the driver when not specified in application code and programming constructs are not clearing it out. What about when the driver is capable of both and not specified in application code making default choice source code shaders?)

And we need two flags: one for checking if source code shaders are supported and another one for checking if binary shaders are supported.

This way there will be at least one thing supported. Application code can be written with source and binary shaders to be more transferable where necessary. (Just comment out, or some other programming construction for not using that one or use another shader, the binary shaders for the device you're not going to target this time.)