problems for DRI/mesa from GIT source

Beeblebrox

Beeblebrox

I am trying to build mesa (and dependents) from git repository, but several things have me completely confused:

1. I don't understand this message:
Code: 
Your system supports OpenGL version "1.2 Mesa 7.6.1" application needs at least version 1.3 to work
2. Some of the versions from GIT are same or even behind version in ports. I am thinking of dumping git and switching to ports for those equal versions here:
libdrm: git-2.4.14 / ports-2.4.17 (since defined WITHOUT_NOUVEAU)
libXmu: git-1.1.0 / ports-1.1.0
libXxf86vm: git-1.1.1 / ports-1.1.1
xf86vidmodeproto: git-2.3.1 / ports-2.3.1

THESE ARE OK (ahead):
dri2proto: git-2.6 / ports-2.3
glproto: git-1.4.14 / ports-1.4.12
mesa: git-7.11 / ports-MesaDemos-7.6.1

For git version info:
# git tag -l

3. I have built and installed the above (except mesa), but the packages do not register themselves in /var/db/ports (nor pkg), and cause portmaster to complain. Having looked through some the Makefiles, I see that they do not have such structure:
Code: 
PORTNAME=	libdrm
PORTVERSION=	${LIBDRM_VERSION}
PORTREVISION=	1
CATEGORIES=	graphics x11
MASTER_SITES=	http://dri.freedesktop.org/libdrm/
MAINTAINER=	x11@FreeBSD.org
COMMENT=	Userspace interface to kernel Direct Rendering Module services
I am thinking of adding these manually to the beginning of the Makefiles to get them to register properly. Should I include below code at the end? Is there a better solution?
Code: 
.include <bsd.port.post.mk>
EDIT: libdrm from git is at: 2.4.29 & not 14.
 
Beeblebrox said:
I am thinking of adding these manually to the beginning of the Makefiles to get them to register properly. Should I include below code at the end? Is there a better solution?
Code: 
.include <bsd.port.post.mk>
Click to expand...

FreeBSD Porter's Handbook
 
Beeblebrox said:
1. I don't understand this message:
Code: 
Your system supports OpenGL version "1.2 Mesa 7.6.1" application needs at least version 1.3 to work
Click to expand...

It's pretty clear. You need at least OpenGL version 1.3, and you only have OpenGL version 1.2. I do know that the last classic r600 mesa driver will claim to support OpenGL 2.1, though without KMS certain things won't work properly. But at the very least it will let that particular application start.

Adam
 
This is where I have to admit my complete ignorance in all matters Xorg:
Isn't mesa (mesa-demos-7.4.4) a port / alternative of OpenGL? I have graphics/libGL-7.4.4 installed, is this what should be upgraded, or is OpenGL 1.3 inside mesa-7.11?

I'm also taking the easy way out and switching the above 4 dependents back to the ports system. However, libdrm started building without Radeon API (whereas it configures with Radeon when building from GIT):
Code: 
libdrm 2.4.17 will be compiled with:
  Intel API      yes
  Radeon API     no
  Nouveau API    no
Is API for KMS, or am I getting the 2 mixed-up? From one of your posts:
--enable-radeon in drm config but since KMS isn't supported on FreeBSD anyway
Click to expand...
 
Mesa is an implementation of OpenGL. The version in the ports tree is old and only supports OpenGL version 1.2. If you want a higher version of OpenGL, you need a newer version of Mesa than what's in the ports tree, just as we discussed in another thread.

The radeon API in libdrm is for KMS. It doesn't matter if it's not enabled.
 
Okay, Thanks so much and sorry for being a numb-nut - some concepts take their time seeping through.

Although drm from git is at 2.4.29 I have reverted back to the port (at ver 2.4.14) because the depends tree gets seriously messed up. Should I advise the port maintainer of this (I suspect they already know)?
 
Yeah, I'm quite sure the ports x11 ports maintainers know there are newer versions available
Click to expand...
I meant the problem that install process does not register itself into /var/db/pkg correctly resulting in hanging depends; but that's still pretty funny.

Separately, I have downloaded from ftp the tars of MesaLib-7.11.2 and MesaGLUT-7.11.2. GLUT has no top-level Makefile, only sub-folders. I copied contents under MesaGLUT to their relevant locations under MesaLib - I assume this is the correct method?

EDIT: Bad news on the ports idea for drm:
Code: 
Requested 'libdrm >= 2.4.24' but version of libdrm is 2.4.17
As an example to the above, after building drm from git (v. 2.4.29) I installed without removing the version built from ports first. I then had to manually edit /var/db/pkg/libdrm-2.4.17_1/+CONTENTS to 2.4.29 and change the libdrm folder name. After that, I am now running this to update all the dependent ports:
# portmaster --check-depends
AND THAT DID NOT WORK EITHER...
 
Beeblebrox said:
I meant the problem that install process does not register itself into /var/db/pkg correctly resulting in hanging depends; but that's still pretty funny.
Click to expand...
No third-party application will ever do this. It's the job of the FreeBSD ports system to do this. The source Makefile has nothing to do with the port's Makefile.

In order for a third-party application to register itself properly you will have to create a port for it. See the Porter's Handbook link I posted earlier.
 
Thanks for the explanation SirDice - did not realize the slight complication package registration entailed.

In the meantime, as a shortcut for drm: I de-installed ports version and re-installed git version. I had made a backup of the libdrm folder from /var/db/pkg before I did this. I will now copy the backed-up folder to /var/db/pkg so that portmaster is OK. This solved the drm error.

While building Mesa, needed options (so as to disable "not found" errors for nouveau and expat):
# ./configure --with-expat=/usr/local CC=gcc46 NOUVEAU_CFLAGS=disable NOUVEAU_LIBS=disable
Nevertheless gave an error: Needs LLVM - so [ports]devel/llvm[/ports] was installed and configure worked.
Now gmake stops with this (also tried without gcc modification):
Code: 
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -
I../../../../../src/mapi -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../..
/src/egl/drivers/dri -I/usr/local/include -I/usr/local/include/libdrm   -I/usr/local/include -
DFEATURE_GL=1 -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing  -
fPIC  -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DPTHREADS DUSE_EXTERNAL_DXTN_LIB=1
 -DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -
DHAVE_XCB_DRI2 -DXCB_DRI2_CONNECT_DEVICE_NAME_BROKEN -DGALLIUM_LLVMPIPE -
D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0300 -fvisibility=hidden  mach64_ioctl.c -o 
mach64_ioctl.o In file included from mach64_ioctl.c:33:
mach64_context.h:302:22: error: byteswap.h: No such file or directory
mach64_ioctl.c: In function 'mach64UploadHwStateLocked':
mach64_ioctl.c:865: warning: implicit declaration of function 'bswap_32'
gmake[6]: *** [mach64_ioctl.o] Error 1
gmake[6]: Leaving directory `/asp/work/builds/Mesa/src/mesa/drivers/dri/mach64'
gmake[5]: *** [lib] Error 2
gmake[5]: Leaving directory `/asp/work/builds/Mesa/src/mesa/drivers/dri/mach64'
gmake[4]: *** [subdirs] Error 1
etc
 
1. Mesa build breaks as above - any suggestions?
2. I currently have x11-drivers/xf86-video-radeonhd installed for my Radeon3000 gpu. I am monitoring cpu load and I get very high cpu usage for simple things like flash movies - I am suspecting the gpu is not kicking in correctly. Is there a way to monitor gpu load? For example under linux, there is supposedly this command:
# aticonfig --adapter=0 --od-getclocks
 
Pass options to configure to build only the driver you want so that it doesn't try to build the mach64 driver.

I do not believe there is a way to monitor GPU load with the open source drivers, but you may finrd that the radeon driver performs better than radeonhd.
 
@Adamk: You are right, I again forgot your instructions from the other thread. I corrected as you had suggested there, but ran into a documented bug when using llvm-3.0 and its patch. Rather than try to slog through that, I downgraded to llvm-2.9 and re-started.
Then eglapi broke the build, so I disabled it assuming that EGL is also KMS dependent. Now the latest options passed to configure were:
# ./configure CC=gcc46 --with-expat=/usr/local NOUVEAU_CFLAGS=disable NOUVEAU_LIBS=disable --with-dri-drivers=r600 --with-gallium-drivers=r600 --disable-egl
With this configuration, gmake returned:
Code: 
gmake[4]: Entering directory `/asp/work/builds/mesa/src/gallium/drivers/r600'
gcc46 -c -I. -I../../src/gallium/include -I../../src/gallium/auxiliary
-I../../src/gallium/drivers -I/usr/local/include -I/usr/local/include/libdrm
-g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing
-fPIC  -DUSE_X86_64_ASM -DHAVE_POSIX_MEMALIGN -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0209 -fvisibility=hidden
-I/usr/local/include  -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS r600_asm.c -o r600_asm.o
[color="Red"]r600_asm.c:25:22: fatal error: byteswap.h: No such file or directory[/color]
compilation terminated.
gmake[4]: *** [r600_asm.o] Error 1
gmake[4]: Leaving directory `/asp/work/builds/mesa/src/gallium/drivers/r600'
 
You shouldn't be building any gallium drivers except, perhaps, swrast. The r600 gallium driver will certainly not work on FreeBSD, even if you get it to compile.

Adam
 
I finally got mesa to compile & install and using x11-drivers/xf86-video-ati, but several strange things:
- glxinfo: Command not found
- cpu load still at max when viewing flash videos.
- gnome apps load faster now, but performance quickly slows down as more apps are opened. I assume this is due to the small amount of RAM I have (1 GB)?

Maybe my xorg.conf is missing something - section Monitor is configured correctly:
Code: 
Section "Module"
	Load  "record"
	Load  "dbe"
	Load  "dri"
	Load  "glx"
	Load  "dri2"
	Load  "extmod"

Section "Device"
#Option     "useconfiguredmonitor" "true"
#Option     "AGPMode"  "true"
#Option     "AGPFastWrite"  "true"
#Option     "RenderAccel"  "true"
#Option     "AccelMethod"  "exa"
Option     "DRI"    "true"

Section "DRI"
	Group "video"
	Mode 0666
is there a link showing what all options in there are control, btw?
 
1) glxinfo is part of graphics/mesa-demos.

2) Flash sucks and is awful when it comes to CPU usage.

3) Yeah, slowing down as more windows open could easily be a RAM issue.

Generally, you shouldn't need to specify a Device, Module, Screen or Monitor section in xorg.conf these days unless something is not correctly detected. Nothing in the snippets you've posted jumps out at me. You can see what other options are available for the Device section, though, by reading the radeon man page.

Adam
 
1) glxinfo is part of graphics/mesa-demos.
Click to expand...
therefore I cannot run glxinfo since my mesa is from source and installing graphics/mesa-demos would interfere.

Thanks for the radeon man page info.

I would like to repeat for future readers how to keep a record of the package on their system (a quick workaround and not the "preferred" solution). After building the depends and mesa its self from git or tar sources, the existing package must be de-installed before the built-from-git packages installed. However, those sources do not register themselves in /var/db/pkg and leave hanging depends in the "package registry". My hacked solution is:
1. Make a copy of the folder corresponding to the port being de-instaled (ex: /var/db/pkg/dri2proto-2.3)
2. Remove the port
3. Re-name the folder to version you are installing (ex: dri2proto-2.6) and do the same for version info in the +CONTENTS file. Copy the folder back to /var/db/pkg.
4. Install the compiled package and run
# portmaster --check-depends

This is not an ideal solution and can cause some problems with version mis-match, but it's a quickie.
 
You must log in or register to reply here.
Back
Top