[Mesa-dev] [PATCH] Linking fails when not writing gl_Position.

[Erik Faye-Lund]

On Thu, Sep 11, 2014 at 12:32 AM, Ian Romanick <idr at freedesktop.org> wrote:
> On 09/10/2014 01:53 PM, Erik Faye-Lund wrote:
>> On Tue, Sep 9, 2014 at 7:30 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>> On 09/08/2014 01:10 AM, Tapani Pälli wrote:
>>>> From: Kalyan Kondapally <kalyan.kondapally at intel.com>
>>>>
>>>> According to GLSL-ES Spec(i.e. 1.0, 3.0), gl_Position value is undefined
>>>> after the vertex processing stage if we don't write gl_Position. However,
>>>> GLSL 1.10 Spec mentions that writing to gl_Position is mandatory. In case
>>>> of GLSL-ES, it's not an error and atleast the linking should pass.
>>>> Currently, Mesa throws an linker error in case we dont write to gl_position
>>>> and Version is less then 140(GLSL) and 300(GLSL-ES). This patch changes
>>>> it so that we don't report an error in case of GLSL-ES.
>>>
>>> Wow.  We can add this to the list of ways OpenGL ES is just plain
>>> broken.
>>
>> Historical note: It's not broken, this is by design. The rationale for
>> why we did this was to ease the burden of compile-time checks for the
>> compiler - detecting if gl_Position is written no matter how the
>> program branches is not trivial, so we decided against it. When we
>> specified this, the typical mobile CPU clock-rate was *a lot* lower
>> than it is today.
>
> I'd call that broken by design.  The overhead of checking that a shader
> statically accessed a variabl is infinitesimal, no matter how slow your
> CPU is.

Not so. If you consider the minimal feature-set required for GLES 2.0,
you'll realize that conformant implementations was expected to do
*very* little program analysis, and compiling shader is something
you're doing on a very restricted time-budget.

When working on the Mali-200 driver for early customers, we also
needed to keep the entire driver (including compiler) in the
size-order of 100KB, due to ROM size limitations. I remember numbers
being thrown around the working-group were that no one could spend
more than around 50KB for the compiler, and around 30ms compilation
time per shader (running on a 2-300 mhz ARM9 CPU, with 64MB of RAM).
Sure, afterwards Android came around and changed a lot of that, but we
couldn't have known (and a lot of people were explicitly betting
*against* anything like that).

So yeah, we really needed to keep stuff down, both for performance and
size-reasons.

> These are the sort of cut-corners that make developers hate
> OpenGL development.  "Why is the screen black?  No clue."

Meh. GLES has way less of these than desktop GL of the same vintage,
so color me unimpressed by that argument.

But also, keep in mind that this was at a time where the total number
of GLES adopters were zero. Yes, a some decisions were made that might
seem questionable now that we *know* that GLES 2 became a success. But
it might not even have become one if we didn't cut some of those
corners.

We went from zero to hundreds of millions of devices real quick, and
initially all the chip-customers were *really* worried about even
shipping a compiler on their device.