You are not logged in.
Hi all,
I'm trying to get hardware acceleration in Xwayland working in weston with my ATI card, but it looks like I'm failing.
I've fully updated my system, mesa, ati-dri, wayland, weston, xorg-server-xwayland (as well as xf86-video-ati for X sessions) all installed from the official repos, added xwayland.so module to weston.ini as described in the wiki.
I can launch weston using `weston-launch` from a free VT (either with or without X running on another VT, great!) w/o problems, launching X apps from within weston works, but when I run `glxinfo` to check for hardware acceleration (as suggested in previous posts), it shows the dreaded 'llvmpipe' in the renderer string.
Does this really mean Xwayland is not using hardware acceleration? Is there another way to test this?
Here are some details about my setup:
$ lspci | grep VGA
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710 [Radeon HD 4550]I know that in Xorg, this video card model doesn't use GLAMOR by default because it is 'too old' (I had to add `Option "AccelMethod" "glamor" to the "Device" section in xorg.conf to use it). Could this be related to Xwayland not activating hardware acceleration?
Here's the full log of a weston session, with libGL debug logging, with no X running (note the "glamor: EGL version 1.4 (DRI2):" line):
$ LIBGL_DEBUG=verbose weston-launch
Date: 2014-08-03 CEST
[13:26:52.330] weston 1.5.0
http://wayland.freedesktop.org/
Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.5.0
Build: 1.4.93 configure.ac: Bump version 1.4.93 (2014-05-12 12:51:52 -0700)
[13:26:52.330] OS: Linux, 3.15.8-1-ARCH, #1 SMP PREEMPT Fri Aug 1 08:51:42 CEST 2014, x86_64
[13:26:52.330] Using config file '/home/miki/.config/weston.ini'
[13:26:52.330] Loading module '/usr/lib/weston/drm-backend.so'
[13:26:52.331] initializing drm backend
[13:26:52.332] using /dev/dri/card0
[13:26:52.332] Loading module '/usr/lib/weston/gl-renderer.so'
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
[13:26:52.348] warning: EGL_EXT_swap_buffers_with_damage not supported. Performance could be affected.
[13:26:52.348] launching '/usr/lib/weston/weston-keyboard'
[13:26:52.354] input device Power Button, /dev/input/event4 is a keyboard
[13:26:52.354] input device Power Button, /dev/input/event3 is a keyboard
[13:26:52.355] input device Logitech USB Mouse, /dev/input/event0 is a pointer caps = relative-motion button
[13:26:52.355] input device USB Keyboard, /dev/input/event1 is a keyboard
[13:26:52.355] input device USB Keyboard, /dev/input/event2 is a keyboard
[13:26:52.355] not using input device '/dev/input/event6'.
[13:26:52.355] not using input device '/dev/input/event5'.
[13:26:52.390] EGL version: 1.4 (DRI2)
[13:26:52.390] EGL vendor: Mesa Project
[13:26:52.390] EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3
[13:26:52.390] EGL extensions: EGL_MESA_drm_image EGL_MESA_configless_context
EGL_WL_bind_wayland_display EGL_KHR_image_base
EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_gl_renderbuffer_image EGL_KHR_surfaceless_context
EGL_KHR_create_context EGL_EXT_buffer_age
EGL_EXT_image_dma_buf_import
[13:26:52.390] GL version: OpenGL ES 3.0 Mesa 10.2.4
[13:26:52.390] GLSL version: OpenGL ES GLSL ES 3.0
[13:26:52.390] GL vendor: X.Org
[13:26:52.390] GL renderer: Gallium 0.4 on AMD RV710
[13:26:52.390] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888
GL_OES_depth24 GL_OES_element_index_uint
GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8
GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D
GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture
GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV
GL_OES_get_program_binary GL_APPLE_texture_max_level
GL_EXT_discard_framebuffer GL_EXT_read_format_bgra
GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5 GL_EXT_texture_rg
GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
GL_EXT_map_buffer_range GL_OES_depth_texture_cube_map
GL_OES_surfaceless_context GL_EXT_color_buffer_float
GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix
[13:26:52.390] GL ES 2 renderer features:
read-back format: BGRA
wl_shm sub-image to texture: yes
EGL Wayland extension: yes
[13:26:52.390] Chosen EGL config details:
RGBA bits: 8 8 8 0
swap interval range: 0 - 0
[13:26:52.390] Failed to initialize backlight
[13:26:52.390] EDID data 'GSM', '23EA63', '308NDZJ7C597'
[13:26:52.390] Output VGA1, (connector 18, crtc 14)
mode 1920x1080@60.0, preferred, current
mode 1680x1050@60.0
mode 1400x1050@60.0
mode 1600x900@60.0
mode 1280x1024@75.0
mode 1280x1024@60.0
mode 1440x900@59.9
mode 1280x800@59.8
mode 1152x864@75.0
mode 1280x720@60.0
mode 1024x768@75.1
mode 1024x768@60.0
mode 832x624@74.6
mode 800x600@75.0
mode 800x600@60.3
mode 800x600@56.2
mode 640x480@75.0
mode 640x480@60.0
mode 720x400@70.1
[13:26:52.428] Loading module '/usr/lib/weston/desktop-shell.so'
[13:26:52.428] Loading module '/usr/lib/weston/xwayland.so'
[13:26:52.434] xserver listening on display :0
[13:26:52.434] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
[13:26:52.443] launching '/usr/lib/weston/weston-desktop-shell'
[13:26:55.958] already in the native mode
[13:27:04.602] forked X server, pid 5377
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
glamor: EGL version 1.4 (DRI2):
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
[13:27:04.831] xfixes version: 5.0
[13:27:04.842] created wm, root 368
child 5366 exited
(EE)
Fatal server error:
(EE) failed to dispatch Wayland events: Broken pipe
(EE) Here are the first few lines of output from running `glxinfo` in a terminal in weston, again with libGL debug logging:
$ LIBGL_DEBUG=verbose glxinfo
libGL: pci id for fd 4: 1002:9540, driver r600
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/r600_dri.so
libGL: driver does not expose __driDriverGetExtensions_r600(): /usr/lib/xorg/modules/dri/r600_dri.so: undefined symbol: __driDriverGetExtensions_r600
libGL error: image driver extension not found
libGL error: failed to load driver: r600
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/swrast_dri.so
libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/xorg/modules/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
libGL: Can't open configuration file /home/miki/.drirc: No such file or directory.
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
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_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample,
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_get_proc_address, 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_MESA_multithread_makecurrent,
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGI_make_current_read
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
<...snip...>Any ideas? Do I need to wait for more driver support or anything?
Offline
Acceleration for Xwayland depends on dri3 and glamor. Seems that only intel GPU works at present.
Offline
Ah, thanks for the info. Hopefully dri3 will be implemented for the other video drivers soon.
Last edited by ackalker (2014-08-05 20:11:24)
Offline
Would you happen to know of any sources as to why dri3 isn't supported on, say, radeon and nouveau? Is it just that work is needed or something is broken on those GPUs or their drivers, for instance? I too am interested in hardware acceleration in Xwayland; my thought is that if GLX can be re-written on top of wayland's EGL protocol, then HW-accelerated stuff within the Xwayland server could be passed through to the weston compositor.
Offline
Would you happen to know of any sources as to why dri3 isn't supported on, say, radeon and nouveau? Is it just that work is needed or something is broken on those GPUs or their drivers, for instance?
I don't know a lot about it. But I guess something is missing on the mesa side.
my thought is that if GLX can be re-written on top of wayland's EGL protocol, then HW-accelerated stuff within the Xwayland server could be passed through to the weston compositor.
No, that's hardly possible. It's not done that way
Offline
Would you happen to know of any sources as to why dri3 isn't supported on, say, radeon and nouveau? Is it just that work is needed or something is broken on those GPUs or their drivers, for instance? I too am interested in hardware acceleration in Xwayland; my thought is that if GLX can be re-written on top of wayland's EGL protocol, then HW-accelerated stuff within the Xwayland server could be passed through to the weston compositor.
DRI3 and glamor is in the latest nouveau which is in the Arch repos, but it still requires mesa 10.3 according to the people at #nouveau which is supposed to come out the next days.
http://cgit.freedesktop.org/nouveau/xf8 … 2c9e932e03
Last edited by blackout23 (2014-09-12 16:36:46)
Offline
No, that's hardly possible. It's not done that way
DId I misunderstand something? GLX and EGL are simply ways of obtaining an OpenGL context and binding it to the underlying window system so we can see what we render. Seeing as EGL already supports Xorg and wayland (besides others) I figured it should be a case of passing through the context calls, though I do appreciate that certain details would need to be translated from the client Xorg server's GLX extension through to the host wayland compositor.
DRI3 and glamor is in the latest nouveau which is in the Arch repos, but it still requires mesa 10.3 according to the people at #nouveau which is supposed to come out the next days.
That looks interesting... so it was already there (at least for nouveau), it just had to bubble through to stable. I will have a read, and I need to get the hang of filtering through mailing list archives ![]()
I forgot to mention however that while the info on nouveau is interesting, I would appreciate any info on radeon as that's what is in my system. (It's a Radeon HD 5450 for the curious.)
Offline
jdbrown wrote:No, that's hardly possible. It's not done that way
DId I misunderstand something? GLX and EGL are simply ways of obtaining an OpenGL context and binding it to the underlying window system so we can see what we render. Seeing as EGL already supports Xorg and wayland (besides others) I figured it should be a case of passing through the context calls, though I do appreciate that certain details would need to be translated from the client Xorg server's GLX extension through to the host wayland compositor.
The reason why EGL support X, wayland, etc. is that it is a platform-independent API, GLX isn't and it seems to need X. (If GLX is that good, why create EGL?)
Maybe I'm wrong, but that's as far as I can understand.
Offline
Ok, I've been doing some research into the subject so that I can make (slightly?) more educated observations.
The completion of DRI3 support would allow mesa to directly talk to GPUs without requiring logic in the X server (Render nodes anyone? this is what they were designed for!).
It accomplishes this by the use of DMA buffers, something for which dri3 (I forget where I read this) "makes all the pains go away".
The way I think it would work (best of my knowledge):
GL application issues render command -> GPU does rendering stuff -> DMA transfers to dma-buf -> GL application hands buffer via the PRESENT Xorg extension -> Xorg server draws buffer with everything else to screen.
(ofc extra step via wayland compositor if the X server is actually Xorg.)
Don't quote me on this, and it may well have been stated elsewhere, but I think this seems to be a major step in wayland adoption by allowing existing GLX applications full HW accel capabilities.
Offline
Just tested mesa-git from AUR. It does indeed enable DRI3 and glamor on Xwayland. glxinfo | grep renderer no longer says llvmpipe but Gallium 4.0 on NVwhatever instead.
Last edited by blackout23 (2014-09-14 11:36:58)
Offline
Awesome! Though I prefer to stick with stable for core libs (mesa is an important one all over...), so I'll wait for 10.3 to land in extra.
Another thing that comes to mind which DRI3 would help with is GL/GLES support in wayland compositors - AFAIK currently weston is designed with the old DRI model in mind (where Render and KMS are provided by a single node and only one process can control it at a time), so as well as providing DRM buffers for wayland clients weston had an extension for GL acceleration (i.e. the compositor had to support it to get accelerated rendering for clients).
With the new mesa, theoretically the concept of OpenGL applications not needing render support from the display server wouldn't just apply to X servers (whether native Xorg or Xwayland, for example), but also to wayland compositors, so we don't need to worry about which compositor we use anymore. Again, seems like a great step forward for wayland in general.
Offline