Full EXA Composite For R300-500 GPUs

[phoronix]

Phoronix: Full EXA Composite For R300-500 GPUs

Alex Deucher has been working on delivering full EXA Composite support for the Radeon driver and today the first bits of this work are available via his personal git repository. The full EXA Composite not only covers the R300 and R400 generations, but it already supports the Radeon X1000 (R500) graphics cards! In Alex's blog post he mentions that some blend combinations still need to be debugged, but the R300/400 support in general is pretty solid...

http://www.phoronix.com/vr.php?view=NjM5OQ

[fragro]

cool, when will be the next stable release? (especially for ubuntu)

[Pseus]

This is great. Go devs! :)

[an0n1m0us]

This news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?

[Melcar]

This news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?


As I understand it, radeonHD does not have "official" support for anything below R400. Why would they kill it off then?

[Michael]

RE: Radeon vs. RadeonHD... There is coincidently an article going up on Phoronix tomorrow morning surrounding the debate.

The RadeonHD driver right now has basic EXA/XAA R500 support.

[yoshi314]

I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options.who told you that?

radeonhd is unlikely to extend support for pre-r500 cards, so radeon driver has a good reason to stay.

[Tillin9]

I thought the eventual goal was for radeonhd to merge back into radeon. The whole reason it exists was since drastic changes might be needed to support the newer chips, the developers thought it best to fork the current driver to avoid breaking pre-r500 chips while it evolved.

[Michael]

I thought the eventual goal was for radeonhd to merge back into radeon. The whole reason it exists was since drastic changes might be needed to support the newer chips, the developers thought it best to fork the current driver to avoid breaking pre-r500 chips while it evolved.


RadeonHD was written from scratch so there is no "merging back". AMD does want the two drivers to move, but the RadeonHD devs at least feel the drivers are far too different now to possibly merge.

[yoshi314]

i would not mind having two separate drivers. r5xx and newer have some substantial changes to 2d acceleration, and it seems pretty reasonable to have a separate driver for these cards.

[Michael]

Radeon vs. RadeonHD: http://www.phoronix.com/vr.php?view=12052

[bridgman]

This news makes very little sense. I was told in an IRC chat that the Radeon driver was dead, that it was a case of RadeonHD slowly becoming usable and the proprietary driver as the only two options. Also doesn't Alex work for AMD now? Or was that somebody else. If so, why isn't this EXA support going into RadeonHD?

This may seem confusing, but the key point to remember is that only the display hardware changed significantly between 4xx and 5xx -- for all of the other blocks, including acceleration, the hardware is pretty much unchanged between 4xx and 5xx. In driver terms, this means that only the modesetting part needs to be different and the (larger) acceleration code should be common. Unfortunately the X driver framework is not broken up that way, leaving us two alternatives :

- separate driver for newer chips, duplicate the acceleration code across the two drivers (radeonhd)
- one driver with separate modesetting code for older & newer chips, one copy of the acceleration code (radeon)

All of the acceleration work being performed recently (Textured Video, EXA rotate & blend, 3D) uses the 3D engine, which in turn requires DRI support in the driver. Today the radeon driver has DRI support but radeonhd does not, so in the short term acceleration work is being done using radeon. Adding DRI support and porting across the existing 2D & video acceleration code is top priority for radeonhd, since that will allow acceleration work to be done using radeonhd, not just in radeon.

As long as we keep the acceleration code common between the two drivers, work done in one driver will be able to immediately benefit the other anyways.

[Tillin9]

Ah, I had remembered a few quotes from the radeonhd developers along the lines of "we're trying to keep things similar to make sharing code easier" from the forum and from FOSDEM talks. I guess the drivers diverged enough for this to be no longer the case.

EDIT: Thanks for the clarification of modesetting / acceleration.

After reading today's article, my big question is which method leads to kernel-level modesetting, ideally, platform independent (non-x86) kernel-level modesetting?

I'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.

[agd5f]

i would not mind having two separate drivers. r5xx and newer have some substantial changes to 2d acceleration, and it seems pretty reasonable to have a separate driver for these cards.

Not exactly. R5xx has the same 2D core and a very similar 3D core as R3xx and R4xx chips. When we added atombios support to radeon, 2D worked out of the box on R5xx. Also, I originally added EXA Composite support for R3xx/R4xx. Since the 3D engine is so similar it was trivial to add support for R5xx. The only real difference between R5xx and the older chips is the display engine, which with atombios, was easy to support quickly.

[agd5f]

I'm a tad confused as to what AtomBIOS actually is. When I heard it being discussed before, the idea of parsing and scripts, made me think it was a way to keep the interface high-level, by passing tokens to the GPU, it then turned these into all the necessary register changes internally. Thus it not only kept the driver smaller, but let the CPU focus on other things. If that's what it does, I'm okay with using it so long as docs are released. If AtomBIOS is just a way of putting x86 blobs in firmware, i.e. the tokens are turned in x86 assembly for the CPU, I think the Novell developers are right, and it should be avoided.

It is literally a set of scripts and data tables stored in the the rom on the card. The scripts are specific to a certain tasks (turning on/off an output, setting the PLL, setting crtc timing, etc.). The atombios script interpreter in the driver decodes the scripts and programs the registers. The scripts basically break down to a list of registers and what values to program them with based on paramters you pass to the script. This allows us to write modesetting code and sort out any HW specific tweaks once (in atom code stored in the rom), then everything else (drivers, bios, etc.) is able to utilize that. Since they are scripts they can even be run even on non-x86 platforms. This allows you to post atom-based cards on powerpc or arm, etc.

[bridgman]

Ah, I had remembered a few quotes from the radeonhd developers along the lines of "we're trying to keep things similar to make sharing code easier" from the forum and from FOSDEM talks. I guess the drivers diverged enough for this to be no longer the case.

I don't think anything has changed. AFAIK we all still believe that acceleration code can be shared with relatively few changes. The two drivers store information in different data structures but it should be pretty easy to isolate those differences.

After reading today's article, my big question is which method leads to kernel-level modesetting, ideally, platform independent (non-x86) kernel-level modesetting?

Both methods could work fine for kernel modesetting. I think Dave (the kernel DRM maintainer) is leaning towards AtomBIOS because it allows the modesetting code to be smaller and require fewer changes for new GPUs, but that is more of a preference than a black/white choice.

[glisse]

Both methods could work fine for kernel modesetting. I think Dave (the kernel DRM maintainer) is leaning towards AtomBIOS because it allows the modesetting code to be smaller and require fewer changes for new GPUs, but that is more of a preference than a black/white choice.

I guess it will be atombios. Thinking backing this is that windows driver use that so it has to work, i was told that such things is obvious ;)

[Tillin9]

Thanks for all the clarification. If AtomBIOS is just a lookup table designed so that drives can be smaller and documentation needs not be at the level of set this register, then set that register, I think its more than okay. Especially if everything is being documented anyway.

Just to mention I'm eagerly waiting for kernel modesetting, I have a MIPS box I'd love to equip with an X1550. :)

[agd5f]

Thanks for all the clarification. If AtomBIOS is just a lookup table designed so that drives can be smaller and documentation needs not be at the level of set this register, then set that register, I think its more than okay. Especially if everything is being documented anyway.


We are providing the register documentation, and, on the radeon driver at least, we print out every operation in each script so you can cross reference the register guide to see exactly what it's doing if you are interested.

[mattst88]

From testing the new branch on my R480 (X800 GTO^2), it seems that scrolling is significantly faster, but dragging windows (even switching windows) is much slower than XAA.

Great work nonetheless.

[NaterGator]

I'm still doing great on EXA with AccelDFS enabled. No scrolling problems to report at all anymore. If anything, the latest git pushes to the driver have improved my stability. FPS increased by about 100 in glxgears as well. Good work! :D

[Tillin9]

The latest git pushes to the driver changed a couple of things on my Radeon 9700 Pro. Glxgears increased by 50 FPS on average. The biggest improvement is on the textured video front. Quality went up, but quality and framerate is still lower than overlay. Mainly CPU usage with textured video is 100%, while with overlay is around 30% for the same fullscreen.

[TechMage89]

I'm having issues with stuff that uses the 3d engine.

I have an x1600. When I switch on composite, the whole system freezes after a couple of seconds. I'm thinking that it's an initialization issue, because the fan on my card throttles to full speed right after the system freezes. This also happens when I try to use Xv with textured video.

Is the x1600 known not to work with this stuff yet? It seems like it might be hard to trace the problem, because no error is given and I have to hard reset my computer before it works again.

A second, somewhat more trivial (but annoying) issue is that the ati driver garbles my framebuffer console as soon as Xorg starts up, so I can't go back to text mode.

[agd5f]

I'm having issues with stuff that uses the 3d engine.

I have an x1600. When I switch on composite, the whole system freezes after a couple of seconds. I'm thinking that it's an initialization issue, because the fan on my card throttles to full speed right after the system freezes. This also happens when I try to use Xv with textured video.

Is the x1600 known not to work with this stuff yet? It seems like it might be hard to trace the problem, because no error is given and I have to hard reset my computer before it works again.

A second, somewhat more trivial (but annoying) issue is that the ati driver garbles my framebuffer console as soon as Xorg starts up, so I can't go back to text mode.

This code is still new, so there are still some bugs that need to be shaken out. Please file bugs for these issues and attach your xorg logs and configs.

https://bugs.freedesktop.org

[TechMage89]

This code is still new, so there are still some bugs that need to be shaken out. Please file bugs for these issues and attach your xorg logs and configs.

Might have to wait until after I get back from vacation. I'll get to it though, crummy ati drivers were the primary reason I've been stuck on Windows for most stuff, so I want to help improve them any way I can.

I'm hoping I might have time this summer to actually learn how the hardware and drivers work so I can contribute code myself. But right now I'm unfortuately too busy.

[whatever]

exa + composite is working really great now on my radeon 9700. no matter whether i use compiz or the old xcompmgr - scrolling and blending is f***ing fast and keeps the cpu almost idle.
thanks to all who made this possible, you are doing a great job :D

[surfer]

Hi,

After the recent work by Alex I decided to try the latest 'radeon' driver, kernel drm module, and mesa (all from git). At first I would just get an error when starting 3D:

$ glxinfo
unknown chip id 0x7100, can't guess

so I added my PCI id to the mesa source and now I get:

$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX+/3DNow!+/SSE2 NO-TCL
OpenGL version string: 1.3 Mesa 7.1
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging,
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_MESAX_texture_float, GL_ARB_texture_mirrored_repeat,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution,
GL_EXT_copy_texture, GL_EXT_draw_range_elements,
GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_packed_pixels,
GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_stencil_two_side,
GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos,
GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle,
GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format,
GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap,
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
GL_SGIS_texture_lod, GL_SGIX_depth_texture

visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None
0x6c 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None

when I try to use 3D, like glxgears, nothing shows up except a black screen where the gears should be, but the text output tells me I'm getting about 3000-4000 fps. is 3D really this close to working? any suggestions on how I can get it working on my X1800 PCIe 512MB card?

05:00.0 VGA compatible controller: ATI Technologies Inc R520 [Radeon X1800] (prog-if 00 [VGA controller])
Subsystem: ATI Technologies Inc Unknown device 0b12
Flags: bus master, fast devsel, latency 0, IRQ 21
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fd7f0000 (64-bit, non-prefetchable) [size=64K]
I/O ports at 7c00 [size=256]
[virtual] Expansion ROM at fd700000 [disabled] [size=128K]
Capabilities: <access denied>

05:00.1 Display controller: ATI Technologies Inc R520 [Radeon X1800] (Secondary)
Subsystem: ATI Technologies Inc Unknown device 0b13
Flags: fast devsel
Memory at fd7e0000 (64-bit, non-prefetchable) [disabled] [size=64K]
Capabilities: <access denied>

If you need to see my xorg.log I put a copy at:

http://www.webaccel.net/surfer/xorg.log

Any help would be appreciated.

Thanks,
Matt.

[bridgman]

The R5xx 3D support is not in the main repositories yet. Dave's blog page has links to the private branches - one for mesa and one for DRM.

As I understand it, right now the R5xx 3D code is working on RV5xx parts but has problems with R5xx parts like yours.

http://airlied.livejournal.com

Then again, it's only been running for a day so it might get better tonight ;)

[Michael]

surfer,

I tried with a 0x7100 this morning with a blank screen. but no results were shown in my case.

I had then tried with an RV515, but that too had the same problem for me.

[agd5f]

The 3D driver and EXA composite support are separate things. All you need to try out the new EXA composite is the radeon driver from git and optionally the latest drm bits for CP support. To play with r5xx 3D, you need the latest radeon bits and Dave's drm and mesa branches. Also, Dave just got it running last night, so it may or may not work for everyone yet.

[surfer]

Hi,
Using Dave's git branches...

git://anongit.freedesktop.org/~airlied/drm (branch r500-fp)
git://anongit.freedesktop.org/~airlied/mesa (branch r500test)

and the 'master' radeon driver, I can confirm that glxgears is working on my X1800! Only 4000 FPS, when FGLRX provided around 10,000 FPS. I've also noticed a few visual glitches, GLmatrix screensaver is a good example.

I had to make the following changes to get my X1800 going:

--- mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h.old 2008-03-20 22:08:07.000000000 -0700
+++ mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h 2008-03-20 21:49:18.000000000 -0700
@@ -147,6 +147,7 @@
#define PCI_CHIP_RV410_5E4D 0x5E4D
#define PCI_CHIP_RV410_5E4F 0x5E4F

+#define PCI_CHIP_R520_7100 0x7100
#define PCI_CHIP_RV530_71C4 0x71C4

#define PCI_CHIP_RS350_7834 0x7834
--- mesa/src/mesa/drivers/dri/radeon/radeon_screen.c.old 2008-03-20 22:08:18.000000000 -0700
+++ mesa/src/mesa/drivers/dri/radeon/radeon_screen.c 2008-03-20 22:29:34.000000000 -0700
@@ -693,6 +693,7 @@
fprintf(stderr, "Warning, RS690 detected, 3D support is incomplete.\n");
break;

+ case PCI_CHIP_R520_7100:
case PCI_CHIP_RV530_71C4:
screen->chip_family = CHIP_FAMILY_R520;
fprintf(stderr, "Warning, R520 detected, 3D HAHAHAHAHA!!.\n");

I'm still very excited. Myself and others are fed up with FGLRX if you need help testing or anything i can do to help with development let me know. Great work guys!

A couple side notes. Compiz is not functional (this might not surprise you). And when testing 2D with gtkperf my GtkDrawingArea test is about half the speed since last time I built the radeon driver (maybe 1-2 weeks ago). The tearing is still pretty bad with textured video. When I use the x11 vo method it doesn't get much better.

Matt.

[agd5f]

The tearing is still pretty bad with textured video. When I use the x11 vo method it doesn't get much better.


Neither method is doubled buffered or synced to vblank. until we do that there will always be potential for tearing.

[NaterGator]

Neither method is doubled buffered or synced to vblank. until we do that there will always be potential for tearing.

Is that even on the table? I always attributed it to Compiz (although compiz apparently syncs to vblank?) but if it's not...

[agd5f]

Is that even on the table? I always attributed it to Compiz (although compiz apparently syncs to vblank?) but if it's not...

We hope to get there eventually.