You are not logged in.
Pages: 1
Hi,
I downloaded the above from AUR having already built libdrm-git-intel. It requires dri2proto-git as a prerequisite, but the version in AUR is out-of-date. I have dri2proto 2.6-1 installed, but the PKGFILE would need to be tweaked.
The point of this was to try out the Gallium driver as a learning exercise (trying to get my head around the different components needed for 3D graphics on Linux). I'm not sure it's worth it now though; has anyone else built mesa-full-i915g recently?
Thanks.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster"
Offline
instead of fiddling with aur, maybe check abs, and start from there.
see what the packages depend on. and start replacing the sourcecode counterparts with the git repo.
(remove the link from the source array, and clone the git repo for the said package).
once you have all set up, you can try some compile options (like enabling gallium)
ohh, dont forget to rename those packages to something meaningful too
Offline
Hi,
I downloaded the above from AUR having already built libdrm-git-intel. It requires dri2proto-git as a prerequisite, but the version in AUR is out-of-date. I have dri2proto 2.6-1 installed, but the PKGFILE would need to be tweaked.
Well, yes, it was me flagging it out of date. In reality it is not out of date, because it just builds it from git and that is always the most recent version. What is out of date is the 'dri2proto=2.3' in provides which is what pacman uses to determine the dependencies between packages. Some other package needed the package to identify with at least version 2.6 I think.
So basically two choices I gues:
- If pacman doesn't complain anywhere about dri2proto-git being only version 2.3 you should have no problems using the "out of date" package.
- Since dri2proto in the standard repository is now version 2.6 (which is sufficient for mesa git) also you should also be fine with simply changing the dependency from dri2proto-git to dri2proto in the mesa-full-i915g PKGBUILD.
The point of this was to try out the Gallium driver as a learning exercise (trying to get my head around the different components needed for 3D graphics on Linux). I'm not sure it's worth it now though; has anyone else built mesa-full-i915g recently?
Thanks.
I'm not sure if it's worth it. Some reported some advantages of the gallium driver over the classic official intel driver in this topic: https://bbs.archlinux.org/viewtopic.php?id=113603
Then google had put some work in the gallium driver for their chromebooks and that means it should have further improved since then.
Trying won't hurt.
As for learning what's needed:
I'm using r600g at the moment.
chris@chrisl ~ % pacman -Ql mesa-full-r600g
mesa-full-r600g /usr/
mesa-full-r600g /usr/include/
mesa-full-r600g /usr/include/EGL/
mesa-full-r600g /usr/include/EGL/egl.h
mesa-full-r600g /usr/include/EGL/eglext.h
mesa-full-r600g /usr/include/EGL/eglplatform.h
mesa-full-r600g /usr/include/GL/
mesa-full-r600g /usr/include/GL/gl.h
mesa-full-r600g /usr/include/GL/gl_mangle.h
mesa-full-r600g /usr/include/GL/glext.h
mesa-full-r600g /usr/include/GL/glu.h
mesa-full-r600g /usr/include/GL/glu_mangle.h
mesa-full-r600g /usr/include/GL/glx.h
mesa-full-r600g /usr/include/GL/glx_mangle.h
mesa-full-r600g /usr/include/GL/glxext.h
mesa-full-r600g /usr/include/GL/internal/
mesa-full-r600g /usr/include/GL/internal/dri_interface.h
mesa-full-r600g /usr/include/GL/osmesa.h
mesa-full-r600g /usr/include/GL/vms_x_fix.h
mesa-full-r600g /usr/include/GL/wglext.h
mesa-full-r600g /usr/include/GL/wmesa.h
mesa-full-r600g /usr/include/GLES/
mesa-full-r600g /usr/include/GLES/egl.h
mesa-full-r600g /usr/include/GLES/gl.h
mesa-full-r600g /usr/include/GLES/glext.h
mesa-full-r600g /usr/include/GLES/glplatform.h
mesa-full-r600g /usr/include/GLES2/
mesa-full-r600g /usr/include/GLES2/gl2.h
mesa-full-r600g /usr/include/GLES2/gl2ext.h
mesa-full-r600g /usr/include/GLES2/gl2platform.h
mesa-full-r600g /usr/include/KHR/
mesa-full-r600g /usr/include/KHR/khrplatform.h
mesa-full-r600g /usr/include/VG/
mesa-full-r600g /usr/include/VG/openvg.h
mesa-full-r600g /usr/include/VG/vgext.h
mesa-full-r600g /usr/include/VG/vgplatform.h
mesa-full-r600g /usr/include/VG/vgu.h
mesa-full-r600g /usr/include/gbm.h
mesa-full-r600g /usr/lib/
mesa-full-r600g /usr/lib/egl/
mesa-full-r600g /usr/lib/egl/egl_gallium.so
mesa-full-r600g /usr/lib/gbm/
mesa-full-r600g /usr/lib/gbm/gbm_gallium_drm.so
mesa-full-r600g /usr/lib/gbm/pipe_r600.so
mesa-full-r600g /usr/lib/libEGL.so
mesa-full-r600g /usr/lib/libEGL.so.1
mesa-full-r600g /usr/lib/libEGL.so.1.0
mesa-full-r600g /usr/lib/libGL.so
mesa-full-r600g /usr/lib/libGL.so.1
mesa-full-r600g /usr/lib/libGL.so.1.2
mesa-full-r600g /usr/lib/libGLESv1_CM.so
mesa-full-r600g /usr/lib/libGLESv1_CM.so.1
mesa-full-r600g /usr/lib/libGLESv1_CM.so.1.1.0
mesa-full-r600g /usr/lib/libGLESv2.so
mesa-full-r600g /usr/lib/libGLESv2.so.2
mesa-full-r600g /usr/lib/libGLESv2.so.2.0.0
mesa-full-r600g /usr/lib/libGLU.so
mesa-full-r600g /usr/lib/libGLU.so.1
mesa-full-r600g /usr/lib/libGLU.so.1.3.071200
mesa-full-r600g /usr/lib/libOSMesa.so
mesa-full-r600g /usr/lib/libOSMesa.so.7
mesa-full-r600g /usr/lib/libOSMesa.so.7.12.0
mesa-full-r600g /usr/lib/libOpenVG.so
mesa-full-r600g /usr/lib/libOpenVG.so.1
mesa-full-r600g /usr/lib/libOpenVG.so.1.0.0
mesa-full-r600g /usr/lib/libXvMCr600.so
mesa-full-r600g /usr/lib/libXvMCr600.so.1
mesa-full-r600g /usr/lib/libXvMCr600.so.1.0
mesa-full-r600g /usr/lib/libgbm.so
mesa-full-r600g /usr/lib/libgbm.so.1
mesa-full-r600g /usr/lib/libgbm.so.1.0
mesa-full-r600g /usr/lib/libglapi.so
mesa-full-r600g /usr/lib/libglapi.so.0
mesa-full-r600g /usr/lib/libglapi.so.0.0.0
mesa-full-r600g /usr/lib/libwayland-egl.so
mesa-full-r600g /usr/lib/libwayland-egl.so.1
mesa-full-r600g /usr/lib/libwayland-egl.so.1.0
mesa-full-r600g /usr/lib/pkgconfig/
mesa-full-r600g /usr/lib/pkgconfig/dri.pc
mesa-full-r600g /usr/lib/pkgconfig/egl.pc
mesa-full-r600g /usr/lib/pkgconfig/gbm.pc
mesa-full-r600g /usr/lib/pkgconfig/gl.pc
mesa-full-r600g /usr/lib/pkgconfig/glesv1_cm.pc
mesa-full-r600g /usr/lib/pkgconfig/glesv2.pc
mesa-full-r600g /usr/lib/pkgconfig/glu.pc
mesa-full-r600g /usr/lib/pkgconfig/osmesa.pc
mesa-full-r600g /usr/lib/pkgconfig/vg.pc
mesa-full-r600g /usr/lib/pkgconfig/wayland-egl.pc
mesa-full-r600g /usr/lib/vdpau/
mesa-full-r600g /usr/lib/vdpau/libvdpau_r600.so
mesa-full-r600g /usr/lib/vdpau/libvdpau_r600.so.1
mesa-full-r600g /usr/lib/vdpau/libvdpau_r600.so.1.0
mesa-full-r600g /usr/lib/xorg/
mesa-full-r600g /usr/lib/xorg/modules/
mesa-full-r600g /usr/lib/xorg/modules/dri/
mesa-full-r600g /usr/lib/xorg/modules/dri/r600_dri.so
mesa-full-r600g /usr/lib/xorg/modules/drivers/
mesa-full-r600g /usr/lib/xorg/modules/drivers/r600g_drv.so
mesa-full-r600g /usr/lib/xorg/modules/extensions/
mesa-full-r600g /usr/lib/xorg/modules/extensions/libglx.so
The files in /usr/include are probably not that important for simply running 3d, only for compiling additional software that uses mesa's headers.
The most important file is probably /usr/lib/xorg/modules/dri/r600_dri.so
With i915g it is probably called i915_dri.so or something like that.
This is the driver that the X server directly uses to render 3d.
You can tell your applications with the variable "LIBGL_DRIVERS_PATH=/usr/lib/xorg/modules/dri" where to search for this driver, just a hint if it doesn't work.
/usr/lib/xorg/modules/extensions/libglx.so has something to do with OpenGL rendering too...
If it works can best be found out with
chris@chrisl ~ % LIBGL_DEBUG=verbose glxinfo | grep render
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/r600_dri.so
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD REDWOOD
GL_MESA_window_pos, GL_NV_blend_square, GL_NV_conditional_render,
chris@chrisl ~ %
The first two lines show where the system is searching for the driver. Actually I have no idea why it searches in the tls/ subdirectory first, but as the correct directory is the second one it doesn't matter that it doesn't exist.
The driver itself connects to the kernel side of the driver via libdrm:
chris@chrisl ~ % ldd /usr/lib/xorg/modules/dri/r600_dri.so
linux-vdso.so.1 => (0x00007fffcf1e2000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f59ff394000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f59ff16b000)
libm.so.6 => /lib/libm.so.6 (0x00007f59feee8000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f59feccb000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f59feac7000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f59fe7bc000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f59fe5a6000)
libc.so.6 => /lib/libc.so.6 (0x00007f59fe246000)
librt.so.1 => /lib/librt.so.1 (0x00007f59fe03d000)
/lib/ld-linux-x86-64.so.2 (0x00007f5a00720000)
So those parts working together should be enaugh for a basic system with opengl.
Other parts of mesa as GLES (OpenGL ES, the mobile-targeted version of OpenGL) are for special purposes. But for example kwin has a backend to render desktop effects via GLES 2.
For dri2proto and glproto, I don't really know. They are somehow interfaces for the X server I guess.
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
Thanks for the very details responses. Cdh, you must have spent a long time writing this so thank you especially.
- Since dri2proto in the standard repository is now version 2.6 (which is sufficient for mesa git) also you should also be fine with simply changing the dependency from dri2proto-git to dri2proto in the mesa-full-i915g PKGBUILD.
I did that and mesa-full-i915g did build. It works after installing, in as much as I see no obvious problems! What I'm doing is trying to squeeze the most video performance I can get out of my Atom N455 netbook, which runs the 64-bit build of Arch very nicely. I also have a five or so year old Core 2 desktop with a decent (at the time) Nvidia card running the same, using the proprietary driver.
In real terms I'm a big fan of emulators (and retro-gaming in general) and like to run them full-screen with filtering and vsync enabled without cooking the CPU. This isn't always possible on a netbook, but you can't blame a guy for trying and I don't give up easily. A couple of my favourites are Stella (Atari 2600 VCS) and Fusion (Sega Genesis / Megadrive) which run really well on my desktop, but really badly on the netbook. I would just accept that the Atom processor is the weak link, but both the Windows versions of these worked fine before I installed Arch.
Interestingly, the Gallium driver seemed to fix Stella but made no difference to Fusion. I have plenty more experiments to do before I draw any conclusions; putting Windows back on my Netbook will be the last resort. Anything that uses SDL such as Vice, MAME or MESS perform just as well if not better under Arch. Hopefully this will all become clear in time and I will learn something in the process. Thanks again for the help.
Edit: I know the above aren't 3D per-se, but most emulators make use of OpenGL for hardware scaling.
Last edited by Modeler (2011-09-21 12:49:47)
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster"
Offline
Hallo everyone. I don't mean to hijack the thread, but I tried to do the same thing (build mesa-full-i915 from AUR, changing the dependency of libdrm-git to libdrm-git-intel), but it fails, saying…
Scratch that, it must have been a problem with yaourt, because when I redid it by hand ($ makepkg) it worked. I don't have any 3D now, though, which is weird, but I'll look into it more.
Last edited by GordonGR (2011-11-23 23:00:38)
Intel(R) Celeron(R) CPU E3400 @ 2.60GHz, x86_64. AURs.
“No one without the knowledge of geometry may enter.“ Plato.
Offline
Pages: 1