On Tue, Mar 15, 2011 at 1:00 AM, Ian Romanick <i...@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 <i...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
