Am Mittwoch, 22. April 2009 18:39:40 schrieb Henri Verbeet:
> > For ARB mode this is essential since something like the prog_link struct
> > from GLSL doesn't exist there.
>
> It's not terribly hard to introduce something like that. That could
> mean adding a handle table to the ARB backend, or ex
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
Henri Verbeet wrote:
> Tex fixup parameter for tex1 would have idx 0, the one for tex3 would
> have idx 1. These would then be packed as PsamplerNP2Fixup0.xy and
> PsamplerNP2Fixup0.zw.
>
OK, forget that as well.
Like I replied to Stefan about the uchar thing: The code is only active
for FX card
Henri Verbeet wrote:
> A handle table would probably make the most sense. A pointer would
> work for ARB, but for GLSL that's just extra indirection that isn't
> really needed.
Sry, I have to correct myself.
It won't work that way.
Setting up the data of the np2 fixup data struct is done in
shade
2009/4/22 Tobias Jakobi :
> Henri Verbeet wrote:
>> Sure, but it's still internal bookkeeping of the backends. Everything
>> the backend needs from the outside world is the np2_fixup field from
>> struct ps_compile_args.
>>
>>> For ARB mode this is essential since something like the prog_link struc
Henri Verbeet wrote:
> 2009/4/22 Tobias Jakobi :
>>> - Why is this in struct ps_compiled_shader? This really looks like
>>> something that should be internal to the backend.
>> No, that's definitely not the case.
>> The struct's data is used both in GLSL and ARB mode (I'll submit the ARB
>> patches
2009/4/22 Tobias Jakobi :
>> - Why is this in struct ps_compiled_shader? This really looks like
>> something that should be internal to the backend.
> No, that's definitely not the case.
> The struct's data is used both in GLSL and ARB mode (I'll submit the ARB
> patches later) - so it makes sense
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 olde
> - I'm sure I mentioned this before, but please don't add code without
> using it.
I'll merge it with one of the other patches then.
> - Why is this in struct ps_compiled_shader? This really looks like
> something that should be internal to the backend.
No, that's definitely not the case.
The str
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
2009/4/21 Tobias Jakobi :
> +struct ps_np2fixup_t {
> +unsigned char idx[MAX_FRAGMENT_SAMPLERS]; /* indices to the real
> constant */
> +GLfloat*const_cache; /* constant cache for fast reloading
> (without readback) */
> +WORDswz; /* bitfield used to determine if
11 matches
Mail list logo
