Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Eli Gottlieb

I need help proving this

This topic is 5354 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Me and my "friend" disagree on which is more strenous on the graphics card for 3D graphics, rasterization, or T/L? Please voice your opinion. Mine is that T/L/vertex shaders are WAY more intense than rasterization. This disagreement may result in something, as I''m trying to convince my "friend" to add h/w accel using T/L functions to his engine. void Signature(void* Pointer) { PObject(Pointer)->ShowMessage("Why do we need so many pointers?"); };

Share this post


Link to post
Share on other sites
Advertisement
In most cases, rasterization is the bottleneck. This is especially true if you''re using complex fragment shaders, or if you have so many textures that you start thrashing the cache.


"Sneftel is correct, if rather vulgar." --Flarelocke

Share this post


Link to post
Share on other sites
So between my "friend" and I, should he add h/w accelerated T/L functions to his engine?

void Signature(void* Pointer)
{
PObject(Pointer)->ShowMessage("Why do we need so many pointers?");
};

Share this post


Link to post
Share on other sites
There is absolutely no reason not to use hardware T&L if you can.


"Sneftel is correct, if rather vulgar." --Flarelocke

Share this post


Link to post
Share on other sites
I stand corrected, but I still think that my "friend" should use hardware T/L if possible. It''s the difference between running really really slow due to doing T/L in software, and going fast.

void Signature(void* Pointer)
{
PObject(Pointer)->ShowMessage("Why do we need so many pointers?");
};

Share this post


Link to post
Share on other sites
Depends... if your CPU isn''t doing ANYTHING, and you have lets say... an AMD64 FX. You probably want to do ProcessVertices() (always on the CPU), and then feed the transformed verts to the GPU. That way your pixel shaders and "vertex shaders" are running in parallel. Parallel is always good =]. But in a game that''s CPU intensive already, I''d definately push as much work as I can to the GPU.

Basically you want to find out what you''re not using, if your GPU is dyyyyyying because of all the pixel shaders, maybe you should do T/L on the CPU. But, if your CPU is dying, throw everything u can at the card.

--Navreet

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If using deferred lighting (http://www.beyond3d.com/articles/deflight/) then you could get away with transforming vertices only once (not counting shadow passes) and writing the needed data to multiple render targets (positions, normals etc). The subsequent lighting passes then basically only involves rendering a quad where the the pixel shader does all the magic. I think this method has great advantages and will be used more in the future but it is heavly fillrate limited.
Screenspace post processing is another increasingly popular technique that can increase image quality significantly and is practically fillrate only.
As others mentioned, your friend should ofcourse use T/L if available.

Share this post


Link to post
Share on other sites
but isnt it shocking to see everybody come up with new techniques that eat fillrate like chips, but everybody is worried about submitting geometry with max speed when it just doesnt matter? its like buying the most expensive and fastest car when you already know you will spend all the time in one huge traffic jam. so the one and only benefit i see is that the cpu doesnt need to feed all vertices and can just say "ey, draw that stuff over there" and go do something else.

also, as we''re talking about a pipeline. is it even remotely useful to do vertex stuff on the cpu because your gpu is having a hard time with fragment processing? i was somehow under the impression that they work in parallel, the next vertices being prepared while the last triangle is rasterized. in that case it would be pointless to do vertex processing on the cpu, as it''s "free" on the gpu if fragment processing for a triangle takes longer than vertex processing (so more or less: always).

someday i really need someone to give me an indepth explanation of whats going on in those cards.

Share this post


Link to post
Share on other sites
It is much faster, per frame, to do T&L on the graphics card instead of the CPU. However if lighting or other things are static then you should do that on the CPU so the card doesn''t repeatedly recalculate the same things each frame. So vertex lighting and lightmaps can be calculated on the CPU (or in the level editor) for static parts of the level, but anything dynamic should be done on the 3D card.

~CGameProgrammer( );

Screenshots of your games or desktop captures -- Post screenshots of your projects. There''s already 134 screenshot posts.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!