[GPU] anisotropic settings and tex2D / tex2Dlod

I remembered that I had already encountered an issue with the ansiotropic filtering settings (see my previous post) and wanted to follow up on it.

I was doing texture lookups through indirections. The last texture was bilinearly interpolated but did not have a MIP-mapping pyramid (MIP-mapping was also disabled in the sampler). Using tex2D, strange artifacts were appearing along the texture coordinate discontinuities. (The coordinates were coming from a first texture sampled in nearest mode). It really looked as if the small explicit integration of anisotropic filtering was performed, even though filtering was disabled in the sampler. Of course, through indirection textures this integration could not work properly, thus producing artifacts. Now, the interesting part is that tex2Dlod was behaving properly. So replacing tex2D(Sampler,tc) by tex2Dlod(Sampler,float4(tc,0,0)), solved the problem. Unfortunately, tex2Dlod is usually a bit more expensive and also requires a few more instructions to set up the float4 before lookup. (A better solution might be to turn off anisotropic filtering in the driver settings - depending on whether you are planning to distribute your application or not).

[GPU] it's all in the settings

Programming GPUs is fun, but it usually comes with a few headaches. So I decided to share some of my 'GPU adventures' to hopefully provide some usefull tips, and why not serve as a starting point for future discussions.

But enough introduction. So here I am today, testing a fairly complicated pixel shader (500+ instr. of ps 3.0 code), comparing its results between a GeForce 6800 and a GeForce 7800. The great thing with the GeForce 7800 is that you double your frame rate 'for free' (of course, 'for free' refers to development time, considering the current price of the beast - as far as I am concern, it is well worth it :-).

The good news, the frame rate is high! The bad news, the result has artifacts on the GeForce 7800. "So, " - do I ask myself - " by which miracle, the same code, on almost two identical cards (at least from a functionnality point of view) using the same driver and the same version of everything else, ends up producing a different result?". And of course, I tend to suspect something's wrong in my code (good assumption in most cases - remember the last time you thought you found a compiler bug?). I must be doing something wrong resulting in an undefined behaviour, which just happens to be ok on the GeForce 6800 and not on the GeForce 7800. Or maybe the internal precision changed? (do not laugh, I have some stories! but this is an entire other subject).

Well, as it turned out - after some non neglictable amount of time spend looking for bugs in my code (which was not a total waste of time...) - the driver settings were different. Yes, the ones in the Windows properties pannel. I never really paid much attention to these, appart from antialiasing and vertical sync. And let me tell you: this was a big mistake of mine! Here you find overrides for such things as antialiasing (so far so good), anisotropic filtering (!), negative LOD bias clamp (!!). (Now I know why negative lod bias did not work). All were set on "Application controlled" on the GeForce 7800 and "Off" on the GeForce 6800. Well, turning "anisotropic filtering" off saved my day. Now, what I still don't understand, is how "application controlled" meant "On" in my case. None of my (D3D) samplers are set on anistropic filtering (most of them do not use MIPmap anyway) ... If someone happens to know, please fell free to leave a comment here.

So, anyway, my point is, go in these settings now and turn off everything you don't need right away - especially if you are using shaders for image processing purposes. The scariest one (imho) goes to ATI, since you can actually change the way the Direct3D rasterizer treats texture coordinates to make it match the OpenGL rasterizer. If you use hlsl to do image processing, you probably understand what nightmare it would be if someones happens to run your code with this setting on! (in short, texture samples would no longer be mapped 1 by 1 with render target's pixels). Note that I am not complaining about having these settings - it's great to have felxibility - I just hope there is a way to check and enforce all of these from the application. As demonstrated by my today's adventure, it does not seem to be always the case.

[game] Speed demo

I just came accross "speed demo archive" which proposes videos of players finishing a game as fast as possible. I just watched the Morrowind one, and the player finishes the game in little more than 7 minutes. Quite amazing. Of course it requires using lots of tricks and exploits that you would not know as a beginning player. Still it is interseting, especially when you played the game yourself, to see how some gameplay elements are used in new and unusual ways.

Also it is a great way to trigger good memories of your favorite games!

[game] Oblivion

I've been watching Oblivion videos. As a big fan of Daggerfall and Morrowind, I was already impatient to play this game but now .... I just can't wait!

The rendering looks great, with tons of parallax mapping, bumps, and very detailed textures. I was also quite impressed by the forest, which appears to be generated procedurally. It reminded me of the work of Thomas DiGiacomo on forest rendering, even though I don't know if Oblivion uses a similar approach.

Most of the game dungeons and environments are handcrafted (apart from the procedural forests), and I can't help thinking that synthesis methods could help the artists a great deal here. That has always been one of my researcher's dreams: automatic generation of huge realistic environment, but still driven by artist created content. I hope we'll be there one day: Imagine the games these guys at Bethesda could do with such tools!!

Anyway, that's going to be an amazing game!