- From: Ralph Thomas <ralpht@gmail.com>
- Date: Wed, 14 Dec 2011 15:44:14 -0800
- To: "Gregg Tavares (wrk)" <gman@google.com>
- Cc: Adam Barth <w3c@adambarth.com>, James Robinson <jamesr@google.com>, Chris Marrin <cmarrin@apple.com>, Vincent Hardy <vhardy@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>
I think you could still branch on anything that wasn't derived from a texture sample of HTML content -- branching on uniforms/fragment position/other GL state wouldn't change runtime based on texture contents. If you remove VTF then you only have the limitations in the fragment shader. Out of curiosity, how would a dependent texture lookup change runtime based on contents? Is it faster to sample edge texels when using GL_LINEAR or something like that? Internally pow has a conditional branch on a value derived from the second argument, which in your example would be tainted, so that should generate an error -- but a good point that the internal functions would need to be considered too. And yes, this doesn't address any DOS concerns. You'd need something else to cancel a frame if it's taking too long to rasterize. Ralph On Wed, Dec 14, 2011 at 1:07 AM, Gregg Tavares (wrk) <gman@google.com> wrote: > Off the top of my head you'd have to remove "if", "while" and "?" and > dependent texture lookups (sampling 1 texture based of sampling of another > texture). You might be able to keep 'for' with its current WebGL limits of > only a constant integer input since with no "if" there would be no way to > break out early. > > I think you'd probably be able to write many useful shaders with those > limitations > > No dependent texture lookups kind of sucks but probably not needed for most > uses of CSS shaders. > > I think the confusion about limited GLSL not being useful is the DOS issue > vs the timing issue. You can't limit shaders in any useful way and solve the > DOS issue. In fact you don't even need shaders for the DOS issue. Just a > large mesh. But for the timing issue, removing those 4 features might solve > it. > > That assumes none of the math changes time based on input like for example > > float v = pow(1, texture2D(someTex, someUV).r * 10000.0); > > > > > On Mon, Dec 12, 2011 at 11:10 PM, Adam Barth <w3c@adambarth.com> wrote: >> >> On Mon, Dec 12, 2011 at 9:56 PM, Ralph Thomas <ralpht@gmail.com> wrote: >> > On the topic of "constant time GLSL", I was thinking that any value >> > derived from a texture sample read from web content would be >> > "poisoned" so it could not be used for conditionals and that the >> > poison would propagate to any dependent value in the program. You >> > could assign a poisoned value to gl_FragColor (obviously) but could >> > not branch or loop on it. >> > >> > This would still let you write blur kernels, do lighting effects and >> > warp texture coordinates, but you wouldn't be able to use any part of >> > the texture as a lookup table, for example. >> >> In principle, this approach can work. To be fully correct, the >> program should be restricted to performing constant-time operations on >> tainted values. However, just avoiding branches is probably a good >> place to start. >> >> > It should be possible to add a pass to ANGLE to poison values read >> > from texture and those dependent on them and then validate that no >> > selections or loops depend on a poisoned value. I think that a program >> > that passed this test would then always execute in the same time for a >> > given set of vertices regardless of the contents of any bound texture. >> > >> > I believe CSS Shaders would still be useful with these limitations >> > added to GLSL -- what did I miss? >> >> I would encourage you to implement a prototype of this scheme to see >> whether you can still write useful shaders. Some OpenGL experts I >> talked with earlier claimed that this approach would be too >> restrictive, but that's something that's easy to experiment with. >> >> Adam > >
Received on Thursday, 15 December 2011 04:56:04 UTC