[Mesa-dev] [PATCH] glsl: add support for gl_InstanceID

[Jakob Bornecrantz]

On Tue, Mar 15, 2011 at 1:00 AM, Ian Romanick <idr at freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/14/2011 04:01 PM, Jakob Bornecrantz wrote:
>> On Mon, Mar 14, 2011 at 11:46 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 03/10/2011 03:30 PM, Marcin Slusarz wrote:
>>>> ...by copying support for gl_InstanceIDARB, but without "#extension" check,
>>>> because EXT_draw_instanced spec does not say anything about it (as opposed
>>>> to ARB_draw_instanced / gl_InstanceIDARB) and NVIDIA driver already allow it
>>>
>>> NAK for a couple reasons.
>>>
>>> This extension depends on EXT_gpu_shader4, which we don't support.
>>> There's no #extension bit required for this extension because the GLSL
>>> changes are implemented by EXT_gpu_shader4.  Without EXT_draw_instanced,
>>> gl_InstanceID always reads 0.
>>>
>>> Note that EXT_gpu_shader4 says that a #extension line is required to use
>>> the features of the extension, including gl_InstanceID.  If their driver
>>> allows gl_InstanceID without a #extension line, it is a bug in their driver.
>>
>> Oh you clearly haven't tried using new features on the nVidia blobs
>> have you, bugs galore! Mind you, you do get a warning per feature used
>> not #extension:ed or #version:ed in the shader log, but who bothers to
>> read that as long as the shader compiles and links correctly[1] :-/
>
> And a little googling will find a *ton* of people pissed that their
> shaders work on NVIDIA's drivers and *nowhere* else.  NVIDIA's
> implementation is clearly wrong here, and we should not copy their
> portability bugs.

Oh most definitely not, just stating the sad fact.

>
>> The problem we have is that most who develops advanced 3D programs do
>> it against the blobs since they have all the cool features, me
>> included and yeah I'm lazy as well. Once EXT_gpu_shader4 lands in mesa
>> I guess I would be motivated to revisit my shaders and code and make
>> sure they are proper.
>
> I'm not sure EXT_gpu_shader4 should ever land in Mesa.  All of the
> features in EXT_gpu_shader4 are in 1.30 or 1.40 (right?).  Every piece
> of hardware that currently supports EXT_gpu_shader4 already also
> supports 1.30 and 1.40 (right?).  As a result, there aren't a lot of
> apps that use just EXT_gpu_shader4 (and not 1.30 or 1.40), and it seems
> unlikely that new ones are being developed.

Haven't had the time to figure out what is in what, which I figure
most app developers doesn't have either, so I understand both why
nVidia did it they way they did and why people are mad that their
shaders aren't portable.

>
> But, this a debate we can have another day... since we don't have
> support for /any/ of it yet.
>
>> [1]The topping of this particular cake is that if you try to use any
>> of the #versions or #extensions you get errors when you try to use
>> deprecated things that are convenient to use, which promotes people to
>> not do the right thing here and just ignore the #version and/or
>> #extension for features.
>
> How do you mean?  Unless you specifically request a "core" context,
> everything should still work fine.  Certainly saying '#extension
> GL_EXT_gpu_shader4: require' shouldn't cause anything to stop working.
> Right?

Hmm, maybe it was only #version that gave me problems, I was in a
hurry at the time so I took the lazy way out. I'll put it on my TODO
to check what works and what doesn't and report back. Also I don't
really know what type of context I get since I use SDL.

Cheers Jakob.