Shadergen Initial Linux Screenshot...

[Svartalf]

3DLabs a long while back made this nifty little tool called ShaderGen that allowed you to turn the fixed functionality knobs
(Such as fog, etc...) and to see what it would do via the Vertex/Fragment shader path and to generate GLSL code that
corresponded to the requested fixed functionality as specified in the program. This can be useful for someone not used
to thinking in terms of GLSL to get up and mostly going with ES 2.0 code and get results.

I've resurrected this program from the last known version with source code available and got the start of it working on Linux right
now. It's still NOT ready for primetime yet (Needs QUITE a bit of cleanup...even with wxWidgets as it's UI, it's a mess that only
VC++ produced workable code on...) and I need to backport it to something like CMake so it'll be properly portable before putting
a "4.0" version up on something like Berlios. However, since I got it mostly working right now, I thought a screen shot and an
initial announcement was in order...

[edit] Grrr... Let's try to get this in a format people can SEE... [/edit]

http://www.earlconsult.com/ShaderGen/LinuxShaderGen1.jpg

 

[Arialia]

Good

do you know some tutorials on Shader ? in french or english ( i prefer french of course )

if i understand this program is a generator of code for Shader , isn't it ?

 

[sindbad]

That's very cool. I expect it will help with porting older gl software.

 

[Xmas]

That's very cool. I expect it will help with porting older gl software.

If you want to port older software it's easier to use OpenGL ES 1.1.

IMO if you want to learn a shader-based API like OpenGL ES 2.0 it's better to learn to write shaders from scratch. Once you've understood the very basics of GLSL it's easier to write a fragment shader than to set up a texture environment. And the OpenGL fixed function lighting model is quite limited so you probably don't want to use it anyway.

ShaderGen may be convenient if you just want to add some tiny bit to fixed function processing, but it may also lead to people never trying to understand and improve the generated code because "it works".

 

[Svartalf]

do you know some tutorials on Shader ? in french or english ( i prefer french of course )

I only know of the reference books right at the moment- and they're in English, unfortunately...

QUOTE

if i understand this program is a generator of code for Shader , isn't it ?



It helps generate shaders to replicate fixed functionality path stuff.

 

[Svartalf]

If you want to port older software it's easier to use OpenGL ES 1.1.

Until I hear otherwise, I'm presuming that we're only going to have 2.0 at our disposal. This is based on the fact that 1.1 brings
intrinsically nothing to the table that 2.0 doesn't bring (save fixed functionality- which can be implemented as shaders) and eats
up space on the firmware dragging an intrinsically duplicated driver layer onto the firmware. If we're getting it, this is less of an
issue and I can just skip this and move on to ShaderDesigner's move to cross-platformness from the GPLed Windows version
of the tool.

QUOTE

IMO if you want to learn a shader-based API like OpenGL ES 2.0 it's better to learn to write shaders from scratch. Once you've understood the very basics of GLSL it's easier to write a fragment shader than to set up a texture environment. And the OpenGL fixed function lighting model is quite limited so you probably don't want to use it anyway.



Depends on whether or not you have 1.1 or 2.0 only and have a game that needs to be moved from OpenGL 1.5 or before.
If you've got ES 1.1, it's a moot point and you're right (which is why I made the comment that I did- ShaderDesigner's a MUCH
more important tool for that sort of thing, being a full-on IDE for GLSL shader development)- if you've got only 2.0, you kind of
need to do this (because understanding that limited model kind of requires poring over the old standards docs) or something
like it. Let's see what we find out here on what is/isn't available. If 1.1 is going to be there in the mix, I'll just shift gears.

QUOTE

ShaderGen may be convenient if you just want to add some tiny bit to fixed function processing, but it may also lead to people never trying to understand and improve the generated code because "it works".



You're going to get that anyhow. Doesn't matter if you have the tool or not. Someone's going to find a snippet of stuff and cut
and paste the functionality they're looking for without understanding it. The bulk of the people out there aren't going to be like you
or I where we want to get the best we can get out of the system- they only care about "it works". And not making something
like this available will actually lower the amount of things getting done by people if we've only got 2.0- because they're not going
to want to learn yet another programming language to get what they want done, simple as GLSL is.

 

[Xmas]

Unless TI or the Pandora team do something amazingly stupid the Pandora should come with OpenGL ES 1.1 drivers. The main thing this brings to the table is compatibility with existing OpenGL ES 1.1 applications, and I'm sure with 256 MiB of NAND flash the size of the driver isn't an issue.

 

[Svartalf]

Unless TI or the Pandora team do something amazingly stupid the Pandora should come with OpenGL ES 1.1 drivers. The main thing this brings to the table is compatibility with existing OpenGL ES 1.1 applications, and I'm sure with 256 MiB of NAND flash the size of the driver isn't an issue.

ES 1.1 drivers means that you'll be dragging along the 2.0 support PLUS a wrapper that transparently does the same thing that the app I'm porting does- there's no fixed functionality paths on this GPU; it's all unified shader based.

 

[Arialia]

Unless TI or the Pandora team do something amazingly stupid the Pandora should come with OpenGL ES 1.1 drivers. The main thing this brings to the table is compatibility with existing OpenGL ES 1.1 applications, and I'm sure with 256 MiB of NAND flash the size of the driver isn't an issue.

ES 1.1 drivers means that you'll be dragging along the 2.0 support PLUS a wrapper that transparently does the same thing that the app I'm porting does- there's no fixed functionality paths on this GPU; it's all unified shader based.

Why a wrapper ?

for graphics card if have support for Direct3D and OpenGL we have two drivers without wrapper i think and both application of Opengl and DirectX could work fine at same time.

I think it will same for support of OpenGL ES 1..1 / OpenGL ES 2.0 for OMAP , no ?

 

[Xmas]

ES 1.1 drivers means that you'll be dragging along the 2.0 support PLUS a wrapper that transparently does the same thing that the app I'm porting does- there's no fixed functionality paths on this GPU; it's all unified shader based.

I am perfectly aware of what the hardware does. That doesn't change anything I wrote. The OpenGL ES 1.1 driver (which isn't a wrapper) doesn't take up much space but it provides compatibility for existing OpenGL ES 1.x applications.

 

[Svartalf]

Why a wrapper ?

Wrapper is probably not the right term, but it's the closest thing to explain it. The fixed functionality that the older 1.1 spec specifies does not exist in the chip in any semblance of the concept. Much like most modern GPUs, it's all shader based internally. When you're coding for OpenGL, you're coding to an API. Same goes for Direct3D from DirectX. You're not coding to a driver, which is a much, much more primitive interface- you're coding to a specific low-level 3D API.

When you code to the ES 1.1 API, you're coding to the fixed functionality half of the OpenGL spec for all intents and purposes. The MBX that was used in the previous OMAP2 series is a fixed functionality card.

When you code for ES 2.0, you're coding to a shader programmable interface, using the same vertex, texture, etc. interfaces and adjusting the results via shader programming. You don't typically have a default shader like you do with 1.1, but you end up specifying one easily enough, if you read the OpenGL 2.0 stuff in something like my former supervisor's book, the OpenGL Superbible, describes for things.

The bulk of the code (setting up triangles, textures, etc.) is the same between both API's. When you provide an ES 1.1 interface for a chip like the one in our OMAP chip, you have to provide some sort of "wrapper" layer that translates the settings you specify into shaders that get ran against the 2.0 engine pieces not exposed. Shaders like the ones this app produces. Now, "wrapper" is really not the right word, in the case of the ImgTec API layer, it's reimplementing everything as a seamless whole, never exposing the shader interface, but using the shader compiler engine pieces in the background to accomplish the fixed functionality operations.

Now, it remains to be seen whether TI or Pandora licenses the 1.1 API layer piece from ImgTec (Yes, there IS a license for that that has to be arranged...)- which is why I state what I state. Rather than presuming that 1.1 is going to be available, and rather than constrain the games I'm porting over to the Pandora to just 1.1's abilities, I'm going the slightly extra step of doing 2.0 stuff. This tool helps in doing this for those that are unfamiliar with reading the OpenGL spec documents (Ugh... You don't wanna... Trust me... ) and translating the stuff there into shaders.

Xmas... If you don't like this, fine. Nobody's making you use it. I'm not insisting that people use it.
I'm doing it to expand the tool space for those that're interested have it available to shave a step off for the initial pass at the port before tweaking it upwards, which the ES 2.0 spec allows for.

 

[argor]

@ Svartalf
Xmas may nou something abot the drives as he works for ImgTec

 

[Svartalf]

@ Svartalf
Xmas may nou something abot the drives as he works for ImgTec

Fair enough. I just know what I was exposed to over at AMD when I worked for 'em. If they're going to provide BOTH API's, then this is fine- like I said...