Pixel Shaders : How creative are you?
- Thread starter Reverend
- Start date
Mintmaster
Veteran
Okay, regarding phong shading, you're right, traditionally it's per pixel renormalization. But your exact quote was "per-pixel phong", so I assumed you're talking about the phong lighting model applied per pixel, and the real value of this to real-time graphics quality is when used with normal maps. Still, how is phong shading without normal maps any more useful than phong shading with them? There's nothing new in your example. Even the performance will be similar on GF1/2, because you need a cube map lookup anyway for the renormalization. I never said phong = bump mapping, I just considered it a subset. That's very close to the truth.
Yes, in my first post I used "bump-mapping" when I should have used "per-pixel lighting", which are both equivalent in the way that ATI, NVidia, and others use the latter word in the context of real-time graphics. Subsequently, though, I reverted to per-pixel lighting.
As for EMBM == dependent texturing, any 2D dependent lookup can be done with EMBM using multipassing. I've clearly been talking about EMBM as a hardware feature, not solely as a bump mapping technique.
I don't see how I'm lumping meanings or wiggling out of anything. EMBM was the first form of dependent texturing. Beyond precision, the only things it lacked compared to general dependent texturing are cube and volume texture lookups on older hardware, and mipmap selection. The fundamentals are there.
Since when am I poo-pooing per-pixel lighting? If anything, I was talking about how EMBM can enhance it. Ever since I saw radiosity around a decade ago, I also strongly believed that improved lighting models are key to increasing realism in real-time games.
But we're talking about DP3 versus EMBM for shader effects. Lighting is important, but DP3 really doesn't give you a lot visually over EMBM. Ever notice the word CREATIVE in the thread title? DP3 is really just a performance optimization, since it can be done with MUL and ADD.
Now you finally mentioned other uses in PRT and PTM's, which I didn't think of when saying per-pixel lighting because, again, I was thinking about the way the term's usually used by the IHV's, especially back in 1999/2000 in the GF1/2 era. For PRT, it only helps with the monochrome version, and only by a bit. For PTM's, you save an instruction (no game usage anyway so far).
Let me try to hammer my point home one more time.
Using DP3 w/o dependent texturing allows per pixel lighting, which EMBM w/o DP3 can emulate quite well. It also speeds up some other effects.
Using only EMBM, though, allows more advanced lighting as well as a plethora of other effects.
You still haven't given any evidence to counter these statements of mine, and I've given plenty to back them up. Yet you insist on saying DP3 is far more general and useful, and is a building block for other effects, while EMBM is far more limited. I have shown you the exact opposite is true.
In fact, you mention primitive DX8 shaders, but more can be achieved or closely emulated with EMBM but not DP3. 3DMark2001 nature scene & pixel shader scene, water in Commanche4 / Tiger Woods / other games, Doom 3 heat haze, etc.
Really, DC, it comes down to this: If you tell me any DP3 effect in current games, and I should be able to make a very close approximation with EMBM. Hell, tell me any DX8 game, and I'll likely be able to emulate its graphics with EMBM. The same is not true for DP3. In terms of "shader effects", which is what this thread is about, EMBM is far more important than DP3.
Yes, in my first post I used "bump-mapping" when I should have used "per-pixel lighting", which are both equivalent in the way that ATI, NVidia, and others use the latter word in the context of real-time graphics. Subsequently, though, I reverted to per-pixel lighting.
As for EMBM == dependent texturing, any 2D dependent lookup can be done with EMBM using multipassing. I've clearly been talking about EMBM as a hardware feature, not solely as a bump mapping technique.
I don't see how I'm lumping meanings or wiggling out of anything. EMBM was the first form of dependent texturing. Beyond precision, the only things it lacked compared to general dependent texturing are cube and volume texture lookups on older hardware, and mipmap selection. The fundamentals are there.
Since when am I poo-pooing per-pixel lighting? If anything, I was talking about how EMBM can enhance it. Ever since I saw radiosity around a decade ago, I also strongly believed that improved lighting models are key to increasing realism in real-time games.
But we're talking about DP3 versus EMBM for shader effects. Lighting is important, but DP3 really doesn't give you a lot visually over EMBM. Ever notice the word CREATIVE in the thread title? DP3 is really just a performance optimization, since it can be done with MUL and ADD.
Now you finally mentioned other uses in PRT and PTM's, which I didn't think of when saying per-pixel lighting because, again, I was thinking about the way the term's usually used by the IHV's, especially back in 1999/2000 in the GF1/2 era. For PRT, it only helps with the monochrome version, and only by a bit. For PTM's, you save an instruction (no game usage anyway so far).
Let me try to hammer my point home one more time.
Using DP3 w/o dependent texturing allows per pixel lighting, which EMBM w/o DP3 can emulate quite well. It also speeds up some other effects.
Using only EMBM, though, allows more advanced lighting as well as a plethora of other effects.
You still haven't given any evidence to counter these statements of mine, and I've given plenty to back them up. Yet you insist on saying DP3 is far more general and useful, and is a building block for other effects, while EMBM is far more limited. I have shown you the exact opposite is true.
In fact, you mention primitive DX8 shaders, but more can be achieved or closely emulated with EMBM but not DP3. 3DMark2001 nature scene & pixel shader scene, water in Commanche4 / Tiger Woods / other games, Doom 3 heat haze, etc.
Really, DC, it comes down to this: If you tell me any DP3 effect in current games, and I should be able to make a very close approximation with EMBM. Hell, tell me any DX8 game, and I'll likely be able to emulate its graphics with EMBM. The same is not true for DP3. In terms of "shader effects", which is what this thread is about, EMBM is far more important than DP3.
DemoCoder said:
I'm going to pedantic here and say Phong shading, which linearly interpolated normals and light directions, probably was based around the Phong lighting model, which AFAIK didn't use a half angle vector. That was introduced by Blinn as an optimisation for the special case where (a) you could assume your light was infinitely far away (i.e. all rays are parallel) and (b) you could assume the camera was also infinitely far away.
Unfortunately, Blinn's method appears to be more expensive if you can't make those assumptions... but it appears to have become the entrenched method.
Mintmaster said:
No, GF2 does not need cube map lookup. Renormalization can be done with two combiner stages using Newton-Rhapson approximation.
And my point is, EMBM as it originally existed was not as useful as real general purpose dependent lookups. Not only because of the extra passes needed, but because early implementations were not made to run fast, and the result was havoc with memory fetch coherency and texture cache.
My point about dotproduct is that dotproduct is the fundamental vector operation of all of 3D graphics. You can't do vector calculus without dot product. Any vector or SIMD processor worth a damn has a dot-product primitive, or can use MAD. Anything you want to do, scaling, translation, projection, cross product, any arbitrary linear transformation has as its basis, dot product. (or inner product, or convolution, or whatever way you want to view it)
Both PRT and BRDF lighting can be done without dependent texture lookups, in fact, ATI released a presentation at GDC 2005 that stores most of the needed data in vertex shaders. Lots of interesting lighting was done prior to PS1.4 using just regular old interpolated texture coordinate fetches and no general purpose dependent lookups. If you look at the old GF2 NSR demos, you'll see what was possible. In fact, DOOM3 shows what was possible with multipass and DOT3/ADD/MUL on non-dependent fetch capable HW. One of the single biggest IQ advances was Polybump technique IMHO, which is still being used today in Crytec and UE3 engines.
Does this mean EMBM is useless? Or that the benefits of it that you have claimed aren't true? No. But mathematically speaking, it is more important to have dotproduct, and general purpose dependant lookup, than to have EMBM. And from the point of view of general purpose computation, people desire dotproduct-like operations in their GPUs, CPU SIMD extenions, CELL SPEs, DSPs, etc and not mega-fixed functions like EMBM.
Simon,
Yes, the reflectance vector is the real deal, but I find almost every shader I look at uses Blinn-Phong half-angle, so much so, I basically have forgotten about the reflectance vector technique.
Mintmaster
Veteran
DC, you're starting to see my points now, though you may not know it.
Any vector processor worth a damn does indeed have at least MAD, and it has been around for ages now with blending stages, at least in the form of MUL and ADD. A pair of adds will make a MAD into a DP3. I know that having a native dot product instruction is very important for speed during complex mathematical routines. But for real-time effects back in the day, EMBM was vastly more important, or at least would have been if NVidia included it, and if developers paid more attention to it. I don't know a single "wow" effect in games from 1999 up to the DX9 era that couldn't be well approximated with EMBM.
All the examples you are giving me - PRT, PTM, BRDF lighting, Polybump - can be done without DP3 either exactly (using MAD/MUL with ADD) or approximately (using EMBM), often with little performance hit. I know they don't need dependent texture lookups, and acknowledged that in my last post. I haven't seen any NSR demos that go beyond what I've been talking about. You can have DOOM3 quality using EMBM, too. Look here, for example.
DP3 is a simple math op achieved by summing components of a MUL. All those operations you mentioned have adds and multiplies as their basis. DP3 is an optimization. A matrix (translation, scaling, linear transformation, etc) multiplied by a vector can be done just as fast with MAD as with DP3. Don't see how DP3 helps cross product (today it's implemented as MUL followed by MAD using swizzling). Why in god's name would you say you can't do vector calculus without dot product when you know multiplication and add have been here for ages?
You've now qualified your assertion with "mathematically speaking", though, and I agree with you in that context. For graphical effects in games, however, especially creative ones, EMBM is far more important. These effects were just never exploited until pixel shaders came (even then very slowly), at which point fixed function EMBM wasn't used anymore.
As I've said before, EMBM was plenty fast, at least on the Radeon. 75% of the speed of GF3, which had about three times the fillrate and twice the transistors. The GF3 was no dependent texturing slouch, either. I haven't seen any good data for the Kyro or G400, though. The cache "havoc" is not nearly as bad as you think, especially for a small lighting texture.
I don't know why you so badly want to underemphasize the importance of EMBM. It was the first dependent texture ability on consumer hardware. That is a milestone far greater than some simple wiring converting a MAD to a DP3. So what if EMBM is tied to a 2x2 matrix multiplication. That makes it a mega-fixed function with little relevence? Going from EMBM to general purpose dependent texturing is not a very big step at all. Just details, really. Be more specific about why EMBM wasn't as useful as general dependent texturing. Are you talking about it not working with cube-maps?
Anyway, I think we should stop this discussion now, as we're not really bringing up any new points. In summary, this is my stance: DP3 is a natural math optimization, nothing more; in contrast, EMBM gives you 2D dependent texturing, opening a world of possibilities.
Any vector processor worth a damn does indeed have at least MAD, and it has been around for ages now with blending stages, at least in the form of MUL and ADD. A pair of adds will make a MAD into a DP3. I know that having a native dot product instruction is very important for speed during complex mathematical routines. But for real-time effects back in the day, EMBM was vastly more important, or at least would have been if NVidia included it, and if developers paid more attention to it. I don't know a single "wow" effect in games from 1999 up to the DX9 era that couldn't be well approximated with EMBM.
All the examples you are giving me - PRT, PTM, BRDF lighting, Polybump - can be done without DP3 either exactly (using MAD/MUL with ADD) or approximately (using EMBM), often with little performance hit. I know they don't need dependent texture lookups, and acknowledged that in my last post. I haven't seen any NSR demos that go beyond what I've been talking about. You can have DOOM3 quality using EMBM, too. Look here, for example.
DP3 is a simple math op achieved by summing components of a MUL. All those operations you mentioned have adds and multiplies as their basis. DP3 is an optimization. A matrix (translation, scaling, linear transformation, etc) multiplied by a vector can be done just as fast with MAD as with DP3. Don't see how DP3 helps cross product (today it's implemented as MUL followed by MAD using swizzling). Why in god's name would you say you can't do vector calculus without dot product when you know multiplication and add have been here for ages?
You've now qualified your assertion with "mathematically speaking", though, and I agree with you in that context. For graphical effects in games, however, especially creative ones, EMBM is far more important. These effects were just never exploited until pixel shaders came (even then very slowly), at which point fixed function EMBM wasn't used anymore.
As I've said before, EMBM was plenty fast, at least on the Radeon. 75% of the speed of GF3, which had about three times the fillrate and twice the transistors. The GF3 was no dependent texturing slouch, either. I haven't seen any good data for the Kyro or G400, though. The cache "havoc" is not nearly as bad as you think, especially for a small lighting texture.
I don't know why you so badly want to underemphasize the importance of EMBM. It was the first dependent texture ability on consumer hardware. That is a milestone far greater than some simple wiring converting a MAD to a DP3. So what if EMBM is tied to a 2x2 matrix multiplication. That makes it a mega-fixed function with little relevence? Going from EMBM to general purpose dependent texturing is not a very big step at all. Just details, really. Be more specific about why EMBM wasn't as useful as general dependent texturing. Are you talking about it not working with cube-maps?
Anyway, I think we should stop this discussion now, as we're not really bringing up any new points. In summary, this is my stance: DP3 is a natural math optimization, nothing more; in contrast, EMBM gives you 2D dependent texturing, opening a world of possibilities.
Mate Kovacs
Newcomer
Some more pictures:
The kanji-map wasn't too impressive, so I'm trying to make an ASCII-katakana mixed map.
The kanji-map wasn't too impressive, so I'm trying to make an ASCII-katakana mixed map.
Mintmaster
Veteran
Touche.Xmas said:Maybe because pre-shader hardware wasn't really able to swizzle vector components?Mintmaster said:
A strange way for this debate to conclude, though. I still think I could make a much, much cooler looking game on the Matrox G400 than an equal speed NV1x, though.
Mate Kovacs
Newcomer
Thx. Read the next 3 rows too! 8)DarN said: