The vendor string proves that your OpenGL drivers are correctly installed. But it doesn''t prove that you use your hardware renderer. You have to check various flags in the pixelformat descriptor to be sure about that (PFD_GENERIC_GDI, PFD_ACCELERATED). Since the SetPixelFormat call can give you a non-accelerated one, if you request a feature that your hardware does not have (stencil buffer, accum buffer, stereo-buffer, etc). And then, you will still run on the MS software driver, even if the vendor string says something else.

> By highlighting the point about the csg being very slow in 16bpp on the tnt2 hardware, this shows that the speed decrease is due to the nvidia driver doing the stencil in software

Yes, it seems that the TNT2 has problems with that. But let me emphasize on that: it does *everything* in software, not only the stencil buffer, because (as pointed out) that would be impossible.

> The point being that this is the same hardware that the original poster is actually using

It is. But you had 1 fps (surely 100% software), the original poster had 20. That''s no software rendering. He must be on the hardware, the bottleneck is somewhere else.

Well, I can''t tell you, why it is that way, but if you use a TNT2-board and run a application that uses Stencil-buffers at 16bit color-depth, then it will run much slower than it runs in 32bit color-depth. BUT NOT AS SLOW, AS IT WOULD BE IN PURE SOFTWARE EMULATION!!!
I have seen this myself and you can tell me what you want, but it is that way and Maximus explanation sounds much more realistic to me, as it isn''t as slow as pure software.


Yesterday we still stood at the verge of the abyss,
today we''re a step onward!

Could be the case, I never had a TNT2.

But Maximus explanation is physically impossible, everyone with a little knowledge of about how a hardware render system works, knows that. Think about it for a second: The stencil test is in the middle of the OpenGL fragment pipeline, between the alpha test and the depth test. To do a software stencil buffer, the hardware would need to spit out *each* fragment that passed the alphatest, down the AGP bus to the CPU, the CPU would do a stencil operation and send the result back to the 3D card. The GPU would idle, waiting for the CPU. Then, it would reintegrate the fragment into the pipeline and continue processing. Lets try to oversee the fact, that implementing such a scheme in the GPU would be harder to do than a complete stencil buffer unit. But imagine the *efficiency* of that !! Can you imagine how SLOW that would be ? It would be 1000 times slower than pure software rendering ! Give me a break, and get the facts straight please.

I suspect it to be a memory access stall. Perhaps the TNT2 memory layout or access system wasn''t optimized for the 16bit rgb + stencil mode. It experienced perhaps some extreme cache misses due to bad alignment or so. This would be a plausible explanation of the effect.

To be sure, post the question on the opengl.org forum, there are several nVidia guys hanging around over there.

To the original poster.
Try this : Draw the scene, reflections and all, without using any stenciling. Keep all alpha blending the same, just comment the stencil calls. If what I''m going to say is correct, then you shouldn''t notice much difference in speed. If not, at least I tried!
The stencil setup itself takes no real performance hit, but you must realize that filling the stencil buffer requires you to render into the stencil buffer. This takes just as much processing as rendering normally (complete with all rotations/tranformations required). Then you must switch modes and render again (the stencil masked reflection). Then you must switch modes and render AGAIN (assuming you''re drawing the unreflected object last). Any time you change the active texture, performance drops, so if you draw the alpha mirror surface before you draw the other reflections, you''re hurting your speed. Also, are the reflections reflecting the other reflections? That would be another hit. Also, you must also know that the stencil buffer does not replace hidden surface removal. You still need to calculate for yourself what polys are visible, because even if the stencil buffer blocks it out, the invisible polys still went into the pipeline, even if you cannot see them.
Well I hope this helped you out some, it just sounds like you need to optimize your code.

email

Something kinda sad about
the way that things have come to be.
Desensitized to everything.
What became of subtlety?
--Tool

quote:

---

Original post by Anonymous Poster

b) ''8x anistropic'': Nvidia cards have a maximum anisotropic level of 2.

---

I just checked the OpenGL section of the driver page on my GF3 TI200, and it has 8X anisotropic filtering avaialable.

quote:

---

Original post by Anonymous Poster
And also as a side note: the standard Q2 does not use the stencil buffer.

---

Hence I edited my post with a little sidenote that Im NOT using standard quake2. Thankyou for showing your lack of observation skills.

quote:

---

Original post by Anonymous Poster
My advice: have a look at nVidia''s documents.

---

I have, many times in the past. Im not dictating how OpenGL works, just general knowledge. I only said WHAT it does not HOW it does it, and it DOES NOT use a hardware stencil buffer in 16bit colour on my geforce3, not any other nVidia card prior to it. It also DOES NOT resort to software OpenGL when Im using a stencil buffer in 16bit colour mode.

And YES my GeForce3 DOES have 8x anistropic filtering.

quote:

---

I only said WHAT it does not HOW it does it, and it DOES NOT use a hardware stencil buffer in 16bit colour on my geforce3, not any other nVidia card prior to it.

---

OF COURSE your GeForce3 uses HARDWARE stencil buffering in 16 bit mode ! It does *not* care, what rgb mode is selected, 32 or 16bit, it will *always* use 24bit z/8 bit stencil packed, such as *all* GeForce class cards, this is *hardwired* in the GPU. Just try to read out the depth/stencil buffer (using the NV_packed_depth_stencil extension) and look for yourself.
It''s hard to argue with people that obviously have no idea what they are talking about. Get a clue about how your hardware works first. Or please explain me, how this software stencil buffer is supposed to work ?

Just go to www.opengl.org, and post your idea about it there. As I said, lots of people working at nVidia hang out there, perhaps you will believe the people that actually *build* your card. But be prepared for a big LOL.

quote:

---

And YES my GeForce3 DOES have 8x anistropic filtering

---

I assumed you had another card, since you said it didn''t do HW stencil in 16bit. A GF3 does that.
BTW: what Lord Karnus suggested seems logical. You should try this first, if you have stencil buffer performance problems, instead of blaming a non-existing feature in your card/driver.

This discussion isn''t of the slighest help to the original poster. Maximus, believe whatever makes you happy to believe. End of discussion.

Kirkbag: you should follow Lord Karnus suggestion, if think it will help you.

quote:

---

Original post by Anonymous Poster
OF COURSE your GeForce3 uses HARDWARE stencil buffering in 16 bit mode ! It does *not* care, what rgb mode is selected, 32 or 16bit, it will *always* use 24bit z/8 bit stencil packed, such as *all* GeForce class cards, this is *hardwired* in the GPU. Just try to read out the depth/stencil buffer (using the NV_packed_depth_stencil extension) and look for yourself.
It''s hard to argue with people that obviously have no idea what they are talking about. Get a clue about how your hardware works first. Or please explain me, how this software stencil buffer is supposed to work ?

---

It also has an incredible slowdown with stencil under 16bit mode, just as my previous nvidia cards had. My GeForce1 had the slowdown, my TNT1 had the slowdown. They all ran faster than software GL, but slower than with hardware stencil.

And when did I say I know HOW it works? I didnt. I simply said WHAT it does, and it took someone with absolutely NOTHING better to do to sit around and start saying things about what I said that had absolutely no relevance to it. I told him a very possible way to solve his speed issue, and all you did was argue about things that I really dont give a shit about but obviously means more to you than life itself. All I say to you is this; get a life! You make the most annoying arguements against what I said for no reason but to make yourself look smart. You said some things that are clearly wrong, such as it resorting to full software opengl for 16bit mode + stencil when it clearly does not. You also said some correct things, but the fact remains that the hardware stencil buffer of the current nvidia cards only works in 32bit mode, and not in 16bit mode.

Is your objective here to be an ass to the people who try to help? Or is it just to give yourself a big head?

To both of you : please calm down.
I don''t care about who is right or wrong.
It''s not the topic.
If you want to continue to argue, then please open another thread.

Current posts do not help Kirkbag a lot.
And if this topic is closed (some Moderators can''t bear flaming), it won''t help him too.

To Kirkbag : Lord Karnus'' suggestions are worth the try.
Also, I would suggest to remove all the planes one after the other (try 0 reflecting plane, then 1 reflecting, then 2 ... up to 6) and look at how the fps goes.