On Feb 03, 09 20:37:32 +0100, Christian König wrote:
Am Dienstag, den 03.02.2009, 14:23 -0500 schrieb Alex Deucher:
- Xv shaders could be optimized to deal with YUV formats directly rather than converting everything to nv12 That's something i wanted to do, but prio 1 on my list is currently getting AGP support more stable. Bye the way what we are going to do about tearing in Xv/3D apps (i can see allot of it with the current implementation)?
You would basically have to emit a packet that waits for vertical retrace (WAIT_REG_MEM, probably), and commit the drawing packets after that. The drawing packets should only draw quads of a certain height (say, 100 pixels), and be drawing top-down. Therefor the lowest lines will be drawn when the crtc is already scanning out the first lines of the framebuffer.
good old double buffering?
Not needed for this particular case. Effectively, XV is already double
buffering (in system memory, though).
Another thing that should be thought of are different color spaces. Even
YCbCr comes in two flavors, one has a Y range of [16,235], one has
[0,255]. If you choose the wrong one, things look ugly. The normal
(video) space uses [16,235], but that should be changeable. If black
isn't really black, or details in black areas aren't visible, you have
the wrong color space. Ah, the ranges for Cb and Cr are different as
well, of course...
As color conversion is nothing than a matrix multiplication, these
things could be controlled easily from user space (as brightness,
contrast, saturation, all only change the matrix) if the matrix is
exposed. OTOH there should be a sane default / in-driver calculation of
the matrix.
Color temperature change might be possible to be calculated by matrix
multiplication as well, if this is a homogeneous matrix. But I'm unsure
ATM.
CU
Matthias
--
Matthias Hopf