Xgl and direct rendering

[Anders Storsveen]

Matthias Hopf wrote:
> 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
>
>   
what exactly is an overlay, I've heard about Hardware Overlay, Video
Overay, Opengl Overlay, and more? what is it?