Re: [1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader

[Stefan Dösinger]

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.

[1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader

[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.

[1/7] [wined3d] add ps_np2fixup_t struct to ps_compiled_shader

[Stefan Dösinger]

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.