Help.. GL_NV_vertex_range causes a crash..

I have a weird problem with GL_NV_vertex_range. First, a description of what i’m trying to do: i do not have the fence extension, but i’m trying to optimize writes to the VA by using multiple buffers. So, in theory, i get a video or AGP memory buffer, i split it in MAX_BUF buffers, and in my loop i write to a buffer, call glDrawElements, then jump to the next buffer. I call glFlushVertexArrayRangeNV once i’ve used all the buffers, and loop back to the first buffer ( basically i simply want to achieve the same thing than in Nvidia’s VAR+Fence demo, for dynamic geometry, but without using the fence extension ).

So what is the problem ? My computer crashes. I allocate some space in video memory for my MAX_BUF buffers ( with a single call ), i setup the VA ( i only use the vertex and texture arrays ), then i fill my arrays as needed, calling glFlushVertexArrayRangeNV once i’m looping back to the first buffer. The heart of my loop looks like this:

for (y=-10.0f;y<10.0f;y+=2.0f)
{
for (x=-10.0f;x<10.0f;x+=2.0f)
{
if (cbuf==0) // comment me and it works
glFlushVertexArrayRangeNV();

                    glVertexPointer(3,GL_FLOAT,3*sizeof(GLfloat),buf_verts[cbuf]);
                    glTexCoordPointer(2,GL_FLOAT,2*sizeof(GLfloat),buf_texs[cbuf]);

                    FillVA(buf_verts[cbuf],buf_texs[cbuf]);

                    glTranslatef(x,0.0f,y);
           glDrawElements(GL_TRIANGLES,nb_elems,GL_UNSIGNED_INT,elems);
                    glTranslatef(-x,0.0f,-y);

                    cbuf=(cbuf+1)%MAX_BUF;
            }
    }

glFlushVertexArrayRangeNV();

There is around 9000 elements and 3000 triangles for each call, but if i reduce it to 50 it still crashes. If i simply replace the priority in wglAllocateMemoryNV from 1.0 ( for video memory ) to 0.5 ( AGP memory ), everything runs fine, w/o changing any other line ( also runs if i use standard system memory ). If i disable texture mapping, it runs fine too ( ! ). Finally, if i call glFlushVertexArrayRangeNV every time i write a buffer ( instead of every MAX_BUF buffers ), it runs fine. I’ve tracked the crash to the glDrawElements call with the debugger, but all the arrays pointers seem to be fine: they are 4-bytes aligned ( btw, i tried with 8 and 16 bytes aligned pointers, doesn’t work either ).

Please… if anybody has an idea… i’ve ready all the specifications but i can’t find where the problem is ( btw, i’ve yet to see a demo using dynamic VARs without using fences… any links are welcome )… What would cause a crash in the driver ( the computer freezes, and i must reset )…?

Thanks,

Y.

Other informations:

  • it doesn’t crash when using lighting and a normals array only.
  • it crashes when i use a color array instead of a texture array.
  • i tried to align the arrays pointers to 32-bytes, and also the stride to be a multiple of 32. Still crashes.
  • i modified the NV_array_range + Fence demo ( the one with a dynamic ondulating golden surface ) from Nvidia’s, to support texture mapping instead of normals. I removed the use of fences. Crashes too. I’m starting to wonder if it’s not a driver bug … I can post the bins and sources if someone has the time to look at it … at least, is it a valid operation to use NV_vertex_array range without using fences ?

Btw, i have the Elsa Erazor X 4.12.01.0206.0050 driver…

Y.

Mail me the executable (and any data it needs) I’ll try it on mine.

I got VAR without fences working fine on a terrain quadtree demo I did.

Ran quite well with AGP, but horrendously slow with video mem. I also used a shadow buffer in system ram for something but I can’t remember.

If you want I could post up an example pretty soon on my site. Been needing some ideas for examples anyway.

What card/drivers you got? And OS too?

  • Nutty

[This message has been edited by Nutty (edited 02-07-2001).]

It’s bad to use video memory for anything dynamic, although it still should not crash.

FlushVertexArrayRangeNV is fairly similar to Finish in many ways. What happens if you use Finish instead?

  • Matt

It wasn’t dynamic. All the vertices never changed. Still very slow though.

I think it’s cos I was using glVertex* (I know, I know!) so it was like reading them up for each vertex. Should’ve maybe done a display list per leaf node or somat.

AGP mode worked top though!

  • Nutty

> What card/drivers you got? And OS too?

An Elsa Erazor X ( GeForce 256 ) with Win98.

> It’s bad to use video memory for anything dynamic, although it still should not crash.

I don’t read from video memory, so i guess it’s not so dramatic ? But anyway, i certainly can’t let a potential crash in my code :slight_smile:

> FlushVertexArrayRangeNV is fairly similar to Finish in many ways. What happens if you use Finish instead?

Crashes too :frowning: What’s interesting to note is that, if i use a vertex array and a normals array with lighting, it doesn’t crash. Also, it crashes wether i flush or not.

I’ve put the binaries,data and sources ( 469 kb zip ) for those of you who are interested, at
http://perso.club-internet.fr/brebionf/VARmodif.zip

Y.

Well, if reading from AGP with the CPU is bad, video is far worse.

Do NOT use AGP or video memory unless you are using it with VAR. That means no immediate mode, for one.

  • Matt

The app worked fine for me on a GF2 MX on Win2K with 6.31 drivers (I didn’t try any newer versions).

I don’t know what the driver version you’re talking about is. It doesn’t look like an NVIDIA driver version number. I’d suggest using the latest reference drivers from our web site (6.50).

  • Matt

Ok, thanks all, i’ve ugraded my drivers and it works fine now. Was definately a driver bug 2 days lost

Y.