Frame buffers, vertex programs and more. 8600m GT

Member
Posts: 52
Joined: 2007.06
Post: #1
Ive been doing research on a project i call sunviz for some time now.

Ive recently implemented a 1024k particle Coronal Mass Ejection(CME) interaction with the magnetosphere of the sun and earth.

Im using VBO's, FBO's and lots of other fun stuff...

Heres the big problem, basically im using 4 textures attached to color0-color3 on a framebuffer. Writing to only two at a time, ping-pong between the 2 write and 2 read textures when using the fragment shader calculate forces and update the two write textures which will be used for reading on the next pass.

Total texture size is 98mb. I can run the simulation 100% for as long as i like 2 times in a row, however if i attempt to run a third time the system freezes with the dreaded gray screen, hold power button to reboot.

I thought i was doing something wrong for a couple hours, then i threw the entire code package on my linux box that contains a Nvidia Quadro FX 5600 with 1.5GB of frame buffer. The problem 100% goes away. I can run 100 times if i like, well i only tested say 20 continuous runs a few times over.

The error message i get is kernel panic with nvidia driver when i reboot, say illegal access to some base memory address.

Any thoughts or suggestions? When i trace the code with GDB the segfault happens
right when i use an drawquad call to draw a fake quad for my simulation.

Ive verified all memory is being cleaned up before program termination, aka removing textures, FBO, VBO's, shader programs.

Last but not least, im using SDL for a couple things. Worked wonderful until i started doing this whole Framebuffer fragment program ping pong technique. If i attempt to do a logical 'or' with the full screen extension for SDL when the simulation starts it enters full screen and the entire system is not responsive. aka, keyboard, mouse, caps lock, anything and everything doesnt work. Must hold the power button down to reboot.

Any help with either of these problem would be greatly appreciated!


Steven
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Sounds like a bug. File it at http://bugreport.apple.com/ (free "online" ADC membership required, get it at http://connect.apple.com/ ).

NVidia drivers for the Mac (and 8600M drivers in particular) are not known for their quality. Might be worth trying on an ATI card if you've got one handy.
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #3
Yeah i got a few Atis on the Sgi Altix i can use.

Sorry this may sounds stupid, does it matter im using cg? I imagine it must work on on ati. Actually texture looksups on ati, does that work yet? If not i can translate particle positions in the vertex shaders.

ie.) position.out = mul(mvp, tecRECT(tex, texCoord));

tex contains all the position info that is being ping-ponged in the fragment shader.

I loose about 20 FPS if i have to read the texture memory back, update a dynamic VBO and render.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
I was talking about an ATI card in a Mac, you've proven it works on a PC, and ATI's PC GL drivers aren't much fun.

Cg has limitations on ATI cards that it doesn't on NVidia. You'd be better off using GLSL in general terms.
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #5
Is there some instructions for setting this type of stuff up under os X?

Should there be any differences? I have a fragment shader program that works perfectly in another app. As soon as i added a vertex shader to it, no good. copy it over to my linux box and everything is perfect.

Here my make file, well the important stuff. New to developing on a mac.
OPENGL_LIB= -framework OpenGL -framework SDL_image -framework Cg -framework SDL -framework Cocoa
%.o: %.cpp %.h
$(CC) -c -DMACOSX $(DEBUG) -O3 -o $@ $<
$(EXECUTABLE): $(OBJECTS)
$(CC) -DMACOSX $(DEBUG) -O3 -o $(EXECUTABLE) $(OBJECTS) $(OPENGL_LIB)
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #6
Hey, i know your a champ at this stuff. U have helped me many times, here is the os x bug report. Was hoping todays graphics driver update from mac would help but on the third try, she freezes.

0 com.apple.GeForce8xxxGLDriver 0x1757858f gldFinish + 1942
1 com.apple.GeForce8xxxGLDriver 0x1755ee39 gldDestroyFramebuffer + 515
2 com.apple.GeForce8xxxGLDriver 0x17571be6 gldObjectUnpurgeable + 18412
3 com.apple.GeForce8xxxGLDriver 0x17575460 gldUpdateDispatch + 674
4 GLEngine 0x173df6be glBegin_Exec + 282
5 libGL.dylib 0x92b232b3 glBegin + 89
6 galaxy 0x0000d36a ParticleRenderer::drawQuad() + 24 (ParticleRenderer.cpp:136)
7 galaxy 0x0000e2e0 ParticleRenderer::timeStep() + 866 (ParticleRenderer.cpp:193)
8 galaxy 0x0000443d draw_stuff() + 147 (galaxy.cpp:222)
9 galaxy 0x00004972 mainLoop() + 312 (galaxy.cpp:463)
10 galaxy 0x00006465 SDL_main + 729 (galaxy.cpp:912)
11 galaxy 0x00002d84 -[SDLMain applicationDidFinishLaunching:] + 75 (SDLMain.m:305)
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
The Mac is a lot less forgiving about making OpenGL calls without a context than most other systems, and the Mac GLSL compiler is much less forgiving of illegal code than the NVidia Windows/Linux drivers. Aside from those, if it runs on NVidia/Linux and doesn't run on the Mac, I generally assume it's a Mac bug.
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #8
Wow that really really sucks,

Its one of the best performing machines ive ever had, i can usually work my way through bugs and such but ive gone on at least five wild goose chases in the last few months.

Its been an incredible waste of time!!!
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #9
Well i think i have figured it out,

Im storing around 100Mb on the GPU in terms of textures that are rendered to from a framebuffer object. Now from a clean boot, i can run the program great two times.

The third run gives the reported errors. I think it has something to do with the memory being free'd on the GPU on program termination is not actually freed. The application allocates this memory correctly, attempts to use and everything blows up.

Here is my destructor,
~ParticleRenderer() {
glDeleteTextures (4,_textureHolder);
glDeleteFramebuffersEXT (1,&_fbPosition);
glDeleteBuffers(1,&_pbo);
glDeleteBuffers(1,&_vboColor);
std::cout <<"ParticleRenderer::cleaned up!" << std::endl;
}

Ive used the old checkGLErrors and checkFramebufferStatus and everything is kool there.

Any thoughts?
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #10
PS i can get the exact same error on the second run of a clean boot if i increase the particle count so it uses 150Mb of memory. Basically its touching bad memory sooner.

PSS i did the bug report, still doesnt help me much...
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #11
Welcome to the club. Your bug is now in a black hole. If it's judged serious (and it sounds like it might well be) then you might get a fix as early as 10.5.2 (rumor sites seem to think 10.5.1 is finalized). If it's not judged serious, you might have to wait until 10.7 or so... and there's no way you can find out which or influence the decision.
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #12
Damn man!!

So what do u do? Youve been programming in graphics on a mac for many years, when u run into a fundamental problem what do you revert to. I luv the mac, would be really sad to get rid of it. But if i cant use it, what good is it to me..

Im going to throw the project on an identical macbook pro to see if i can duplicate the problem.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #13
I submitted a 100% every-time hard crasher with reproducible code when 10.4.(9/10?) came out. Blew up my particle system code, too, though in my case I was doing soft particles with depth texture readback. Worked great when I wrote it under 10.4.7 or so, but blew up when I upgraded to 10.4.9 or 10.

Apple sounded like they were taking it seriously. I got an email from an engineer saying he'd reproduced it independently.

Well, it still blows up, even in Leopard. Guess I'd better re-file it.
Quote this message in a reply
Member
Posts: 52
Joined: 2007.06
Post: #14
This is strange, i dont get how 90% of my shaders work and 10% dont. I would sooner have it that zero worked.

Ive been screwing around trying to figure out the difference with no luck.

All im doing now is drawing point sprites, translating based upon a texture lookup on a texrect which is updated by a framebuffer.

Everything works, however some random color crap comes out even with me explicitly setting the color in the vertex shader to float4(1,0,0,1). They eventually go black.

Absolutely no sense!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #15
You're trying to do vertex texture fetch? Last I checked that wasn't supported...

Also, point sprites are an abomination (and IIRC are known to be unusably buggy on various hardware/OS versions). Why aren't you using regular old quads?
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Free paint programs? Toontingy 12 6,021 May 18, 2009 01:14 PM
Last Post: Ingemar
  Stencil buffers in an FBO... trouble TomorrowPlusX 17 7,310 Mar 23, 2006 08:19 PM
Last Post: kberg
  Beginning ARB vertex programs dfmoore 1 2,756 Sep 24, 2005 02:45 PM
Last Post: lightbringer
  Pixel Buffers, Cocoa, and Mipmaps bensta00 10 5,437 Jan 24, 2005 02:11 PM
Last Post: arekkusu
  How much VRAM for textures/buffers? Fenris 2 2,538 Nov 24, 2003 10:37 AM
Last Post: Fenris