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

["Kornmann, Ralf" <rkornmann@ea.com>]

The significant relaxed limits in SM 4+ might help as the compilation is now more straight forward. I am not sure if Angle currently uses SM 2 or 3. 2 was always a problem as the limits were so low that the compiler needs to use any possible trick to get the HLSL code in these.

 

While I like to see an update (it would open the way for more extensions that would allow AAA graphics with WebGL) I am not sure how many systems would lost their WebGL support this way. With the concerns about the limited time that people can spend on WebGL development task I am not sure if going forward with two versions of Angle can be done.

 

 

---

Von: Brandon Jones [bajones@google.com]
Gesendet: Samstag, 2. Februar 2013 17:33
An: Florian Bösch
Cc: Kornmann, Ralf; public webgl
Betreff: Re: [Public WebGL] ESSL -> HLSL -> cso, do we really need to do this?

I've never looked into the D3D10+ compile times much, but have they improved over D3D9 at all? Ralf mentioned that a straight-to-bytecode approach would stop working once we upgrade, but if the compiler is better it may be a non-issue.

Do we have any stats on that?

On Saturday, February 2, 2013, Florian Bösch wrote:

On Sat, Feb 2, 2013 at 11:37 AM, Kornmann, Ralf <rkornmann@ea.com> wrote:

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.

Arghl

 

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.

At least 3 of my WebGL demos have run into such issues, where a compile would take anything from 10 seconds to several minutes. The reaction of browsers to this problem is different. Chrome usually kills your context after about 11 seconds, and Firefox usually lets things run, but after about 15 seconds asks you if you want to kill the page since the JS is unresponsive.

 

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. 

There is a shader cache. But that doesn't really help that much because if you need to compile a serious amount of shaders (A typical high quality production has anything between 300 to 1000 different shaders) or if you run into a bunch of pathological cases (exceedingly likely with a large number of shaders) then the result is that a user never gets to the page. It'll lose context, or it'll ask him to kill the page, or he just leaves out of boredom to wait for stuff to happen. The typical 5ms or so compile time of GLSL via OpenGL is still way long. But the typical 100ms to 500ms compile time for GLSL via D3D pushes this beyond the point of breaking.