Author Topic: Case Study: Projection Transformation  (Read 2629 times)

0 Members and 1 Guest are viewing this topic.

Offline Scali

  • ASM Fanatic
  • ****
  • Posts: 1413
    • http://sourcevault.scali.eu.org
Re: Case Study: Projection Transformation
« Reply #45 on: 2012-09-19 12:46:55 »
The real point is that, of the three major transforms, we need to update them separately, and combine them in the shader, or we have to do it MANY times on the cpu, for a single scene.

Uhhh... Shaders are stateless. If you multiply inside a vertex shader, that multiply is done for EVERY vertex. Which is a LOT more often than whatever work you need to do on the CPU (which, as I said already, will mostly be hidden by the driver/bus overhead).

Example. The projection transform normally only changes if we changed the screen resolution (or just created a window). View transform changes once per frame, assuming the player wiggled a controller.

So we have already established that view*projection only changes once per frame at most... Gee, one whole matrix multiply per frame. You really think our multi-GHz, multi-core, SIMD-capable CPUs are up to that?
Not to mention that CPU and GPU work mostly asynchronously. So in many cases the CPU can work ahead and queue up work in the driver. So your matrix multiplies can be performed while the GPU is busy, which would otherwise be time wasted by the CPU waiting on the GPU anyway.

World transform needs to change once for every rendered instance of a reference mesh.. possibly several times per frame.

Oh dear, 'several times per frame'... Compared to 'everytime per vertex' (as stated, thousands to millions of times per frame). Yes, I really see where you're going with this... Wait, what?

it's usually going to be faster on the gpu

Wrong, see above.
As I already said, you are moving more workload into the innerloop.

and, we are reducing our bus bandwidth, and achieving higher framerates.

Again, wrong.
The theoretical bus savings are immaterial given the other overhead.

Perhaps you are not aware of this, but there was a time when ALL 3d mathematics were performed on the CPU. So instead of just a handful of matrix multiplies to set up shader constants, the CPU also had to do the thousands of multiplies for per-vertex T&L and all that.
I think you have completely lost all perspective here (no pun intended).

Offline Homer

  • ObjAsm32 Developer
  • Community Staff
  • ASM Fanatic
  • *****
  • Posts: 4617
  • Country: au
Re: Case Study: Projection Transformation
« Reply #46 on: 2012-09-21 08:09:47 »

Whatever you like, I've made some major advances in my advanced material based generated shader scheme, and there are still no matrices anywhere.
I'm happy with where I am going and not really interested in anything that is not constructive.
In C++, friends have access to your private members.
In ObjAsm, your members are exposed!

Offline Scali

  • ASM Fanatic
  • ****
  • Posts: 1413
    • http://sourcevault.scali.eu.org
Re: Case Study: Projection Transformation
« Reply #47 on: 2012-09-21 08:29:48 »
I'm happy with where I am going and not really interested in anything that is not constructive.

If you think optimization tips and sharing experiences with tuning performance-critical code on various platforms are not constructive, then fine. I won't waste my time on you anymore.
I just hope other people have enough common sense to steer clear of your suggestions.