Xgl and direct rendering

Matthias Hopf mhopf at suse.de
Tue Feb 28 10:20:49 PST 2006


On Feb 27, 06 18:53:55 +0100, Roland Scheidegger wrote:
> Rockmen Jack wrote:
> >R200 chips do have pixel shader,its version is 1.4. Glitz's shader
> >codes are assembly codes,which will be supported by R200 and above.
> R200 have direct3d pixel shader 1.4 (just as geforce3/4 have pixel
> shader 1.1/1.3) but they are useless for ARB_fragment_program. The R200 

Yes, that's what I actually meant. I'm currently unsure whether this is
enough for the color conversion and resampling code (there are
limitations with dependend texture lookups), but I guess it is. So
ATI_fragment_shader might be supported in the future as well. Though
there are more pressing issues ATM.

> but the tex instructions need some non-obvious translation, as there are 
> 3 of them but you can only access the same texture twice with ATI_fs 
> (thus you'd need to bind the "video texture" to more than one texture unit).

It should be possible by moving the texture coordinate calculation to
the main program and let the interpolation unit do the rest.
Additionally, we might have to bind the texture to two units.
I don't remember 100% of ATI's fp programming interface right now.

> R300 pixel shaders should work just fine, though I don't have such a 
> card to test.

Intel should work fine as well, fact is that one of the two color
difference channels (u or v) is missing. Otherwise it works fine.

> Both R100 and R200 (and r300, i8/9xx,...) however support yuv textures, 
> and the code should probably be modified to take advantage of them when 
> available (not very well standardized unfortunately, but 
> GL_MESA_ycbcr_texture should fit the bill). (Note that they are broken 

This is non-planar. Could work for YUY2, but not for YV12.

> on rv250 apparently, however, it should be possible to fix them up with 
> a quite simple "fragment program" as at least the component ordering 
> seems to be correct).

This is a no-go. I don't want to see any complicated code that fixes
issues for a *single* card.

> Sure, hw overlay has its limitations (usually only 1 per gpu, in case of 
> the radeons you can't have it on both screens even with mergedfb etc.) 
> but it usually gets the job done very well.

I consider hardware overlay broken by design. It has already given me
tons of nightmares.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de



More information about the xorg mailing list