[gstreamer-bugs] [Bug 615696] Shaders using GLSL 1.20 without #version.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=615696
  GStreamer | gst-plugins-gl | git

--- Comment #5 from Eric Anholt <eric at anholt.net> 2010-04-19 01:23:00 UTC ---
Looks like nouveau is claiming support for GLSL without actually supporting
even the required features of the GLSL in GLES2.  The new compiler will be
making that easier to support, but until then I keep the 915 version of the
same problem hidden under a driconf option :)

I haven't read the orange book thoroughly (I didn't find it to be a great
starting point for writing shaders, really), but there are a few ways that
numbers get into shaders:

- Varyings (changes per fragment or primitive)
- Uniforms (changes per draw call)
- Constants (changes per compilation of the source)

In figuring out how to get your data into the shader, the question is how often
the numbers change.  The more constant you can make them, the less resources
they consume

On the 965, varyings take up precious URB space that make it so we can't get as
much parallelism between stages of the pipeline because they end up blocking on
each other.  Not a big deal for gstreamer, where you have basically no vertex
shaing going on, and only the fragment stage is busy, which consumes no URB. 
Uniforms and varyings take up register space, which is shared between threads
on a core, so we are less able to hide latency of texture fetches or mathbox
(sqrt, reciprocal, pow, exp, log, etc.) calls through hyperthreading. 
Constants can be compiled right into the instruction stream (if they aren't
optimized out!), which only consumes icache space, and even then no more than
uniform access does and less than varying access does.  There's about 24kb of
icache, and the optimized fragment shaders were around 800b.

Now, we're dreaming of making Mesa super smart and watch the uniforms used for
a shader, then spawn a thread to go off and recompile a version where constant
uniforms are turned into constants so we can have that version on hand if you
keep your uniforms constant.  That's a loooong way down the road, though.

The next thing I wanted to check for this patch series was whether the if
statement was helping even for the kernel that was 4/9 0.0s.  My bet is that
removing the if statement will be a big win.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.