Re: Can drivers lie?

Dave Eberly wrote:
I added code to my OpenGL renderer to trap when extensions
I use do not exist. When running this on my laptop computer,
I ran into a strange problem. Queries to the driver:

vendor = ATI Technologies Inc.
renderer = FireMV 2400 PCI DDR x86/SSE2
version = 1.3 5014 WinXP Release

Okay, so it appears I am running OpenGL 1.3. My extension
handling system, though, queried the driver for all the
function pointers that are associated with OpenGL 2.0. Every
single one came back non-null, so my extension handling system
reports I can run OpenGL 2.0.

There might be some obscure little 2.0 function
which isn't supported. I think it's much better
to check if individual extensions are supported
than to try for some (fairly mythical in practice)
OpenGL version number.

I make the call
GLint maxVShaderImages;
glGetIntegerv(GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS,&maxVShaderImages);
and the value of maxVShaderImages is uninitialized, which means
the driver doesn't like the query.


Maybe it's a bug in the driver. Write a very simple
test program to check it and if it still happens
get in contact with ATI via the "feedback" page
on their web site. If you can give them a simple
test program they're usually very good at fixing
things.

Is it really the case that I have to check the OpenGL
> version number and ignore the fact that the driver gives
> me non-null pointers for functions defined
in later versions of OpenGL?


No. The version number is perhaps the least useful
piece of information you can extract from a driver.

A card might be 99% OpenGL 2.0 compliant and support
all the functions I need so a perfectionist API
which tells me "sorry, we only have OpenGL 1.3"
isn't helpful.


--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.

In science it often happens that scientists say, 'You know
that's a really good argument; my position is mistaken,'
and then they actually change their minds and you never
hear that old view from them again. They really do it.
It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens
every day. I cannot recall the last time something like
that happened in politics or religion.

- Carl Sagan, 1987 CSICOP keynote address

.

Relevant Pages

  • Re: MOH: Allied Assault under Vista
    ... I would get a "no opengl driver ... they were building a support team to re-write ... OpenGL for Vista. ... Soon after I discovered a beta NVIDIA driver on Guru3D which did, so I went ahead and tried it, and lo and behold things worked. ...
    (comp.sys.ibm.pc.games.action)
  • Re: Display problems in Vista
    ... Vista has been out for several months, so I assume the problem is ... mixed GDI and OpenGL. ... never corrected that in the driver so an alternative had to soft coded. ... one can always point to the OpenGL specification. ...
    (comp.graphics.api.opengl)
  • Re: how do i fix this?
    ... Quake 3 is not finding a proper OpenGL-compatible display driver on your ... > Initializing DirectInput... ... > Initializing OpenGL subsystem ...
    (microsoft.public.games)
  • Re: avoiding glTranslatef*
    ... So memory bandwidth is in critical role, ... and you can still render with a single display list command. ... Let's not forget in these discussions, that OpenGL is not, and in my ... just a graphics hardware driver exposed to ...
    (comp.graphics.api.opengl)
  • Re: State of Linux graphics
    ... Those OpenGL commands could be directly implemented with whatever ... After one driver was ... >>display hardware does well, ... on renderbuffers but we really need that overdue memory manager. ...
    (Linux-Kernel)
Loading