*Sub-Thread* Dithering in GTA4

By this response I presume the guy is talking about the uniform texture dithering, and not the texture noise, which is something else entirely, but which people aren't differentiating between in conversation despite the noise (not the dithering) being the reason for this thread!
 
By this response I presume the guy is talking about the uniform texture dithering, and not the texture noise, which is something else entirely, but which people aren't differentiating between in conversation despite the noise (not the dithering) being the reason for this thread!

Good point...I can see the dithering you're talking about as an artistic choice (not one I'd make probably), but certainly not the noisy - garbled stuff that this thread seems focused on.
 
Would be fun to hear Rockstar about this.
It's likely that they did it because they thank that overall it fitted the game better (according to theirs tastes).
Now with all the noise around the effect (.... :LOL:) they might really question theirs tastes and feel lone.. :LOL:
 
- the reason it's not in the PS3 version is that, most likely, it would impact performance to implement it

Wow, does it mean that they wasted performance to get this dither effect in 360?! like they chose the dithered textures over a better frame rate? That's got to be the stupidest decision anyone could ever make :LOL:
 
Wow, does it mean that they wasted performance to get this dither effect in 360?! like they chose the dithered textures over a better frame rate? That's got to be the stupidest decision anyone could ever make :LOL:
There are two things going on. Maybe. :)

The grainy 'dithering" seems obviously some shader effect, that's the artistic decision and whether it costs performance depends on other factors. Maybe they were CPU constrained and had some "free" GPU cycles so they chose to implement that effect.

There's also the noisy textures (most of the closeups deal with this, an example is the text on the Burger Shot sign) that is what this thread mostly is about. It's remotely possible this is a side-effect of the above, there is some serious break-up issues involved with alpha values on textures (e.g. the billboard where big chunks of the under-structure is blasted away) but even relatively close up you can see an exaggerated noise on the text of small textures and that shouldn't be happening to that extent, so it's probably something else. Maybe they do an initial grain on the texture when they generate the mipmap variants to get it to blend better with the environment, and then it gets an extra dose with the grain shader and that's why it's so ugly.
 
Not sure. Just listen to the actual talk, 28 minutes or so in.

Thanks, Rockster! I didn't realize there was audio available for that presentation. I listened, and right at 28 minutes and 26 seconds the presenter says that, "another thing to keep in mind is that any DXT compressed textures will be uncompressed when they're brought into the texture cache".

I always thought that GPU caches stored textures in compressed form, at least since NV20, but I guess that might have been an nVidia-only optimization. Does anyone know what ATI's PC GPUs do in this regard?
 
I always thought that GPU caches stored textures in compressed form, at least since NV20, but I guess that might have been an nVidia-only optimization. Does anyone know what ATI's PC GPUs do in this regard?
Maybe nVidia patented that brilliant idea. ;)
 
I always thought that GPU caches stored textures in compressed form, at least since NV20, but I guess that might have been an nVidia-only optimization. Does anyone know what ATI's PC GPUs do in this regard?
Until R600, ATI GPUs have only had a 1 level texture cache.

It would appear that texture decompression is performed before texels are placed in Xenos's texture cache.

My understanding of the two-level cache approach is that texels are decompressed on their way from L2 to L1, meaning that L1 holds decompressed texels.

Jawed
 
Thanks, Rockster! I didn't realize there was audio available for that presentation. I listened, and right at 28 minutes and 26 seconds the presenter says that, "another thing to keep in mind is that any DXT compressed textures will be uncompressed when they're brought into the texture cache".

Until R600, ATI GPUs have only had a 1 level texture cache.
It would appear that texture decompression is performed before texels are placed in Xenos's texture cache.

My understanding of the two-level cache approach is that texels are decompressed on their way from L2 to L1, meaning that L1 holds decompressed texels.
Jawed

Intriguing. That's quite the opposite way to how I would have a texture cache function. <shrug>
 
Intriguing. That's quite the opposite way to how I would have a texture cache function. <shrug>
IIRC previous ATI architectures always assigned a single pixel pipe to predetermined screen tiles so that a L1 per pipe can probably cover the texture(s) working set on a per tile basis. A L2 on top of that would have been nice though :)
 
Intriguing. That's quite the opposite way to how I would have a texture cache function. <shrug>
This is the two-level cache architecture:

Two level cache memory architecture

Looking at figure 5 (which shows a single quad texture fetch/filter pipeline) you'll see that each L1 cache contains four instances of memory (each described as 2KB in size) corresponding with the locations of texels in the texture.

Unfortunately I can't find mention in this document of decompression. I surmise that decompression happens twixt L1 and L2 merely because L1 provides per-texel locality for feeding data to the filtering pipes.

I have to admit, reading this:

3-D rendering texture caching scheme

[0046] FIG. 3 shows a texture map that is to be stored in main memory 46 being partitioned by labeling or identifying each texel with four different identifiers. As shown, texels are labeled A, B, A, B etc. across every even row of the map and likewise C, D, C, D etc. across every odd row of the map. This organization results in an interesting relationship when bilinear interpolation is performed. After mapping a pixel into the texture map, the texture addresses to the texels that surround the mapped pixel result in a group of texels, no matter what four are selected, that will always be consisting on one A, one B, one C, one D type of texel. This allows the organization of texel types in cache memory to be in banks so that all four texels that are needed for a pixel can be accessed in one dock cycle. This is accomplished by putting all A types in one bank, all B types in another bank, C types in a third bank, and D types in a fourth bank. The mapping of pixel 48 into texture map 46 is an example showing that one of each texel type will be selected for bilinear interpolation.
and considering that the base design for R600 is fp16 texels (which aren't compressed) I'm now thinking that decompression is performed for DXT etc. before the texels are put into L2.

Jawed
 
IIRC previous ATI architectures always assigned a single pixel pipe to predetermined screen tiles so that a L1 per pipe can probably cover the texture(s) working set on a per tile basis. A L2 on top of that would have been nice though :)

What I meant was, caching raw memory (i.e. compressed textures) VS decompressed 8888 means that your texture cache effectively becomes 4~8x larger. <shrug>
 
IIRC previous ATI architectures always assigned a single pixel pipe to predetermined screen tiles so that a L1 per pipe can probably cover the texture(s) working set on a per tile basis. A L2 on top of that would have been nice though :)
Hmm, yeah, Xenos is stuck with the kind of texturing that RV610/620 have (no L2 at all).

Jawed
 
What I meant was, caching raw memory (i.e. compressed textures) VS decompressed 8888 means that your texture cache effectively becomes 4~8x larger. <shrug>
Yeah, I took that as read. It appears as if, historically, ATI's been averse to building multiple copies of decompression units per quad-texturing unit.

Jawed
 
GTA has had an auto-update on both platforms. The shadows look softer and less grainy to me but I could be talking nonsense.
 
Back
Top