[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Public WebGL] ESSL -> HLSL -> cso, do we really need to do this?

It is possible to generate D3D bytecode directly. There is even an assembler for this. Unfortunately this will not longer work as soon Angle would switch over to D3D 10+. To ensure that you don't mess with the bytecode anymore the compiled shaders are signed by the HLSL compiler and the runtime checks this.
I have written a number of HLSL shaders and hardly run in compiler issues. In most cases problems were caused by me doing things wrong in the HLSL code. So I am not sure how many of the problems you noticed are caused by the ESSL to HLSL step.
Anyway to ease the problem with the long compile times at least a bit it might be a good idea to add some kind of shader cache. This way it would a least faster the second time a user visit a page. Anything beyond this would most likely requires a custom shader container that can beside the pure GLSL code contains multiple binary shaders for different targets.  

Von: owner-public_webgl@khronos.org [owner-public_webgl@khronos.org] im Auftrag von Florian Bösch [pyalot@gmail.com]
Gesendet: Samstag, 2. Februar 2013 11:04
An: public webgl
Betreff: [Public WebGL] ESSL -> HLSL -> cso, do we really need to do this?

So as you might know if you go trough Angle targeting D3D the following things happen:

1. ESSL is parsed Angle
2. various bug-fixes and optimizations/unrollments are applied and it's output to HLSL
3. HLSL is parsed by the Direct3D compiler, various optimizations are applied, again
4. cso (direct3d intermediary bytecode) is produced
5. cso is translated to native GPU code

Stages 3 -> 4 have been traditionally a weak spot. It takes most OpenGL drivers a couple milliseconds to parse and translate GLSL. But it usually takes Direct3D hundreds of milliseconds (sometimes dozens of seconds in pathological cases) to translate HLSL to cso.

However Stages 4 -> 5 have been a traditional strength of Direct3D (troughout the development history of games on windows, game developers have always strived to precompile all their shaders to cso for shipping).

Now one odd thing I have observed in the last 1-2 years is that the same shader in GLSL and HLSL, on the same GPU on the same operating system, would run fine on OpenGL (and compile as fast as anything else). But when going trough HLSL odd things would happen (strange register errors, extremely long compile times, completely broken rendering etc.).

Trough discussing this with various people I think that it mainly stems from the HLSL -> cso compiler beeing... lackluster. It's slow and it often tries to optimize something erroneously which ends up being to clever by half.

So since I don't have a lot of experience with Direct3D, I'm wondering about the following: Can't we just skip HLSL and compile ESSL -> cso directly? It is after all a machine/driver independent fast intermediary bytecode format.