Radeon 9800 Pro - Questions

OpenGL OpenGL: Advanced Coding
1

This post should perhaps go right to ati, but I think the questions and answers can be of general interest.

For various reasons I upgraded from NVidia’s GeForce 4200 Ti to ATI’s Radeon 9800 Pro (128M). After installing the Catalyst 3.4 drivers I was puzzled by a few things.

  1. When querying for the GL version it gives me 1.4. However, I cannot wglGetProcAddress any of the functions in the imaging subset that became core in 1.2. Moreover, the PointParameteri(v) functions also fail (core in 1.4). Not that I lose any sleep over this, but I would appreciate some facts/comments on this one.

  2. GL_ARB_vertex_buffer_object is not in the extension string, but I can wglGetProcAddress all the functions in this extension. Does this mean it is not fully supported yet and the functions are in for people to experiment? I know NVidia did this some driver versions ago. However, when I googled around I came across e.g. humus’s framework code and he checks extension string presence prior to setting up the associated vbo functions. Any experiences here?

  3. The last point is a little esoteric. It is on using Cg with the new ATI card. Under the old 4200Ti I had a Cg vertex program for rendering a pulsating sphere reflecting its surroundings through a cube map. When using glVertex (immediate mode) to pass on the vertices everything is fine on both cards. But when I switch to an indexed vertex array using Cg’s equivalent of glVertexPointer functionality it does not go so well. Specifically, it all works on the 4200Ti. On the 9800Pro the program runs for about five seconds and then it stalls and locks up the whole computer as well. Some would probably say that some quirks are to be expected in this “mixed” setup. Anyone out there with any insight on this? By the way, I also wrote a program that replaced the “cg-stuff” with an equivalent ARB_vertex_program setup using glVertexAttribPointer. No problems at all on the 9800Pro. I could not trigger any hangups.

Some facts on the system I used:

  • Windows XP Home edition

  • Intel P4 1.6GHz with an ASUS board

  • Catalyst 3.4

  • The latest gl.h, wglext.h, glext.h from the extension registry (check it out, they finally updated them).

  • SFRuckus

2

Originally posted by SFRuckus:
1. When querying for the GL version it gives me 1.4. However, I cannot wglGetProcAddress any of the functions in the imaging subset that became core in 1.2. Moreover, the PointParameteri(v) functions also fail (core in 1.4). Not that I lose any sleep over this, but I would appreciate some facts/comments on this one.

Please write down your code’s wglGetProcAddress line.
Do you use (ARB or EXT) at the end of the functions?

3

Csiki wrote:

Please write down your code’s wglGetProcAddress line.
Do you use (ARB or EXT) at the end of the functions?

I use the (template) function

template
bool LoadExtension(T& glfptr, char* name)
{
if( !( glfptr = reinterpret_cast(wglGetProcAddress(name)) )){
Log::cout << “InitOpenGL: Error loading <” << name << “>” << Log::endl;
return false;
}
else {
Log::cout << “InitOpenGL: Loaded <” << name << “>” << Log::endl;
return true;
}
}

for initializing function pointers. So for the OpenGL 1.2 function glHistogram my code will contain

PFNGLHISTOGRAMPROC glHistogram = 0;
LoadExtension(glHistogram, “glHistogram”);

No EXT or ARB extension is required. This function is a core OpenGL function since 1.2.
And I do query and verify that I have OpenGL version 1.4 before initializing any of these function pointers.

Let me point out that when using NVidia’s cards and drivers glHistogram is successfully initialized along with all the other functions which became core in 1.2, 1.3 and 1.4.

  • SFRuckus

PS: I hope the code is legible. Don’t know the markup language used here.

4

The imaging subset is, if I remember correct, an optional part of the core. If it’s implemented, ARB_imaging should be found in the extension string. If it’s not there, the imaging subset it not supported.

5

Originally posted by Bob:
The imaging subset is, if I remember correct, an optional part of the core. If it’s implemented, ARB_imaging should be found in the extension string. If it’s not there, the imaging subset it not supported.
Exactly.

That’s also the reason why everything belonging to the imaging subset is displayed in the spec on a different (grey) background.

6

cough

This is a Radeon 9700 Pro running Cat 3.4. It reports GL version 1.3 (and so does mine).

This is a 9800 Pro with slightly older drivers (3.2 methinks) and it also reports GL version 1.3.

Anyway, Cat 3.4 exposes ARB_vertex_buffer_object in the extension string on all Radeon cards. 3.2 does not.

Delphi3D currently doesn’t seem to have a 9800Pro report w 3.4 yet, maybe you could submit one, help them helping us and stuff.

Let me ask just one silly question: does your driver really report version 1.4?

The string reported through GL_VERSION should be “1.3.3717”.

7

zeckensack:

After a driver reinstall and a recompilation of my framework I get version 1.3.3717. I am not sure why I got 1.4 before but I suspect that the 3.1 driver was not properly removed. All entry points in 1.4 apart from glPointParameteri(v) are present though.

The reinstall also fixed my problem with ARB_vertex_buffer_object not being exposed int the extension string.

> Delphi3D currently doesn’t seem to have a 9800Pro report w 3.4 yet, maybe you could submit one, help them helping us and stuff.

Will do so this evening.

Bob and zeckensack: thanks for the imaging subset clarification.

  • SFRuckus

[This message has been edited by SFRuckus (edited 06-19-2003).]