Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 237860

Summary: Add support for radeonhd in /etc/make.conf
Product: Gentoo Linux Reporter: Olivier Pelerin <olivier>
Component: [OLD] UnspecifiedAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Status: RESOLVED LATER    
Severity: enhancement CC: paolo.pedroni, rickv
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Olivier Pelerin 2008-09-16 18:47:43 UTC
Radeonhd driver starts to be mature. Latest GIT version have DRI working. Mesa 7.1 or 7.2 should be compiled for r500 driver. This would give 3d acceleration.

Reproducible: Didn't try

Actual Results:  
no support

Expected Results:  
support for radeonhd in /etc/make.conf
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2008-09-16 20:33:24 UTC
Do I infer correctly that you seek to have a radeonhd USE supported in media-libs/mesa?
Comment 2 Nils Larsson 2008-09-17 20:14:22 UTC
If you build mesa with video_cards_radeon and have recent DRM kernel modules(drm.ko and radeon.ko), building and running the radeonhd driver should work. x11-base/xorg-server, the only ebuild that really cares if you use xf86-video-ati or xf86-video-radeonhd, carries the video_cards_radeonhd USE-flag.

Maybe video_cards_radeonhd(doing exactly the same as video_cards_radeon) should be added to mesa for the sake of completeness.
Comment 3 Olivier Pelerin 2008-09-19 06:36:35 UTC
Well....


I've the git version of radeonhd and I'm trying to get accelerated 3d working....

I'm using xorg-server 1.5.0 and libdrm 2.3.1.

olpeleri@kroupouk ~ $  lspci | grep ATI
01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5250]


X.org.0.log does not reveal any failures

olpeleri@kroupouk ~ $ cat /var/log/Xorg.0.log | egrep -i 'glx|acce|dri'
        X.Org Video Driver: 4.1
        X.Org XInput driver : 2.1
(II) "glx" will be loaded by default.
(II) "dri" will be loaded. This was enabled by default and also specified in the config file.
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
(II) Loading extension XFree86-DRI
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 2.1
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
(==) AIGLX enabled
(==) Exporting typical set of GLX visuals
(II) Loading extension GLX
(II) Loading /usr/lib/xorg/modules/drivers//radeonhd_drv.so
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 4.1
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 2.1
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 2.1
(II) RADEONHD: X driver for the following AMD GPG (ATI) graphics devices:
(**) RADEONHD(0): Option "DRI"
(**) RADEONHD(0): Selected XAA 2D acceleration.
(II) RADEONHD(0): Found libdri 5.4.0.
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
        ABI class: X.Org Video Driver, version 4.1
(II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x02632000 (size = 0x00C90000)
(II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x032C2000 (size = 0x00CA2000)
(II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x03F64000 (size = 0x0C000000)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(II) RADEONHD(0): [dri] Visual configs initialized
(II) RADEONHD(0): [DRI] installation complete
(II) RADEONHD(0): Using accelerated EXA DownloadFromScreen hook; GART location = 0xe0000000
(II) RADEONHD(0): Using XFree86 Acceleration Architecture (XAA)
(II) AIGLX: Screen 0 is not DRI2 capable
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: node name is /dev/dri/card0
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
(II) AIGLX: enabled GLX_texture_from_pixmap with driver support
(II) AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so
(II) GLX: Initialized DRI GL provider for screen 0
(II) Synaptics touchpad driver version 0.15.2
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 2.1

However glxinfo reveal an error

olpeleri@kroupouk ~ $ LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 4.3.0 r300 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_tls_Context)
libGL error: unable to load driver: r300_dri.so
display: :0  screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
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_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_OML_swap_method,
    GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL
OpenGL version string: 1.3 Mesa 7.2
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging,

======> It would be nice to have this radeonhd keyword taking care of what ever required to make it working.

Googling a bit it seems xorg-server need --enable-glx-tls [ I did'nt tested yet by installing manually....

Would be nice to get all this automated :-)


Comment 4 Olivier Pelerin 2008-09-19 07:27:23 UTC
mmmmh Now that I look at it again. -enable glx-tls is on in mesa and xorg... 

Still I get this glap_tls_context for any opengl based app.

olpeleri@kroupouk ~ $ LIBGL_DEBUG=verbose glxinfo | grep dri
libGL: XF86DRIGetClientDriverName: 4.3.0 r300 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_tls_Context)
libGL error: unable to load driver: r300_dri.so


Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2008-09-22 00:52:21 UTC
Er, so basically you're trying to get the portage tree to support certain features for software that is not in the tree?
Comment 6 Paolo Pedroni 2008-10-22 08:21:48 UTC
(In reply to comment #5)
> Er, so basically you're trying to get the portage tree to support certain
> features for software that is not in the tree?
> 

I don't see any software not in the tree in the request:
- mesa-7.1 in the tree
- mesa-7.2 in the tree
- xf86-video-radeonhd-1.2.3 in the tree

The only things needed would be a video_card_radonhd USE flag in mesa and in x11-drm.
Comment 7 Olivier Pelerin 2008-10-26 19:41:07 UTC
Mucking around [strace glxinfo] I saw DRI was working as root but not at user level.

It seems like libraries path are different and suid 0 seems to get the right one.

====> I did the following:


mkdir /usr/lib/xorg/i686/
sudo ln -s /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 /usr/lib/xorg/i686/libGL.so.1 

Now I have opengl working with radeonhd. Performance are decent enough to enable opengl on KDE 4.1.
kroupouk ~ # equery belongs /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2
[ Searching for file(s) /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 in *... ]
media-libs/mesa-7.2 (/usr/lib/opengl/xorg-x11/lib/libGL.so.1.2)



----> The keyword should play with some MESA paths or links







Comment 8 rick vernam 2008-12-24 08:44:02 UTC
(In reply to comment #7)
> Mucking around [strace glxinfo] I saw DRI was working as root but not at user
> level.
> 
> It seems like libraries path are different and suid 0 seems to get the right
> one.
> 
> ====> I did the following:
> 
> 
> mkdir /usr/lib/xorg/i686/
> sudo ln -s /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2
> /usr/lib/xorg/i686/libGL.so.1 
> [...snip...]

hmm, I'm not using radeonhd but I had a problem which the above two steps (almost) solved.
I'm using mesa-7.2, xorg-server-1.5.3, xf86-video-ati-6.9.0.
I had the same symptoms, and solved the problem by linking not into /usr/lib/xorg/i686, but into /usr/lib/xorg/x86_64 (of course this is b/c I'm running 64-bit).
This leaves me thinking that there is some other bug elsewhere?  But I don't really don't know...
Comment 9 Alessandro Surace 2009-09-11 13:17:24 UTC
I had the same problem with radeon driver!
And I've solved thanks to your link but changing the var LIBGL_DRIVERS_PATH before:
export LIBGL_DRIVERS_PATH="/usr/lib64/dri"
mkdir /usr/lib/xorg/x86_64
ln -s /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 /usr/lib/xorg/x86_64/libGL.so.1


(In reply to comment #8)
> (In reply to comment #7)
> > Mucking around [strace glxinfo] I saw DRI was working as root but not at user
> > level.
> > 
> > It seems like libraries path are different and suid 0 seems to get the right
> > one.
> > 
> > ====> I did the following:
> > 
> > 
> > mkdir /usr/lib/xorg/i686/
> > sudo ln -s /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2
> > /usr/lib/xorg/i686/libGL.so.1 
> > [...snip...]
> 
> hmm, I'm not using radeonhd but I had a problem which the above two steps
> (almost) solved.
> I'm using mesa-7.2, xorg-server-1.5.3, xf86-video-ati-6.9.0.
> I had the same symptoms, and solved the problem by linking not into
> /usr/lib/xorg/i686, but into /usr/lib/xorg/x86_64 (of course this is b/c I'm
> running 64-bit).
> This leaves me thinking that there is some other bug elsewhere?  But I don't
> really don't know...
>