[Mesa-dev] Mesa (master): mesa: Validate assembly shaders when GLSL shaders are used

[tom fogal]

Ian Romanick <idr at freedesktop.org> writes:
> Brian Paul wrote:
> > On 10/12/2010 07:49 PM, Ian Romanick wrote:
> >> Brian Paul wrote:
> >>>> -
> >>>> +#include<stdbool.h>
> >>>
> >>> Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be
> >>> consistent?
> >>
> >> If possible, I'd prefer not. [. . .]
> > 
> > My concern here is people will get lazy and just use int
> > everywhere.  Using GL types such as GLuint, GLint, GLboolean and
> > GLbitfield convey useful information about the variables declared
> > with those types.
>
> There are a few GL types that actually have useful semantic
> information.  The others were just ways to request types of a
> specific size (e.g.,  GLint must be a 32-bit integer).  With
> inttypes.h and stdbool.h those types no longer serve any purpose.
> They just make code that uses OpenGL look different from code that
> doesn't use OpenGL.
>
> > For example, if I see "int buffers_used" I have to wonder if
> > it's really a boolean or a bitfield or a count (and what if it's
> > negative?).  I don't have that problem if the GL types are used.
>
> GLint vs. GLuint doesn't provide any advantage over int vs. unsigned.
> Looking at the number of 'comparison between signed and unsigned
> integer expressions' warnings (over 600 in my build) in Mesa, it's
> pretty clear that we're doing it very wrong anyway.

One thing that bytes (ha!) us now and again is GL's broken "sizei"
type, which is *signed*.  Ugh.

As an app developer, GL types are dumb.  They don't provide any
advantages, and they add the additional step of casting your data
before you send it to the GL.  Nobody is going to standardize on
'GLfloat', for example, because your I/O code being cognizant of
graphics is stupid (not to mention the desired abstraction for a DX
backend).

I guess this is technically broken -- "... for example, GL type int is
referred to as GLint outside this document, *and is not necessarily
equivalent to the C type int*." (emph. added, from gl3.1 spec, page
16).  That said, if they didn't line up I bet so many apps would break
that GL driver authors don't really have a choice, but that's another
story...

Back to my main thread: I wish these types would just die, and GL would
switch to the semi-std int8_t, uint32_t, etc. types.  I'd vote the GL
types exist only at interfaces, for what my vote's worth.

(That said, there are a few types: bitfield, half, clampf, and clampd,
which convey unique information and might be nice to keep around.)

-tom

> > We should keep the "write once, read many times" principle in mind.
> >
> >> We already have stdbool.h in the Mesa tree for platforms that lack
> >> it.
> >>
> >> Moreover, we're using bool/true/false in all of the C++ code.
> >> Even as a long time OpenGL programmer I find bool/true/false
> >> infinitely more natural than GLboolean/GL_TRUE/GL_FALSE.
> >
> > Well, I like consistency and it looks a bit messy to mix GLboolean
> > and bool in neighboring code.
> >
> > C++ has had its bool type for a long time I have no problem with
> > using it there.  GLboolean would look out of place in the GLSL
> > compiler code.
> >
> >> Either way, we should resolve this soon.  All of the EXT_sso work
> >> I've been doing using stdbool.h, so I'd like to know if I need to
> >> go back and change all of that.
> >
> > I'd prefer GLboolean but I also don't want to cause you a lot of
> > inconvenience in your work.
> >
> > Some O.S. projects have a pretty rigid coding style and I like the
> > consistency of that.  I'd actually like to have that in Mesa but I
> > also don't want to spend my time nagging people about their style.
>
> Yeah, pretty much all large projects have more rigid coding style
> guidelines.  I think that's a good thing.  They also adapt over time.
> The Linux kernel coding style isn't the same today as it was 5 years
> ago, for example.  Part of what makes it work in other projects is a
> more rigid review process.  Much fewer people have commit rights, and
> changes from other people have to go through those few gatekeepers.
>
> Maybe it's time to at least work out what we would want the coding
> style to be.  A process for enforcing it can be derived later.