Performance HIT with VBOs?
Author
Ok so this is kind of a weird application I guess but here's what I'm doing...
It's pseudo 3d/2d game. It's in perspective, not ortho... simply quads flyin around as sprites, 4 vertices each, flat, and with tex coords being changed according the frame of animation.
My procedure here is this,
1. load up my VBO's, create a buffer for vertex coords, texture coords, and color coords,
2. setup my indices (which is just an array, size equivalent to how many vertices at max i want on the screen, with data of 0 to that number.... array[0] = 0, array[1] = 1, etc.), because then...
3. a routine that goes through all of my object data, takes their x, y, z, and rotation into account and spits out the x, y, z of each vertice into my vertex array (along with my tex coords and color data in seperate arrays), so each object that's on the screen gets added to the array in the order they should be drawn (hence my indices being 0, 1, 2, 3, 4, 5, ...). THEN i BufferDataARB those arrays.
4. repeat step 3 each frame, walla.
In my intense demo I setup, with like 300 sprites going crazy (1200 vertices), I get around 46 fps using standard vertex arrays (not buffered in graphics card memory as I understand it) and around 30 fps utilizing the VBO ARB extension which is supposed to be glorious in its infinite capacity for speed.... what gives? Am I doing something wrong or is doing it this way just bad news?
You did create your VBO with a usage of STREAM_DRAW, yeah?
You might also try MapBuffer and writing directly into there instead of making your own system memory copy.
You might also try MapBuffer and writing directly into there instead of making your own system memory copy.
Author
Yeah I used STREAM, and tried STATIC just for some giggles. I was on my way to use MapBuffer but they I started seeing a bunch of red flags- Lock/unlocking!? SATANIC! Buuuuuuuut I'll guess I'll labor another go, aaah 'til then, anyone else have any thoughts?
Doing a MapBuffer allows you to lock that specific area of video memory, and map it into virtual process space. This way when you write into that buffer, you directly change the memory on the video card.
Mapping is orders of magnitudes faster because you do not need to write into system RAM (which is probably not cached, so you usually incur cache misses to store the data), and you do not need to copy the data from system RAM into video memory, so there is less bus overall traffic.
Change over to use mapping. You'll be glad you did. :)
Mapping is orders of magnitudes faster because you do not need to write into system RAM (which is probably not cached, so you usually incur cache misses to store the data), and you do not need to copy the data from system RAM into video memory, so there is less bus overall traffic.
Change over to use mapping. You'll be glad you did. :)
however, a MapBuffer is a sync point and can/will stall the CPU while it waits for the GPU.
There is also no garrentee about where the memory you are writing to exists, it could be system ram still and the driver controls the copy back.
Posting relivent code might well help people spot some points of issue..
There is also no garrentee about where the memory you are writing to exists, it could be system ram still and the driver controls the copy back.
Posting relivent code might well help people spot some points of issue..
If the buffer is in use by the GPU, or the GPU is busy handling some other request, yes, the CPU will stall. You can use double buffers and alter one while drawing the other to minimize any GPU impact.
Any decent hardware today will provide a buffer of memory on the video card itself, although there are still some bad ones out there. Most Intel chipsets basically have no video memory at all, they just give a portion of system memory.
Even still, mapping is going to be faster than a buffer copy every frame.
Any decent hardware today will provide a buffer of memory on the video card itself, although there are still some bad ones out there. Most Intel chipsets basically have no video memory at all, they just give a portion of system memory.
Even still, mapping is going to be faster than a buffer copy every frame.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
