02-29-2016, 12:35 PM
I mean uses texture that contains real integer (aka not normalized value, so float). Blending is done this way (Col1 - Col2) * Factor + Col3. Operation is fully integer (likely truncated, not rounded). For example to apply a -1 on color, a game could use 127/128 as the normalized factor. (Note used by Jak&Dexter game for shadow effect)
Using integer texture coordinate could be nice too for post-processing effect to avoid strange rescale. And again, to have a rounding closer of PS2. Even, if I'm afraid that rasterizer will create others diff. (note this kind of rounding explain the blooming effect of SotC).
Integer operation will make it easier to implement destination alpha testing too. Globally it will be closer of the openCL renderer.
I think we have some room in shader power, however I'm afraid of the memory bandwidth. SW texturing will requires to fetch 4 texels instead of 1 for bilinear filtering. Load/Store from shader won't be as optimized as the ROP. Besides, I don't know the cost of the ordering synchro in HW. HBM seems like the future.
Using integer texture coordinate could be nice too for post-processing effect to avoid strange rescale. And again, to have a rounding closer of PS2. Even, if I'm afraid that rasterizer will create others diff. (note this kind of rounding explain the blooming effect of SotC).
Integer operation will make it easier to implement destination alpha testing too. Globally it will be closer of the openCL renderer.
I think we have some room in shader power, however I'm afraid of the memory bandwidth. SW texturing will requires to fetch 4 texels instead of 1 for bilinear filtering. Load/Store from shader won't be as optimized as the ROP. Besides, I don't know the cost of the ordering synchro in HW. HBM seems like the future.