(git master 313402048fdad05d3401340129b9e412878d8957 with the patches from Bugzilla entries 75098 and 75126) When building with the following configuration: ./configure --enable-gles2 --disable-dri --enable-gallium-egl --with-egl-platforms=drm --with-gallium-drivers=i915 the following error occurs: ... Making all in gallium/targets make[2]: Entering directory `/home/christian/projects/mesa/mesa/src/gallium/targets' Making all in egl-static make[3]: Entering directory `/home/christian/projects/mesa/mesa/src/gallium/targets/egl-static' CC egl.lo CC egl_pipe.lo CC egl_st.lo make[3]: *** No rule to make target `../../../../src/gallium/winsys/i915/drm/libi915drm.la', needed by `egl_gallium.la'. Stop. Perhaps it has to do with the configuration output not having 'i915/drm' in the 'Winsys dirs' line? ----------------------------------- prefix: /usr/local exec_prefix: ${prefix} libdir: ${exec_prefix}/lib includedir: ${prefix}/include OpenGL: yes (ES1: no ES2: yes) OpenVG: no OSMesa: no GLX: no EGL: yes EGL platforms: drm EGL drivers: egl_gallium EGL Gallium STs: $(GL_LIB) llvm: no Gallium: yes Target dirs: egl-static Winsys dirs: i915/sw sw Driver dirs: galahad i915 identity noop rbug softpipe trace Trackers dirs: egl Shared libs: yes Static libs: no Shared-glapi: yes CFLAGS: -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp Macros: -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DHAVE_LIBUDEV -DHAVE_MINCORE -DMESA_EGL_NO_X11_HEADERS PYTHON2: python2
The gallium i915 is a bit special, as it's the only driver to have both sw and drm based winsys. When you disable dri, you essentially state "there will be no drm winsys", thus the makefile should handle the libraries it tries to link. I highly suspect that the issue was present since day one, just that before you were not allowed to build such a config.
I wonder if we should just remove the i915 sw winsys... I certainly don't use/test it and it's confusing (like in this case where people thing they're still getting acceleration).
So, which configuration would be the one to use for accelerated rendering on i915 without X11?
(In reply to comment #2) > I wonder if we should just remove the i915 sw winsys... I certainly don't > use/test it and it's confusing (like in this case where people thing they're > still getting acceleration). While going through glx_mesa_query_renderer I asked myself - how much i915 is used/tested nowadays ? (In reply to comment #3) > So, which configuration would be the one to use for accelerated rendering on > i915 without X11? dri does not imply X11 in this case. You should be able to run i915/drm on a X-less system.
(In reply to comment #4) > (In reply to comment #2) > > I wonder if we should just remove the i915 sw winsys... I certainly don't > > use/test it and it's confusing (like in this case where people thing they're > > still getting acceleration). > > While going through glx_mesa_query_renderer I asked myself - how much i915 > is used/tested nowadays ? I ship i915g on Chrome OS, so it is maintained. I don't encounter many issues with it, though, so there's not many commits. As for i915 + sw winsys, probably no one uses it. Maybe we should ask on the list.
(In reply to comment #4) > (In reply to comment #2) > > I wonder if we should just remove the i915 sw winsys... I certainly don't > > use/test it and it's confusing (like in this case where people thing they're > > still getting acceleration). > > While going through glx_mesa_query_renderer I asked myself - how much i915 > is used/tested nowadays ? As for my use case, I'm currently planning to upgrade our Mesa 7.8 port for the Genode OS Framework to Mesa 10. Back then, we had a spare IBM T60 notebook, so the i915 driver was the one which got ported (including the kernel part of the driver, since it is a non-Unix OS). I was not involved in the porting work then, so this topic is quite new to me and I'd like to stick with the i915 for now to limit the initial porting work to the Mesa part. The long-term goal is to support more recent hardware, though, so the i915 support is rather a temporary need. > > (In reply to comment #3) > > So, which configuration would be the one to use for accelerated rendering on > > i915 without X11? > > dri does not imply X11 in this case. You should be able to run i915/drm on a > X-less system. The latest configuration I tried was this one: ./configure --enable-gles2 --disable-glx --with-dri-drivers= --enable-gallium-egl --with-egl-platforms=drm --with-gallium-drivers=i915 but it depends on X11 headers: ---------- Making all in pipe-loader make[3]: Entering directory `/home/christian/projects/mesa/mesa/src/gallium/auxiliary/pipe-loader' CC libpipe_loader_la-pipe_loader.lo CC libpipe_loader_la-pipe_loader_sw.lo In file included from pipe_loader_sw.c:34:0: ../../../../src/gallium/include/state_tracker/xlib_sw_winsys.h:5:22: fatal error: X11/Xlib.h: No such file or directory ---------- Since I'm planning to derive the source files needed for the port from the make output, ideally there shouldn't appear any files which depend on anything X11-related. But in case there is no configuration which matches this constraint, I could also try to filter these files out later or try add such a configuration if this could be useful for others, too.
(In reply to comment #5) [snip] > I ship i915g on Chrome OS, so it is maintained. I don't encounter many > issues with it, though, so there's not many commits. As for i915 + sw > winsys, probably no one uses it. Maybe we should ask on the list. AFAICS you are the primary developer of i915 so it's only fair that you give the good news :-) (In reply to comment #6) > > (In reply to comment #3) [snip] > > dri does not imply X11 in this case. You should be able to run i915/drm on a > > X-less system. > > The latest configuration I tried was this one: > > ./configure --enable-gles2 --disable-glx --with-dri-drivers= > --enable-gallium-egl --with-egl-platforms=drm --with-gallium-drivers=i915 > > but it depends on X11 headers: > > ---------- > Making all in pipe-loader > make[3]: Entering directory > `/home/christian/projects/mesa/mesa/src/gallium/auxiliary/pipe-loader' > CC libpipe_loader_la-pipe_loader.lo > CC libpipe_loader_la-pipe_loader_sw.lo > In file included from pipe_loader_sw.c:34:0: > ../../../../src/gallium/include/state_tracker/xlib_sw_winsys.h:5:22: fatal > error: X11/Xlib.h: No such file or directory > ---------- > > Since I'm planning to derive the source files needed for the port from the > make output, ideally there shouldn't appear any files which depend on > anything X11-related. But in case there is no configuration which matches > this constraint, I could also try to filter these files out later or try add > such a configuration if this could be useful for others, too. For compilation purposes you will need the headers but as far as runtime is concerned you should be fine. Here is a snippet from nouveau_dri.so $ ldd /usr/lib/xorg/modules/dri/nouveau_dri.so linux-vdso.so.1 (0x00007fffb430a000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007faaa5096000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007faaa4e79000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007faaa4c75000) libdrm_nouveau.so.2 => /usr/lib/libdrm_nouveau.so.2 (0x00007faaa4a6d000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007faaa4861000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007faaa455d000) libm.so.6 => /usr/lib/libm.so.6 (0x00007faaa425b000) libc.so.6 => /usr/lib/libc.so.6 (0x00007faaa3eb3000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007faaa3c9d000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007faaa5c74000)
(In reply to comment #7) > For compilation purposes you will need the headers but as far as runtime is > concerned you should be fine. > Seems to be only a missing #ifdef HAVE_WINSYS_XLIB around the X11 header inclusion in pipe_loader_sw.c. With that, it builds for me. I'll test later this day. Thanks for the hints so far.
As suggested i915/sw has been disabled (and will be removed soon-ish) thus you should not be having this issue. AFAIK the header issue has been resolved as well. If you encounter another bug please file it in a separate report.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.