Emulator Issues #6742
closed
Shader Generator API
0%
Description
I've been seriously thinking about and toying with some code to create a API to a shader generator instead our current implementation of just writing straight text that can't get type-checked at all by the compiler. This has been hit multiple times by us where a typo has been in some obscure section of the shader that doesn't get hit very commonly.
My current implementations have been heavily based upon the IRBuilder used by the JITILs, either directly using the IRBuilder that is modified, or a new one that is based off of it. I feel now at this point that there could very well be a better way to go about it than the approach that I have gone with. I'll have at the bottom my current API and what it outputs.
I'm asking here is for someone to come up with a better API or to review the one I've currently got done. I know neobrain has an idea that could very well beat out my current one, so I'd like to hear opinions on this.
Current Test API:
IRBuilder build;
InstLoc uv = build.EmitUniformConst(CVec4, "uv");
build.EmitMainStart();
InstLoc ocol0 = build.EmitVec4Const(1.5, 1.0, 1.0, 1.0);
InstLoc ocol1 = build.EmitVec4Const(1.5, 1.0, 1.0, 1.0);
InstLoc ocolResult = build.EmitAdd(ocol0, ocol1);
InstLoc result = build.EmitAdd(ocolResult, uv);
build.EmitStoreOCol0(result);
build.EmitMainEnd();
printf("code:\n%s\n", WriteCode(&build).c_str());
Outputs:
code:
uniform vec4 uv;
void main() {
gl_FragColor = uv + vec4(3.000000, 2.000000, 2.000000, 2.000000);
}
Updated by NeoBrainX over 10 years ago
A few comments, some of which are just questions, some of which are cosmetic problems but there are a few critical ones, too:
- It's not obvious what InstLoc is supposed to mean. Instruction Location, I guess? Is it a class? How does it look like internally?
- I think a constructor would be nicer to use than "build.EmitVec4Const()". I can see that having a constructor would break OOP design rules though, since you'd have to pass "build" as a constructor parameter...
- What shader variable names will be used when writing the GLSL code? I don't see your code specifying that anywhere, so I can only guess that you'd randomly assign any name. That would make the shader code incredibly hard to read, however.
- How does EmitAdd know which objects ocol0 and ocol1 are pointing to and their properties? It might not be critical for EmitAdd, but other functions might need to know e.g. if it's an int or a float.
- build.EmitAdd could be replaced by defining a "+" operator on ocol0 and ocol1 (those should probable be in some derived class since you wouldn't want to define "+" on InstLoc). Point is, having to use EmitWhatever() for each operation like this will quickly blow up the whole code and make it completely unreadable.
- The API does not support storing branches in the AST. delroth's idea (which I liked) was to build an AST once and parse it for each different configuration, but that's apparently not what you were going for.
I'll write up an example of the API I have in mind when I find some time for that.
Updated by Sonicadvance1 over 10 years ago
Write it down here as well to communicate what was discussed in IRC.
I have realized that it isn't a good idea to use the IRBuilder. The IRBuilder is good for the CPU instruction emulating because it is only dealing with a couple calls per emulated instruction. Having it for writing out a huge bulk of code like the shaders will be ridiculously bloated and cumbersome.
I'll wait for your example before continuing forward.
Updated by Helios about 6 years ago
- Status changed from New to Won't fix
hdkr got eaten by a big green giant and is missed very much.