View Full Version : does the GPU process the blending?
12-10-2005, 07:16 AM
When i use from the blending in some of my programs, the fram rate starts to decrease. I don't know that what does happen in the blending process. Does the GPU process the blending?
12-10-2005, 07:26 AM
normal rendering, the GPU does :
-compute pixel color
-write to FrameBuffer
blending requires the GPU to do :
-compute pixel color
-do blending operation between src and dst
-write to FrameBuffer
12-11-2005, 08:22 AM
So it's so expensive for the older graphics cards such as ATI Radeon 7000 or NVIDIA TNT2. Regarding the book OpenGL Game Programming, I have used from the billboarding and blending to draw the trees. But now the frame rate is something about 30 - 40 FPS. In my demo, i have used from a simple terrain and then i have drawn many trees in this manner. So does the blending reduce the frame rate?
12-11-2005, 11:14 AM
>> So does the blending reduce the frame rate?
of course it does, you see it with your own eyes :)
Try rendering with the blending disabled, you'll see the difference.
Can you post screenshots, both with and without blending ?
BTW, use alpha testing too, it will accelerate rendering for totally transparent parts.
Something like :
12-12-2005, 07:58 AM
*Can you post screenshots, both with and without blending ?*
Of course. Here's a screen shot of our demo with blending:
And you can see our demo with the blending disabled here:
also, you can download our free demo here:
In this demo, i have used from both the blending and alpha testing:
glEnable( GL_BLEND );
glBlendFunc( GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA );
glEnable( GL_ALPHA_TEST );
glAlphaFunc( GL_GREATER, 0.0f );
Billboarding( p1, p2, p3, texId , size );
glDisable( GL_BLEND );
glDisable( GL_ALPHA_TEST );
Note that i have loaded the targa files in this demo.
unfortunately, in my country, most of the people use from the older graphics cards such as ATI Radeon 7000. So i want to increase the frame rate without reducing the quality of my demo. Dorbie have suggested me to use from the ABGR format--Many special thanks to him. But i don't know anything about the ABGR formats. So how can i use from this format? Here's his suggestions:
The other thing you may want to do and it may be the real cause of your performance issue is just specify ABGR texture internal format, don't explicitly request 8888 or RGBA (although RGBA shouldn't be an issue for good drivers etc.)
So ABGR no specific 8888 format, maybe just ask for a 4444 format using internal format extensions and no blending just alpha texting instead.
12-12-2005, 09:56 AM
I think you should disable blending altogether, if it brings the performance you need. Set the alpha test cutoff at 0.5
But you should modify the textures accordingly : ie. for the star texture, its background should be black, not white, and for trees background should be green.
>> Dorbie have suggested me to use from the ABGR format
In those cases, please post a link to the related forum thread ...
Dorbie is talking about the *internalformat*, read the man pages for glteximage2D :
And don't forget the spec, maybe hard to read, but very precise :
12-12-2005, 11:53 AM
I have had good success with "screendoor" blending (http://www.opengl.org/resources/faq/technical/transparency.htm) .
Looks like it might work for your app.
12-12-2005, 12:30 PM
this may not be related to your question- but i think you should add a lot more blood and
cut off human body parts :p
12-12-2005, 01:03 PM
It was a personal email I sent. I've been mentoring Ehsan for some time via email.
I also made the suggestion to disable blending and perform the alpha test to speed things up.
Eshan, you have a halo (a colored outline in your case black in some textures white in others)around your images when you disable alpha blending, this is because the color under the transparent alpha does not match the color with the opaque alpha, you can create images that color under the transparence to fix this.
With later releases of OpenGL and various extensions additional internal formats are supported that give more control over how OpenGL stores textures. These are simply sent as tokens in the tex image call. Technically the internal byte ordering shouldn't affect performance an implementation can still swizzle internally and you'd never know (render to texture has presented new issues of course), but external format byte ordering could affect loading performance via external formats (I should have actually said BGRA since that's windows native), loading's not your main concern but the only legitimate issue with a well written driver. The 4444 suggestion was incase you explicitly requested an 8888 internal format. An vanilla RGBA internal format token one would hope would give you something fast on a PC but if you want to be sure about it you could request a 4444 alpha token, I imagined a scenario where 32 bit RGBA was slow on your card where a 4444 format may be faster, but it's really a bit of a shot in the dark. One of several performance suggestions made based on a complaint of slow performance.
To compile code with these tokens you need an OpenGL header file that defines them, you have a Radeon so getting ATI's SDK may be the simplest option.
The internal token I would recommend trying is GL_RGBA4, if it's not in your current headers you should get some current ones I don't know if it's in gl.h or glext.h these days. Don't confuse this with extrernal formats, which also let you define 4444 packed formats and of course support the windows BGRA DIB format.
In general you need to start conducting experiments to figure out where the performance problem is arising. Nothing stops you disabling blending and even alpha testing. That may tell you if the problem lies with the texture format or with the blending. This is the kind of basic thing everyone does to performance tune their graphics application. Through a process of elimination you can narrow the problem down to the root cause.
1) What could cause the performance problem?
2) What state changes can I make to test that theory?
3) What were the results?
4) Repeat from 1)
12-12-2005, 01:13 PM
Alpha testing will reduce performance for todays GPU due to hierarchal z buffer or whatever the prefered term is. I think it would be ok with the older Geforces and Radeons.
Also, it's BGRA the prefered format for textures, but this only boost texture upload performance.
Old hardware might prefer 5-6-5 (16 bit) formats and 5-5-5-1
12-12-2005, 01:21 PM
Good point on the 5551 format that would be a GL_RGB5_A1 token, I pretty much agreed with the rest of your second part in the post I just made, but w.r.t. the first part, alpha test is probably not the problem especially with a ref of 0. Sure it disables schemes like early Z schemes on some modern cards but the problem presented here is on an older card with very simple graphics and almost no depth complexity.
My guess is texture format or blending is really hurting. That said it could be alpha test, it's certainly worth disabling it and seeing what that does to performance. If alpha test is a problem it's a more generic performance issue (e.g. lack of HW support) rather than the effect it has on a fancy zbuffer optimization.
12-13-2005, 05:14 AM
Thank you :) I'm reading the replies and i'm experimenting the results.
If i have any questions, let you know
AGBR or BGRA (or RGBA)... Where can I find some info about why using one format instead of another for best performances regarding graphic cards, drivers and the OS ?
I know NVIDIA had a document detailing the various supported formats along with recommendations. I would guess as much is true for ATI, but I haven't looked lately.
Oops! That link just lists the supported formats. There's another page at the dev site that has links to all sorts of performance related stuff. Should be easy to find.
Unfortunately, at this stage in the game we're still forced to deal with IHV-centric details like this. Hopefully, eventually, this kind of concern with be put to rest in the application arena, and only the lucky few who deal with implementations directly will have the pleasure of wallowing in the brine. Current APIs expose too many implementation details, by design and a concern for performance, but the separation is becoming more apparent all the time.
12-14-2005, 01:21 AM
As i didn't found the GL_BGRA constant in my current header file, i downloaded the NVIDIA 9.5 SDK and copied the gl header files in the GL folder of my VC++. Also i have installed the latest version of my graphics card--The graphics card that i use in my corporation is GeForce FX 5500. So is it sufficient to use from the new constants? Do i need to add some new libraries to the lib folder of my VC++ compiler?
GL_BGRA is a an extension that went core in version 1.2.
For Windows, you need to grab the extension headers "glext.h" and "wglext.h". You can find them here:
Powered by vBulletin® Version 4.2.2 Copyright © 2015 vBulletin Solutions, Inc. All rights reserved.