Am Dienstag, 21. April 2009 23:37:51 schrieb Tobias Jakobi:
- unsigned char idx[MAX_FRAGMENT_SAMPLERS]; /* indices to the real
constant */ I don't remember how you plan to use the ps_np2fixup_t structure in the ARB backend, but an unsigned char might turn out to be too limited if you end up storing ARB constant numbers in there, since cards can have more than 256 constants. For your GLSL code it is good enough because you just store values from 1-8.
However the FX only supports these 256 constants and every other NV card above the FX doesn't need the fixup since ARB_texture_non_power_of_two is supported in hardware.
This was my thought when limiting the index array to uchars. I know that you mentioned we could use the fixup code also for older cards, but in this case: even fewer constants.
So it doesn't make much sense for me to allow indices greater than 255.
Am Mittwoch, 22. April 2009 17:37:55 schrieb Tobias Jakobi:
However the FX only supports these 256 constants and every other NV card above the FX doesn't need the fixup since ARB_texture_non_power_of_two is supported in hardware.
This was my thought when limiting the index array to uchars. I know that you mentioned we could use the fixup code also for older cards, but in this case: even fewer constants.
So it doesn't make much sense for me to allow indices greater than 255.
I don't think we want to make such an assumption when its just a matter of using a short or an int, especially when we don't have to count single bytes(ps_compiled_shader isn't performance or size critical).
E.g. one might run across a strange Intel, Matrox or SGI GL implementation, or somebody might disable some extensions for debugging purposes and fall back to texrect on dx10 cards. (It's kinda annoying when you hit a new bug when debugging something)
It is obviously a different story with things like adding extra complicated code for handling vertex texture fetch that will most likely never be used in real life.
-
Stefan Dösinger -
Tobias Jakobi