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

Re: [Public WebGL] Shader validator issue.



Joe D Williams wrote:
>> support for something like standard_derivitives.
> Is that a math thing, a first connection with OCL?
> Thanks and Best,
> Joe
Not exactly...but it's going to take a bit of explaining...I'll take a
shot at it!

Although each fragment shader program looks like a completely separate
program running in splendid isolation on a little computer inside the
GPU, there are in fact a bunch of fragment shaders running in parallel -
each working on a different pixel of the same triangle. (Technically: on
a different "fragment" - but it's OK to think "pixel".)   Typically,
these processors all run in perfect lock-step -
instruction-by-instruction...and most GPU's have dozens to hundreds of
them running along in parallel.

When you are doing texturing, the shader needs to figure out which
MIPmap level to read - which depends on how much the texture is
magnified or minified.  But each little shader processor only knows the
texture coordinate at the precise location of the screen pixel that it's
processing.   So how does it know whether the texture is being stretched
or squashed?  The answer is that it 'cheats' - it takes a sneaky peek at
what the other fragment shaders are doing on nearby fragment.   By
taking a sneaky peek at the next fragment above, below and to either
side, it can figure out how much difference there is in the texture
coordinates across the fragment - which tells it how much magnification
and/or minification is going on...and that gets you the MIPmap level. 
Because the fragment shader processors run in perfect lockstep, they are
always ready with their values for the texture coordinates at the
precise same moment.

In math terms, the rate of change of a variable is expressed as a
'differential' (as in 'differential calculus') - indicated with the
letter 'd' (actually, the greek 'delta') and in calculus you see things
like 'dx/dy' - the rate of change of x as a function of y.   What the
MIPmap level calculator is figuring out is the rate of change of texture
S and T coordinates as a function of X and Y screen coordinate: ds/dx,
dt/dx, ds/dy and dt/dy.

Now - inside shader code, it's often convenient to know how the value of
other variables are changing across the screen - this is handy when you
want to avoid aliassing for procedurally-generated stuff, for example.  
Because this is so useful, most (but evidently not all) graphics cards
allow you to use the "take a sneaky peek at your neighbours work" trick
to find the rate of change of any variable with respect to screen-space
X or Y.  In shader code, you call the 'ddx(thing)' and 'ddy(thing)'
functions - which tell you the rate of change of 'thing' with respect to
the screen coordinates...d(thing)/dx and d(thing)/dy.

Evidently some embedded processors don't (or at least, didn't) support
this mechanism (probably because they don't have many shader processors
- so the opportunity to look at their neighbours isn't there).   Hence
this functionality is an extension in OpenGL-ES - although it is in the
core standard for mainstream OpenGL and Direct3D.

It's a shame it's not in WebGL because quite a few algorithms rely on
it...but c'est la vie.

  -- Steve



>
> ----- Original Message ----- From: "Chris Marrin" <cmarrin@apple.com>
> To: "Kenneth Russell" <kbr@google.com>
> Cc: "Ben Vanik" <Ben.Vanik@microsoft.com>; <steve@sjbaker.org>; "Gregg
> Tavares (wrk)" <gman@google.com>; "Vladimir Vukicevic"
> <vladimir@mozilla.com>; "public webgl" <public_webgl@khronos.org>
> Sent: Tuesday, August 24, 2010 4:14 PM
> Subject: Re: [Public WebGL] Shader validator issue.
>
>
>>
>> On Aug 24, 2010, at 11:14 AM, Kenneth Russell wrote:
>>
>>> On Tue, Aug 24, 2010 at 9:31 AM, Chris Marrin <cmarrin@apple.com>
>>> wrote:
>>>>
>>>> On Aug 23, 2010, at 1:41 PM, Kenneth Russell wrote:
>>>>
>>>>> Support for OES_standard_derivatives is in the process of being added
>>>>> to the ANGLE shader validator. See
>>>>> http://code.google.com/p/angleproject/issues/detail?id=25 . Once this
>>>>> is in place, it will be possible to enable
>>>>> OES_standard_derivatives in
>>>>> a WebGL app. (We need to start a WebGL extension registry...part of
>>>>> this is still on my plate.)
>>>>
>>>> Extensions aren't enabled in WebKit yet, are they? How about Firefox?
>>>
>>> They aren't enabled in WebKit yet. I think we need to specify them
>>> before adding support.
>>
>> The extension mechanism is defined in the spec, but the functions are
>> not yet in WebKit I see. Once they are, it seems reasonable to add
>> experimental support for something like standard_derivitives.
>>
>> -----
>> ~Chris
>> cmarrin@apple.com
>>
>>
>>
>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>>
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: