Re: WineD3D: paletted texture emulation using fragment shaders

[Chris Robinson]

On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote:
> Hi,
>
> This patch adds 8-bit paletted texture emulation support using a fragment
> shader.

Won't this break for programs that attempt to use paletted textures and 
fragment shaders itself? If you need to emulate paletted textures, IMHO, a 
better option would be to hold the palette and 8-bit image in RAM, and just 
convert it to RGB(A) when either's changed.

Though hardware has dropped native support for paletted textures, so, also 
IMHO, that should be done on the ddraw side, instead of making all d3d apps 
think paletted textures are available.

WineD3D: paletted texture emulation using fragment shaders

[H. Verbeet]

On 17/12/06, Chris Robinson  wrote:
> Won't this break for programs that attempt to use paletted textures and
> fragment shaders itself?

For ddraw that won't be an issue, but in case of d3d I think it will,
even if the game isn't using fragment shaders itself. Calls to
DrawPrimitive will (re)bind the proper vertex / fragment shaders,
which would effectively disable the surface conversion.

AFAIK this patch is aimed at ddraw blits with 8-bit paletted surfaces,
where this would of course work just fine, but code that gets called
from LoadTexture probably isn't the right place.

A few other points:
On 16/12/06, Roderick Colenbrander  wrote:
> +static int use_fragment_program;
> +static unsigned int shader_id;

...
> - "END";
> -

These are only used inside d3dfmt_p8_upload_palette(), so they
probably shouldn't be global. Also, use_fragment_program is assigned,
but never read.
> - extensions like ARB_fragment_program and ATI_fragment_shaders

will be added as well.
> - extensions like ARB_fragment_program and ATI_fragment_shaders

will be added aswell.
"as well" is actually the proper spelling :-)
> -
>    if(!have_fragment_program)
> -
>    {
> -
>        glEnable(GL_FRAGMENT_PROGRAM_ARB);
> -
>        GL_EXTCALL(glGenProgramsARB(1, &shader_id));
> -
>        GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, shader_id));
> -
>        GL_EXTCALL(glProgramStringARB(GL_FRAGMENT_PROGRAM_ARB,

GL_PROGRAM_FORMAT_ASCII_ARB, strlen(fragment_palette_conversion),
(const GLbyte *)fragment_palette_conversion));
> -
>        glDisable(GL_FRAGMENT_PROGRAM_ARB);
> -
>        have_fragment_program=1;
> -
>    }

I don't think the glEnable()/glDisable() is required there. If it is
though, you can kill the glDisable(), and move the glEnable() above
the if-block, to save a few redundant state changes. Also, it probably
makes sense to just check if shader_id is non-zero, rather than
introducing another variable to check if the program is already
created.
> -
>    glActiveTexture(GL_TEXTURE1);

You should probably call that through GL_EXTCALL, even though I doubt
there are much pre-1.3 GL setups left.

WineD3D: paletted texture emulation using fragment shaders

[Stefan Dösinger]

Am Sonntag 17 Dezember 2006 05:06 schrieb H. Verbeet:
> On 17/12/06, Chris Robinson  wrote:
> > Won't this break for programs that attempt to use paletted textures and
> > fragment shaders itself?
>
> For ddraw that won't be an issue, but in case of d3d I think it will,
> even if the game isn't using fragment shaders itself. Calls to
> DrawPrimitive will (re)bind the proper vertex / fragment shaders,
> which would effectively disable the surface conversion.
>
> AFAIK this patch is aimed at ddraw blits with 8-bit paletted surfaces,
> where this would of course work just fine, but code that gets called

Yeah, this will only work for 2D Blits, not for 3D drawing. Even if the app 
doesn't use pixel shaders we would need a full fragment pipeline replacement 
I think.

Games that use fragment shaders and 8 bit textures at the same time should be 
pretty rare, as directx drivers dropped 8 bit support long ago. I think we 
should remove the advertisement for WINED3DFMT_P8 if the texture palette 
extension isn't available for directx8 and directx9, even though we support 
those formats. Even though the emulation via manual unpacking works, it needs 
4 times the video memory, and CPU time for unpacking. Games will fall back to 
a 16 bit texture usually. They have to deal with a lack of that format on 
windows too.

We should keep advertising it for DirectX7 and below games. Afaik all cards 
that were out when these games were written had support for P8 (well, the 
ddraw format that represents D3DFMT_P8). And if a dx8/9 game tries to use P8, 
then this should succeed, with just beeing inefficient in terms of vidmem 
usage.

WineD3D: paletted texture emulation using fragment shaders

[Stefan Dösinger]

Am Sonntag 17 Dezember 2006 04:03 schrieb Chris Robinson:
> On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote:
> > Hi,
> >
> > This patch adds 8-bit paletted texture emulation support using a fragment
> > shader.
>
> Won't this break for programs that attempt to use paletted textures and
> fragment shaders itself? If you need to emulate paletted textures, IMHO, a
> better option would be to hold the palette and 8-bit image in RAM, and just
> convert it to RGB(A) when either's changed.
>
> Though hardware has dropped native support for paletted textures, so, also
> IMHO, that should be done on the ddraw side, instead of making all d3d apps
> think paletted textures are available.

If you look at dlls/wined3d/surface.c, d3dfmt_get_conv() and 
d3dfmt_convert_surface() then you'll see that we do exactly that :-) The 
problem is that unpacking a 8 bit palettized texture to a 32 bit ARGB texture 
eats a lot of video memory and cpu time. The idea behind the blitting shader 
is to have unpacking done in the gpu and avoid eating video memory. But as 
you've correctly seen, this won't work for 3D rendering, only for 2D 
blitting.