Radeong: What does what?

[marek]

what does radeong_drv do?

It's supposed to be a replacement for xf86-video-ati for r300 hw. Please don't use it, it's completely untested and very experimental.

-Marek

[EnglishMohican]

An update following previous help and a request for further thoughts.

Thanks for the previous help and suggestions. I am now running with r300_drv.so from Xorg git (6.13.99 apparently) and radeong plus a raft of other libraries from mesa git.

If I remember to put radeon.modeset=1 in my grub startup line I get about 1260fps from glxgears (dont scream at me!) and the following from glxinfo:-
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV410
OpenGL version string: 1.5 Mesa 7.9-devel
glu version: 1.3

Note the 1.5 Mesa.

If I forget to set up KMS, I get 2.1 Mesa on softpipe and an VMWare becomes my OpenGL vender but glxgears runs at about 24fps.

Are there any clues here that give anyone an idea as to what I have done wrong? Why can I not get 2.1 Mesa from R300. Mesa should be a late enough version to do 2.1 but I could easily have not set it up correctly. Any thoughts?

[Zhick]

Are there any clues here that give anyone an idea as to what I have done wrong? Why can I not get 2.1 Mesa from R300. Mesa should be a late enough version to do 2.1 but I could easily have not set it up correctly. Any thoughts?

I think "full" (well, not really full, but WIP) OpenGL 2.1 is only available on r500-chips. Might be wrong though.

[marek]

OpenGL 2.1 was enabled nearly 2 weeks ago for older chipsets.

[EnglishMohican]

Hurray - got there. It really does work.

OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV410
OpenGL version string: 2.1 Mesa 7.9-devel

I reckon my mistake was in not getting LIBGL_DRIVERS_PATH set up properly. I thought I had removed all of the alternative drivers but adding this in (among other things that may also have been the solution) sorted it.

For what its worth, glxgears is about 1000fps and the various mesa demo programmes seem to run very nicely with just a few seg faults that need repeating a few times to see if its me or mesa.

So as I run openSUSE on a 64bit machine with lib64 and lib directories I will have some more fun getting wine to understand what to use. As usual, anyone who has done this already is welcome to give me advice.

[nanonyme]

It's supposed to be a replacement for xf86-video-ati for r300 hw. Please don't use it, it's completely untested and very experimental.

-Marek

Wait, what? Isn't the plan to make it a replacement for all radeon hardware?

[marek]

Wait, what? Isn't the plan to make it a replacement for all radeon hardware?

From what I know, there will be separate drivers for r300 and r600. radeong is r300-only.

[nanonyme]

From what I know, there will be separate drivers for r300 and r600. radeong is r300-only.

I thought you were talking about the X.org state tracker. (which is supposed to be replacement for xf86-video-ati eventually afaik)
Obviously there will be separate Gallium drivers for r300 and r600.

[bridgman]

Guess we need to be really clear whether the discussion is about the 3D driver (aka mesa) or the X driver (aka xorg state tracker).

I think there is consensus that the Gallium3D-based 3D driver will replace the "classic" 3D driver, and that there will be one driver for 3xx-5xx and a different one for 6xx and higher. AFAIK there is no consensus yet on the final deployment of Xorg drivers (state trackers) using Gallium3D for acceleration and KMS for modesetting.

While one driver could in theory be generic across multiple hardware platforms I believe there are kernel-driver-specific API calls which differ from one set of hardware to the next, with the result that the evolution may be to use Gallium3D calls in the existing HW-specific Xorg drivers (which still gets the benefit of sharing accel code between 2D and 3D) rather than replacing the existing Xorg drivers with a new, generic driver.

[nanonyme]

While one driver could in theory be generic across multiple hardware platforms I believe there are kernel-driver-specific API calls which differ from one set of hardware to the next, with the result that the evolution may be to use Gallium3D calls in the existing HW-specific Xorg drivers (which still gets the benefit of sharing accel code between 2D and 3D) rather than replacing the existing Xorg drivers with a new, generic driver.

Well, right. Maybe "is supposed to" is an exaggerated term there. The X.org state tracker is a cute idealistic approach imo and I think it would be just fine if it became the X graphics driver but obviously I'm in no position to make any promises or predictions in that regard. Guess we'll see in a few years.