Initial Radeon R6xx/R7xx acceleration support pushed
It's finally here! r6xx-r7xx-support branches of the drm and xf86-video-radeonhd. http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/log/?h=r6xx-r7xx... After months of hard work we are finally able to push out initial drm and accel code for r6xx and r7xx chipsets. We couldn't have done this without a lot of hard work from a lot of people. Of particular note: Matthias Hopf - implementing r600_demo as a test program to get the hw up and running Dave Airlie - initial r6xx drm implementation John Bridgman - sheparding along the IP review process This release is mostly targeted at developers as the code is not really ready for regular use. The accompanying r6xx/r7xx register spec is still in IP review and will be released soon. Current drm status: - only indirect ioctl currently implemented (for EXA/Xv) - mesa support will require additional work Current EXA/Xv status: - lack of direction blitter makes overlapping copy blits difficult. current code breaks down overlapping blits into line by line blits of non-overlapping regions. running xcompmgr -a is highly recommended for decent performance - a8 support has issues - planar Xv shader implemented, but not working properly yet - missing Xv shader support for packed formats. should be easy to adapt the planar Xv shader once that is working - composite mask support is currently broken. I suspect the interpolater setup. - depth 16 is untested Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Just to clarify for those that want to play with this, you'll need to
build the r6xx-r7xx-support branches of the drm and radeonhd. The drm
is also required for r600_demo.
Alex
On Mon, Dec 29, 2008 at 4:33 PM, Alex Deucher
It's finally here! r6xx-r7xx-support branches of the drm and xf86-video-radeonhd.
http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/log/?h=r6xx-r7xx...
After months of hard work we are finally able to push out initial drm and accel code for r6xx and r7xx chipsets. We couldn't have done this without a lot of hard work from a lot of people. Of particular note:
Matthias Hopf - implementing r600_demo as a test program to get the hw up and running Dave Airlie - initial r6xx drm implementation John Bridgman - sheparding along the IP review process
This release is mostly targeted at developers as the code is not really ready for regular use. The accompanying r6xx/r7xx register spec is still in IP review and will be released soon.
Current drm status: - only indirect ioctl currently implemented (for EXA/Xv) - mesa support will require additional work
Current EXA/Xv status: - lack of direction blitter makes overlapping copy blits difficult. current code breaks down overlapping blits into line by line blits of non-overlapping regions. running xcompmgr -a is highly recommended for decent performance - a8 support has issues - planar Xv shader implemented, but not working properly yet - missing Xv shader support for packed formats. should be easy to adapt the planar Xv shader once that is working - composite mask support is currently broken. I suspect the interpolater setup. - depth 16 is untested
Alex
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi Alex, first of all: A very big THANK YOU to everybody involved. Ok, now to the hard work getting this up and running: Radeonhd won't even compile after i checked out the r6xx-r7xx-support branch. Digging into it i found that gcc is complaining about function declaration and definition mismatch in r600_state.h and r6xx_accel.c. When i take a look into r600_state.h i can see prototypes for a bunch of inline functions: inline void e32(drmBufPtr ib, uint32_t dword); inline void efloat(drmBufPtr ib, float f); inline void pack3(drmBufPtr ib, int cmd, unsigned num); inline void pack0 (drmBufPtr ib, uint32_t reg, int num); inline void ereg (drmBufPtr ib, uint32_t reg, uint32_t val); I don't really know why gcc is complaining about a declaration mismatch here, but after moving those functions into the header file and commenting out draw_immd in the header file the code seems to compile fine. I'm using gcc version 4.3.2 with X.Org X Server 1.5.99.3. Both from Ubuntu Jaunty (9.04 Beta). A patch with my changes to radeonhd sources is attached, hoping this will help cleaning up the code a little bit. After compiling and installing the driver seems to work normal (without dri). so i started to get the drm code compiled. After realising that the Ubuntu standard kernel doesn't compile drm as a module i compiled my own 2.6.28 kernel. Now the drm modules compile and load quite fine. After adding the DRI option to my xorg.conf and firing up the xserver i get a nice kernel oops in r600_do_init_cp. And that's the point where i'm stuck. Because i am not familiar with the drm code and haven't programmed inside the kernel for years. Output of dmesg and lspci is attached, do you need anything else? or have an idea what's going wrong? Bye, Christian.
On Tue, Dec 30, 2008 at 7:07 AM, Christian König
Hi Alex,
first of all: A very big THANK YOU to everybody involved.
Ok, now to the hard work getting this up and running: Radeonhd won't even compile after i checked out the r6xx-r7xx-support branch. Digging into it i found that gcc is complaining about function declaration and definition mismatch in r600_state.h and r6xx_accel.c.
When i take a look into r600_state.h i can see prototypes for a bunch of inline functions: inline void e32(drmBufPtr ib, uint32_t dword); inline void efloat(drmBufPtr ib, float f); inline void pack3(drmBufPtr ib, int cmd, unsigned num); inline void pack0 (drmBufPtr ib, uint32_t reg, int num); inline void ereg (drmBufPtr ib, uint32_t reg, uint32_t val);
I don't really know why gcc is complaining about a declaration mismatch here, but after moving those functions into the header file and commenting out draw_immd in the header file the code seems to compile fine. I'm using gcc version 4.3.2 with X.Org X Server 1.5.99.3. Both from Ubuntu Jaunty (9.04 Beta). A patch with my changes to radeonhd sources is attached, hoping this will help cleaning up the code a little bit.
After compiling and installing the driver seems to work normal (without dri). so i started to get the drm code compiled. After realising that the Ubuntu standard kernel doesn't compile drm as a module i compiled my own 2.6.28 kernel. Now the drm modules compile and load quite fine.
After adding the DRI option to my xorg.conf and firing up the xserver i get a nice kernel oops in r600_do_init_cp. And that's the point where i'm stuck. Because i am not familiar with the drm code and haven't programmed inside the kernel for years.
Output of dmesg and lspci is attached, do you need anything else? or have an idea what's going wrong?
Looks like you have an AGP card. Those aren't supported at the moment (PCIE only). I should probably add a check to the ddx to not try and init the drm until we have r6xx AGP support. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Happy new year, Am Dienstag, den 30.12.2008, 10:41 -0500 schrieb Alex Deucher:
Looks like you have an AGP card. Those aren't supported at the moment (PCIE only). I should probably add a check to the ddx to not try and init the drm until we have r6xx AGP support.
I already figured this out myself, so i started hacking the drm code a little bit: I adjusted all calculations with the pcigart scatter-gather address within r600_cp.c to match the one in radeon_cp.c, this fixed the kernel oops and even allows xserver with xvideo support to start. Playing some MPEG with mplayer displays something which looks like random pixel data, so i think the only thing missing is programming the agpgart addresses into the hardware, but here my knowledge really stops. A patch is attached, is AGP support something witch is showing up soon? I can't wait to crash the xserver while watch videos with xv, and start hacking the hardware directly. Bye, Christian.
On Dec 30, 08 10:41:43 -0500, Alex Deucher wrote:
Looks like you have an AGP card. Those aren't supported at the moment (PCIE only). I should probably add a check to the ddx to not try and init the drm until we have r6xx AGP support.
Alex, is this a DRM only issue? It's also possible that AGP isn't
working correctly in radeonhd, I *think* I added code for AGP, but that
has never been verified.
We now have an AGP r6xx card here, so I can eventually verify.
Matthias
--
Matthias Hopf
On Dec 30, 08 10:41:43 -0500, Alex Deucher wrote:
Looks like you have an AGP card. Those aren't supported at the moment (PCIE only). I should probably add a check to the ddx to not try and init the drm until we have r6xx AGP support.
Alex, is this a DRM only issue? It's also possible that AGP isn't working correctly in radeonhd, I *think* I added code for AGP, but that has never been verified.
We now have an AGP r6xx card here, so I can eventually verify. i don't know if it helps, but attached is a r600_demo output i created with my hacked drm code. It looks like the memory controller gets stuck when a command processor script is run, but still my knowledge of all of
Hi, Am Freitag, den 02.01.2009, 19:00 +0100 schrieb Matthias Hopf: this is very limited. And by the way: I think i can get a HP Notebook with an radeon chipset on Monday. I will prepare a usb drive with an working linux environment till then and test it on any system i can get my hand on in the office, so prepare for some results :) Bye, Christian.
On Fri, Jan 2, 2009 at 1:00 PM, Matthias Hopf
On Dec 30, 08 10:41:43 -0500, Alex Deucher wrote:
Looks like you have an AGP card. Those aren't supported at the moment (PCIE only). I should probably add a check to the ddx to not try and init the drm until we have r6xx AGP support.
Alex, is this a DRM only issue? It's also possible that AGP isn't working correctly in radeonhd, I *think* I added code for AGP, but that has never been verified.
The AGP/PCIE detection in the ddx should be fine. We need to add AGP support to the drm. Christian's patch looks like a good start. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Dec 30, 2008 at 7:07 AM, Christian König
Hi Alex,
first of all: A very big THANK YOU to everybody involved.
Ok, now to the hard work getting this up and running: Radeonhd won't even compile after i checked out the r6xx-r7xx-support branch. Digging into it i found that gcc is complaining about function declaration and definition mismatch in r600_state.h and r6xx_accel.c.
When i take a look into r600_state.h i can see prototypes for a bunch of inline functions: inline void e32(drmBufPtr ib, uint32_t dword); inline void efloat(drmBufPtr ib, float f); inline void pack3(drmBufPtr ib, int cmd, unsigned num); inline void pack0 (drmBufPtr ib, uint32_t reg, int num); inline void ereg (drmBufPtr ib, uint32_t reg, uint32_t val);
I don't really know why gcc is complaining about a declaration mismatch here, but after moving those functions into the header file and commenting out draw_immd in the header file the code seems to compile fine. I'm using gcc version 4.3.2 with X.Org X Server 1.5.99.3. Both from Ubuntu Jaunty (9.04 Beta). A patch with my changes to radeonhd sources is attached, hoping this will help cleaning up the code a little bit.
This should be fixed in git. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Alex Deucher wrote:
It's finally here! r6xx-r7xx-support branches of the drm and xf86-video-radeonhd.
http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/log/?h=r6xx-r7xx...
After months of hard work we are finally able to push out initial drm and accel code for r6xx and r7xx chipsets. We couldn't have done this without a lot of hard work from a lot of people. Of particular note:
Matthias Hopf - implementing r600_demo as a test program to get the hw up and running Dave Airlie - initial r6xx drm implementation John Bridgman - sheparding along the IP review process
This release is mostly targeted at developers as the code is not really ready for regular use. The accompanying r6xx/r7xx register spec is still in IP review and will be released soon.
Yay! Exciting! Congrats and thanks to everyone who made this possible. I'm a dev by trade and I'd be quite happy to test it on my system (R770) and provide reports, or would you only recommend this for people who actually want to hack on it? n -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Dec 30, 2008 at 8:39 PM, Nigel Rantor
Alex Deucher wrote:
It's finally here! r6xx-r7xx-support branches of the drm and xf86-video-radeonhd.
http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support
http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/log/?h=r6xx-r7xx...
After months of hard work we are finally able to push out initial drm and accel code for r6xx and r7xx chipsets. We couldn't have done this without a lot of hard work from a lot of people. Of particular note:
Matthias Hopf - implementing r600_demo as a test program to get the hw up and running Dave Airlie - initial r6xx drm implementation John Bridgman - sheparding along the IP review process
This release is mostly targeted at developers as the code is not really ready for regular use. The accompanying r6xx/r7xx register spec is still in IP review and will be released soon.
Yay! Exciting!
Congrats and thanks to everyone who made this possible.
I'm a dev by trade and I'd be quite happy to test it on my system (R770) and provide reports, or would you only recommend this for people who actually want to hack on it?
It's not particularly useful for end users at the moment. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Dec 30, 08 22:12:24 -0500, Alex Deucher wrote:
I'm a dev by trade and I'd be quite happy to test it on my system (R770) and provide reports, or would you only recommend this for people who actually want to hack on it?
It's not particularly useful for end users at the moment.
Alex's right - at this particular point nothing of this code is
particularly useful for users. OTOH, if you love experimenting, testing
r600_demo could be useful. RV770 works fine here, so in case anybody
finds that it doesn't work for his/her card, a report would be welcome.
Also, so far nobody verified on notebook chipsets (RS780 is the only
one, AFAIK) - but you would need to hack r600_demo.c a bit with the PCI
IDs at least.
Matthias
--
Matthias Hopf
participants (4)
-
Alex Deucher -
Christian König -
Matthias Hopf -
Nigel Rantor