Hi Clemens and Matthias,
Hi,
Great that you are interested in enhancing the R600 driver :)
Well, XAA has more or less been declared as "dead", intel plans for a long time to get rid of it. I would not recommend putting effort into it, its just not well suited for todays requirements.
Two other interesting (but I guess hard parts) but be Gradient and Trapezoid accaleration for EXA ;)
Thanks again for working on it, Clemens
Ok, then it's wasted time to start with XAA. I think my time is better used when helping in some oss project then do some other senseless stuff. ;-) And I'm totally pissed of about closed source drivers since years.
XAA is. Read Alex r6xx-r7xx-support branch, it contains EXA acceleration, or better, a start of EXA. That will give you some ideas.
I'll be working on Mesa next week again, this week I have to prepare two FOSDEM talks...
Ok, I think I speak with Alex. Maybe he can give me some tasks. Have fun on FOSDEM (I have no time to go there :/)! Kind regards Manuel -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Feb 3, 2009 at 2:00 PM, manuel gysin
Hi Clemens and Matthias,
Hi,
Great that you are interested in enhancing the R600 driver :)
Well, XAA has more or less been declared as "dead", intel plans for a long time to get rid of it. I would not recommend putting effort into it, its just not well suited for todays requirements.
Two other interesting (but I guess hard parts) but be Gradient and Trapezoid accaleration for EXA ;)
Thanks again for working on it, Clemens
Ok, then it's wasted time to start with XAA. I think my time is better used when helping in some oss project then do some other senseless stuff. ;-) And I'm totally pissed of about closed source drivers since years.
XAA is. Read Alex r6xx-r7xx-support branch, it contains EXA acceleration, or better, a start of EXA. That will give you some ideas.
I'll be working on Mesa next week again, this week I have to prepare two FOSDEM talks...
Ok, I think I speak with Alex. Maybe he can give me some tasks. Have fun on FOSDEM (I have no time to go there :/)!
Your best bet for playing with accel stuff is the EXA/Xv code. There are still some issues with it: - Using shader constants on r7xx seems to cause lockups in some cases - Some corruption with text and small pixmaps (I think this is cache flush related) and there is a lot of room for optimization: - Xv shaders could be optimized to deal with YUV formats directly rather than converting everything to nv12 - Overlapping blits could be optimized (currently done line by line) - Add support for UploadToScreen() and DownloadFromScreen() EXA hooks (basically a textured blit to/from a gart buffer to/from vram) Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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)? good old double buffering? or does this hardware support something more featured?
Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Feb 3, 2009 at 2:37 PM, Christian König
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)? good old double buffering? or does this hardware support something more featured?
For video, I'd say stalling on vline like we did in radeon for older asics. For 3D we can use one of the vblank GL extensions and for 3D with composite we'll need DRI2. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
Hi Alex,
Your best bet for playing with accel stuff is the EXA/Xv code. There are still some issues with it:
- Using shader constants on r7xx seems to cause lockups in some cases - Some corruption with text and small pixmaps (I think this is cache flush related) ... - Add support for UploadToScreen() and DownloadFromScreen() EXA hooks (basically a textured blit to/from a gart buffer to/from vram)
Alex
I will start within these points. Maybe I can fix something or add stuff. Do you have more information about the two issues? I played around two days with the driver and never had a lockup or corruption with text or pixmaps. Only the r600 demo goes sometimes crazy. ;-) I'm using a radeon 4870 btw. If I find something, I will send the patches to the mailing list. Kind regards Manuel -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (5)
-
Alex Deucher
-
Christian König
-
gwydion.dot@morrigan.ch
-
manuel gysin
-
Matthias Hopf