3dfx technology glossary/Spectre info

[TGCid]

Man... you guys need to lay off the computer and take a vacation in your backyard.

 

[PCResources]

<< Well because it is drawing more frames per second, i assume the frame buffer could not get the memory needed and draw a black frame >>



Somewhat simplified, but yes, that's it, you are a smart one, sepiroth...

Patrick Palm

Am speaking for PC Resources

 

[DaveB3D]

Are you saying you think it flips before something is in the backbuffer?

 

[Soccerman]

heh. I guess we'll just have to figure it out on our own!

 

[Rectalfier]

My understanding of 3dfx's HSR is that they are trying to remove unnecessary calculations of graphics not being displayed on the screen. For me, I would assume the drivers are buggy and they happen to also remove calculations for graphics that should be displayed resulting in a blank screen.

If any piece of hardware along the 3d graphics pipeline cannot keep up, the result would be a bottleneck and a FPS cap, not a blank screen. I am not a hardware engineer but the stuff PC Resources said does not make any sense to me.

 

[PCResources]

<< Dave doesn't know, and yet you claim to? Sounds fishy >>



Well, even Dave doesn't know everything...

But i do (irony).. ;-)

Patrick Palm

Am speaking for PC Resources

 

[Sephiroth_IX]

<< Somewhat simplified, but yes, that's it, you are a smart one, sepiroth... >>

Is that an insult or a compliment?

If that idea is correct, it's a simple driver fix to make sure that the frame buffer is filled before it gets thrown on the screen. However, this will cut framerates. I suppose we will have to see.

 

[DaveB3D]

riiiggghhhhttttt...

So then.. if you know everything, tell me how it works. I do know enough that I could tell you if you are wrong.

 

[Soccerman]

&quot;Is that an insult or a compliment?&quot;

that's a compliment..

I personally assumed the framerate would go down on WHQL drivers with this feature officially supported, however how much is not apparent to me yet.

I wait in suspence for 3dfx to release more, less buggy versions of this driver.. in other words, I still consider the problem as being driver related. ie, you CAN solve it using drivers.

the end result could be that the Voodoo 3/4/5 will receive a substantial boost in performance at high res, however not to it's max, for various reasons that I don't quite understand yet.

 

[Marty]

So its not the pixel fillrate thats eating up the bandwidth, but the framebuffer?

Marty

 

[PCResources]

<< So then.. if you know everything, tell me how it works. I do know enough that I could tell you if you are wrong. >>



Dave, i did writ (irony).

You know very well i cannot tell you how it works exactly, as i explained to you in a private message before.

Simplified, i can tell you that the memory doesn't have enough bandwidth to supply the framebuffer with sufficient data and so the framebuffer outputs a blank wich is what you experience on your monitor (with that speed, one blank equals an entire room of movement).

Patrick Palm

Am speaking for PC Resources

 

[DaveB3D]

A frame buffer in itself doesn't use bandwidth. It is accessing it that uses the bandwidth (ie. reading and writing to it).

 

[Sephiroth_IX]

No, its neither. Its the fact that the card cannot get enough bandwidth to get it to get the screen to the framebuffer, and the buffer releases a black screen because it has no data.


This is just a possible solution, it very well could be a driver problem.

 

[DaveB3D]

If that is the case... theory time here... triple buffering should help.

 

[PCResources]

<< A frame buffer in itself doesn't use bandwidth. It is accessing it that uses the bandwidth (ie. reading and writing to it). >>



I simplified it. What can i say, without going into details, the memory bandwidth is too low.

Patrick Palm

Am speaking for PC Resources

 

[DaveB3D]

Well memory bandwidth is always too low.. unless you use deferred rendering (coughGigapixelcough)...

Patrick,

the part on frame-buffer bandwidth was a reply to Marty.. nothing at you (don't want you having the wrong impression ).

 

[Sephiroth_IX]

Dave - Can you explain triple buffering? Doesnt have to be in kid terms, but try and throw me a bone here...

 

[PCResources]

<< If that is the case... theory time here... triple buffering should help. >>



Hmm, would it, if the mem-bandwidth is low then how would triple buffering help? the outcome would be the same, only worse, (1,5 black frames instead of one).

Patrick Palm

Am speaking for PC Resources

 

[PCResources]

<< Well memory bandwidth is always too low.. unless you use deferred rendering (coughGigapixelcough)... >>



Now we are going into specifics, i really cannot go into specifics about the GP tech, but if you were to use a deferred rendering engine with these drivers, well, then you might solve the problem, however, the deferred rendering (assuming software) would decrease the fillrate, so the memory bandwidth would not be needed anyway.


Patrick Palm

Am speaking for PC Resources

 

[Marty]

Thats what I meant, Dave.

Actually, if you ask me, the visual problems that we have seen (screenshot, posted by IBMer in another thread) seem as though they result from entire polygons not being rendered, instead of a normal rendering process interrupted midstream because of lack of bandwidth, if what I imagine that to look like is correct. Perhaps the HSR algorithm is not completely bug free?

PCResources, if I understand you correctly, you are saying that the visual anomolies arise when there is not enough bandwidth available to complete the drawing of the frame. However, this appears to assume an independent entity which determines the framerate. Without something dictating the framerate, the rendering would continue until it is complete, at the cost of fps. To me, it doesn't make sense for such a framerate-determining entity to exist.

Let me know if I'm completely off base, my understanding isn't as great as I would like.

Marty

 

[DaveB3D]

Well first let me explain double buffering.

Double buffering gives you two buffers, a front buffer and a back buffer. The front buffer is what you are displaying and the back buffer is being rendered to. So in other words, while you are displaying the front buffer you are rendering the back-buffer. After the back buffer is written the buffers flip. So the back buffer becomes the front buffer (what you are displaying) and you start writing the next frame to the new back buffer. The reason for doing this is so that you don't have to watch the new frame being rendered. That would look ugly.

Now the problem with this is that you can waste clock cycles. With V-sync enabled you are dependant on the refresh rate for when you can do the flip. So if your refresh rate is at 60 hz, you can only flip 60 times every second. But what if you have the ability to render 90 fps? If that happens you can still only render 60 fps and so you have idle time. So you add a second back buffer to render to. This means that you are reading the front buffer (1), writing the first back buffer (2) and when you are finished writing that buffer and you are still waiting for the buffer flip you start rendering to the second back buffer (3). So you are just trying to reduce wasted clock cycles.

 

[Marty]

When triple buffering, there is an additional buffer in memory. There are now a total of two buffers. The accelerator writes to alternating buffers, and the images in the buffers are displayed on a fifo basis. Since the buffer is emptied on a regular interval (monitor refresh rate), using triple buffering allows the accelerator to begin work on a new frame before the old one has been displayed. This allows higher framerates, and is similar in effect to diabling vsync, without the tearing.

I think that's right. Correct me if i'm wrong.

Marty

 

[Marty]

D'oh! Beaten by two minutes!

Marty

 

[DaveB3D]

Well again, I'm going off of your theory here.
My thought was this: people are saying that when they enable v-sync you reduce the bugs. Now your thought is that there is a bandwidth limitation. Now if that were the case, there would be time when this isn't so much a problem (depends on the situation). So you'll have extra cycles that are being wasted. Use those to render to a second back buffer. That allows you to have a bit of a buffer for if a problem were to come up.

 

[PCResources]

<< PCResources, if I understand you correctly, you are saying that the visual anomolies arise when there is not enough bandwidth available to complete the drawing of the frame. However, this appears to assume an independent entity which determines the framerate. Without something dictating the framerate, the rendering would continue until it is complete, at the cost of fps. To me, it doesn't make sense for such a framerate-determining entity to exist. >>



Marty, i do wish that i could tell you what i know on this matter, but i cannot.

I tried to simplify it so that i would not have to go into specifics, because i really cannot do that. The thing is, if you do not have a framerate-determining entity, then you would have maximum throughput for the chip, this is correct, but if the framebuffer is missing information then the output from the framebuffer would be a blank.

Patrick Palm

Am speaking for PC Resources