| View previous topic :: View next topic |
| Author |
Message |
theotherjoe
Guru
Joined: 22 Nov 2003
Posts: 393
|
 Posted: Fri May 29, 2015 7:46 am Post subject: |
 |
|
Had a look again at the kernel 3.18.x just to check the information
from yesterday.
so here is the included firmware list
from /proc/config.gz:
| Code: | CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="v4l-cx2341x-enc.fw radeon/TAHITI_uvd.bin radeon/VERDE_pfp.bin radeon/VERDE_me.bin radeon/VERDE_ce.bin radeon/VERDE_rlc.bin radeon/VERDE_smc.bin radeon/VERDE_mc2.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
|
but in the kernel log there is some interesting additional information:
| Code: |
...
[ 0.804481] [drm] Loading verde Microcode
[ 0.804542] radeon 0000:01:00.0: Direct firmware load for radeon/verde_pfp.bin failed with error -2
[ 0.804639] radeon 0000:01:00.0: Direct firmware load for radeon/verde_me.bin failed with error -2
[ 0.804735] radeon 0000:01:00.0: Direct firmware load for radeon/verde_ce.bin failed with error -2
[ 0.804834] radeon 0000:01:00.0: Direct firmware load for radeon/verde_rlc.bin failed with error -2
[ 0.804931] radeon 0000:01:00.0: Direct firmware load for radeon/verde_mc.bin failed with error -2
[ 0.805025] [drm] radeon/VERDE_mc2.bin: 31500 bytes
[ 0.805082] radeon 0000:01:00.0: Direct firmware load for radeon/verde_smc.bin failed with error -2
[ 0.805175] [drm] Internal thermal controller with fan control
[ 0.805288] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[ 0.811381] [drm] radeon: dpm initialized
...
|
surprisingly GL behaves properly. will have to try it with the verde_* fileset.
nevertheless it seems to rely on the mc2 part, at least that's my interpretation.
| Code: | localhost $ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.7
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.3.7
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.3.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:
|
|
|
| Back to top |
|
 |
theotherjoe
Guru
Joined: 22 Nov 2003
Posts: 393
|
| Posted: Fri May 29, 2015 8:28 am Post subject: |
|
|
Built a new 3.18.14 kernel with the verde_* fileset
| Code: | localhost ~ $ uname -a
Linux localhost 3.18.14-kms #2 SMP PREEMPT Fri May 29 10:06:49 CEST 2015 x86_64 AMD FX(tm)-6300 Six-Core Processor AuthenticAMD GNU/Linux
localhost ~ # zgrep FIRMWARE /proc/config.gz
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="v4l-cx2341x-enc.fw radeon/TAHITI_uvd.bin radeon/verde_pfp.bin radeon/verde_me.bin radeon/verde_ce.bin radeon/verde_rlc.bin radeon/verde_smc.bin radeon/verde_mc.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
# CONFIG_CYPRESS_FIRMWARE is not set
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_GOOGLE_FIRMWARE is not set
# CONFIG_TEST_FIRMWARE is not set
|
with following drm output in kernel log:
| Code: | [ 0.799349] [drm] Initialized drm 1.1.0 20060810
[ 0.799434] [drm] radeon kernel modesetting enabled.
[ 0.799709] [drm] initializing kernel modesetting (VERDE 0x1002:0x683D 0x1787:0x2501).
[ 0.799808] [drm] register mmio base: 0xF7300000
[ 0.799860] [drm] register mmio size: 262144
[ 0.799930] radeon 0000:01:00.0: Invalid ROM contents
[ 0.800013] ATOM BIOS: VERDE
[ 0.800191] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
[ 0.800284] radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
[ 0.800376] [drm] Detected VRAM RAM=1024M, BAR=256M
[ 0.800436] [drm] RAM width 128bits DDR
[ 0.800546] [TTM] Zone kernel: Available graphics memory: 4062712 kiB
[ 0.801865] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 0.801918] [TTM] Initializing pool allocator
[ 0.801973] [TTM] Initializing DMA pool allocator
[ 0.802040] [drm] radeon: 1024M of VRAM memory ready
[ 0.802094] [drm] radeon: 1024M of GTT memory ready.
[ 0.802147] [drm] Loading verde Microcode
[ 0.802202] [drm] Internal thermal controller with fan control
[ 0.802304] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[ 0.808457] [drm] radeon: dpm initialized
[ 0.808528] [drm] GART: num cpu pages 262144, num gpu pages 262144
[ 0.809959] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[ 0.810017] [drm] PCIE gen 2 link speeds already enabled
[ 0.823436] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[ 0.823584] radeon 0000:01:00.0: WB enabled
[ 0.823638] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8802342efc00
[ 0.823730] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0xffff8802342efc04
[ 0.823821] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0xffff8802342efc08
[ 0.823915] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff8802342efc0c
[ 0.824007] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0xffff8802342efc10
[ 0.824586] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc900107b5a18
[ 0.824678] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 0.824731] [drm] Driver supports precise vblank timestamp query.
[ 0.824785] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[ 0.824855] radeon 0000:01:00.0: irq 30 for MSI/MSI-X
[ 0.824863] radeon 0000:01:00.0: radeon: using MSI.
[ 0.824933] [drm] radeon: irq initialized.
[ 1.328617] [drm] ring test on 0 succeeded in 2 usecs
[ 1.328673] [drm] ring test on 1 succeeded in 1 usecs
[ 1.328729] [drm] ring test on 2 succeeded in 1 usecs
[ 1.328793] [drm] ring test on 3 succeeded in 9 usecs
[ 1.328857] [drm] ring test on 4 succeeded in 9 usecs
[ 1.505874] [drm] ring test on 5 succeeded in 2 usecs
[ 1.505930] [drm] UVD initialized successfully.
[ 1.506316] [drm] ib test on ring 0 succeeded in 0 usecs
[ 1.506396] [drm] ib test on ring 1 succeeded in 0 usecs
[ 1.506490] [drm] ib test on ring 2 succeeded in 0 usecs
[ 1.506593] [drm] ib test on ring 3 succeeded in 0 usecs
[ 1.506695] [drm] ib test on ring 4 succeeded in 0 usecs
[ 1.792661] tsc: Refined TSC clocksource calibration: 3516.133 MHz
[ 2.157574] [drm] ib test on ring 5 succeeded
[ 2.158146] [drm] Radeon Display Connectors
[ 2.158210] [drm] Connector 0:
[ 2.158270] [drm] HDMI-A-1
[ 2.158322] [drm] HPD1
[ 2.158395] [drm] DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578 0x657c 0x657c
[ 2.158486] [drm] Encoders:
[ 2.158538] [drm] DFP1: INTERNAL_UNIPHY2
[ 2.158591] [drm] Connector 1:
[ 2.158643] [drm] DVI-D-1
[ 2.158695] [drm] HPD2
[ 2.158747] [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
[ 2.158839] [drm] Encoders:
[ 2.158893] [drm] DFP2: INTERNAL_UNIPHY
[ 2.158945] [drm] Connector 2:
[ 2.158998] [drm] VGA-1
[ 2.159056] [drm] DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[ 2.159147] [drm] Encoders:
[ 2.159199] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 2.197203] [drm] fb mappable at 0xC047A000
[ 2.197256] [drm] vram apper at 0xC0000000
[ 2.197312] [drm] size 9216000
[ 2.197363] [drm] fb depth is 24
[ 2.197416] [drm] pitch is 7680
[ 2.197565] fbcon: radeondrmfb (fb0) is primary device
[ 2.210779] Console: switching to colour frame buffer device 160x54
[ 2.214935] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 2.214975] radeon 0000:01:00.0: registered panic notifier
[ 2.235454] [drm] Initialized radeon 2.40.0 20080528 for 0000:01:00.0 on minor 0
|
OpenGL seems to behave fine
| Code: | localhost ~ # glxinfo | grep Open
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.7
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.3.7
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.3.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:
|
edit:
btw, scorched3d shows at ultra detail and 1680x1050 resolution
for the same image that you showed earlier in the thread
a frame rate just shy of 10fps for both 3.14 and 3.18 kernels. |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Sat Jun 06, 2015 11:48 am Post subject: |
|
|
I have no freaking clue what's going on, still. Something's happening, and yet nothing's happening.
I go to my kernel, make a new one WITHOUT the radeon firmware blobs.
| Code: | grep -i firm /usr/src/linux/.config
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="" |
Reboot, and X works, KDM works, scorched3d runs the same shitslow 4fps.
Not only that, but:
| Code: | dmesg | grep -i verde
[ 2.432976] [drm] initializing kernel modesetting (VERDE 0x1002:0x683D 0x1458:0x2282).
[ 2.433810] [drm] Loading verde Microcode |
.
So the goddamn thing is loading microcode even when I've told it not to.
The point of trying that was to see if *not* loading microcode gave any performance hit, ie, if the microcode was doing anything at all.
So I just 'emerge -Ca radeon-ucode' and took the modules="radeon" OUT of /etc/conf.d/modules and rebooted.
Finally. I got a horribly ugly tty screen at bugger-all resolution. So the ucode and/or 'radeon' module actually affects the text mode too.
So instead of putting radeon-ucode back in, I put in linux-firmware instead. Still haven't put the firmware blobs back into my kernel, still got CONFIG_EXTRA_FIRMWARE="", and still I get the same dmesg 'loading microcode'. So I don't think this goddamn computer is actually doing what I want it to do anyway. So I have no damned clue as to how to test putting things in or out, because the freaking thing will just do its own thing anyway.
In other news, I completely took out VIDEO-CARDS="radeon radeonsi" and replaced it with VIDEO-CARDS="fglrx". So that won't even compile. so I'm stuck with a halfarsed open-source micro-code-loading-even-when-I-tell-it-not-to driver.
I give up.
In other news, KDE5 finally made it into the portage tree I noticed. So maybe now that KWin 5.4 is a 'real' wayland compositor, I can ditch this whole goddamn X bullshit once and for all. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54220
Location: 56N 3W
|
| Posted: Sat Jun 06, 2015 5:30 pm Post subject: |
|
|
Dr Croubie,
If you keep the emotion out your your posts the technical issues will be easier to comprehend for your helpers.
You can build the radeon driver in two ways. Build into your kernel on as a module.
When you build it into your kernel, the firmware must be in kernel too.
As a module, the firmware is loaded from /lib/firmware.
As you have had the firmware in the kernel, its probably still in /lib/firmware too.
The firmware is only required for hardware accelerated 3D. Even then, your user must be in the video group as they need access to
| Code: | $ ls -l /dev/dri/c*
crw-rw---- 1 root video 226, 0 Feb 16 2014 /dev/dri/card0
crw-rw---- 1 root video 226, 64 Feb 16 2014 /dev/dri/controlD64 |
to get access to the hardware.
As you have moved toward fglrx, you must have disabled radeon in the kernel, so you no longer get the free framebuffer console. Indeed, you may even be back to an 80x24 text console.
That can be ugly.
It would be useful to see your Xorg.0.log when you are using radeon and
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Sun Jun 07, 2015 1:10 am Post subject: |
|
|
| NeddySeagoon wrote: | Dr Croubie,
If you keep the emotion out your your posts the technical issues will be easier to comprehend for your helpers.
You can build the radeon driver in two ways. Build into your kernel on as a module.
When you build it into your kernel, the firmware must be in kernel too.
As a module, the firmware is loaded from /lib/firmware.
As you have had the firmware in the kernel, its probably still in /lib/firmware too.
The firmware is only required for hardware accelerated 3D. Even then, your user must be in the video group as they need access to
| Code: | $ ls -l /dev/dri/c*
crw-rw---- 1 root video 226, 0 Feb 16 2014 /dev/dri/card0
crw-rw---- 1 root video 226, 64 Feb 16 2014 /dev/dri/controlD64 |
to get access to the hardware.
As you have moved toward fglrx, you must have disabled radeon in the kernel, so you no longer get the free framebuffer console. Indeed, you may even be back to an 80x24 text console.
That can be ugly.
It would be useful to see your Xorg.0.log when you are using radeon and |
Well, I'm really trying to be rational about this, trying things in a scientific change-one-variable-at-a-time way, I've been at this for 3 months or more and have come absolutely nowhere, I have the same performance as then, and nothing changes no matter what I do. It's especially frustrating trying to change something to test and it doesn't even change so I can't rip things apart to single-variables to change one at a time.
***
For the record, I'm still on radeonsi. I tried fglrx and that won't even compile. It fails early on so here's the whole stack:
| Code: | # emerge -va ati-drivers
...
>>> Compiling source in /var/tmp/portage/x11-drivers/ati-drivers-15.1/work ...
* Preparing fglrx module
make -j10 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' GCC_VER_MAJ=4 KVER=4.0.4-hardened-r2-linFW KDIR=/lib/modules/4.0.4-hardened-r2/build 'CFLAGS_MODULE+=-DMODULE -DATI -DFGL' CFLAGS_MODULE+=-DCOMPAT_ALLOC_USER_SPACE=arch_compat_alloc_user_space kmod_build
make -C /lib/modules/4.0.4-hardened-r2/build SUBDIRS=/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x modules
make[1]: Entering directory '/usr/src/linux-4.0.4-hardened-r2'
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_agp.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_debug.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_ioctl.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_io.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_pci.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_iommu.o
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_wait.o
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.c: In function ‘KCL_STR_Strnicmp’:
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.c:172:5: error: implicit declaration of function ‘strnicmp’ [-Werror=implicit-function-declaration]
return strnicmp(s1, s2, count);
^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target '/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.o' failed
make[2]: *** [/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_acpi.c:839:20: warning: ‘KCL_ACPI_Slot_No_Hotplug’ defined but not used [-Wunused-function]
static acpi_status KCL_ACPI_Slot_No_Hotplug(KCL_ACPI_DevHandle handle, u32 lvl, void *data, void **rv)
^
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function ‘kcl_mem_pat_setup’:
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4501:9: error: implicit declaration of function ‘read_cr4’ [-Werror=implicit-function-declaration]
cr4 = read_cr4();
^
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4502:9: error: implicit declaration of function ‘write_cr4’ [-Werror=implicit-function-declaration]
write_cr4(cr4 & ~X86_CR4_PGE);
^
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: At top level:
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:6426:12: warning: ‘KCL_fpu_save_init’ defined but not used [-Wunused-function]
static int KCL_fpu_save_init(struct task_struct *tsk)
^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target '/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o' failed
make[2]: *** [/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o] Error 1
Makefile:1468: recipe for target '_module_/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x' failed
make[1]: *** [_module_/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x] Error 2
make[1]: Leaving directory '/usr/src/linux-4.0.4-hardened-r2'
Makefile:88: recipe for target 'kmod_build' failed
make: *** [kmod_build] Error 2
* ERROR: x11-drivers/ati-drivers-15.1::gentoo failed (compile phase):
* emake failed |
I can't even see a valid error message in that, can anyone else?
There's only "cc1: some warnings being treated as errors", is that a reason to kill an ebuild?
Even worse, it gives me this:
| Code: | * Messages for package x11-drivers/ati-drivers-15.1:
* CONFIG_DRM must be disabled or compiled as a module and not loaded for direct
* rendering to work.
* Please check to make sure these options are set correctly.
* Failure to do so may cause unexpected problems.
* CONFIG_DRM must be disabled or compiled as a module and not loaded for direct
* rendering to work.
* Please check to make sure these options are set correctly.
* Failure to do so may cause unexpected problems.
* You have disabled xattr pax markings for portage.
* This will likely cause programs using ati-drivers provided
* libraries to be killed kernel. |
a) yes, radeon drm is compiled as a module, that's why I took it out of /etc/conf.d/modules to stop it autoloading when I tried to get fglrx (it's back in now that I'm back to radeonsi). I can ignore that warning, that's fine.
but b) "* You have disabled xattr pax markings for portage."
Um, no I haven't. In fact, xattr and pax_kernel are not only set in my make.conf, they're explicit by default in a hardened profile, I couldn't turn them off if I wanted to. So that error is just BS.
If anyone can fix that and get fglrx to compile, I'd still like to try it to compare. I'm not an OS fanboy, I don't mind binary-drivers (especially if they work when the OS driver fails). I'll try anything (and I am) if there was the remotest chance that it'd work. Hell, I'd use a Matrox Millenium driver if it worked with this card.
So yeah, until I can compile it, screw fglrx. At least radeon/si compiles and gives me kdm.
***
So I'm back to / still at square one with radeonsi. The only thing I've learnt in the last 3 months is that my card physically can clock up to the full 1GHz if I set it manually. So it's not a hardware fault.
I still don't know if I'm loading the right microcode. I'm blindly following what the wiki says, that's all I can do. That's why I wanted to try screwing with the lines in the kernel to load different ones. If ripping them all out gives me the same performance, then I know I'm loading the wrong ones. Or I could just put the whole damned lot in there and let the kernel load what it wants. But that might backfire and it loads something wrong that blocks the loading of the correct one.
Other than that, I've got all the right things set, as far as I know:
| Code: | # equery u mesa
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for media-libs/mesa-10.5.6:
U I
- - bindist : Disable patent-encumbered ARB_texture_float, EXT_texture_shared_exponent, and EXT_packed_float extensions.
- - classic : Build drivers based on the classic architecture.
- - d3d9 : Enable Direct 3D9 API through Nine state tracker. Can be used together with patched wine.
- - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
+ + dri3 : Enable DRI3 support.
+ + egl : Enable EGL support.
+ + gallium : Build drivers based on Gallium3D, the new architecture for 3D graphics drivers.
+ + gbm : Enable the Graphics Buffer Manager for EGL on KMS.
- - gles1 : Enable GLESv1 support.
- - gles2 : Enable GLESv2 support.
+ + llvm : Enable LLVM backend for Gallium3D.
+ + nptl : Enable support for Native POSIX Threads Library, the new threading module (requires linux-2.6 or better usually)
+ + opencl : Enable the Clover Gallium OpenCL state tracker.
- - openmax : Enable OpenMAX video decode/encode acceleration for Gallium3D.
- - osmesa : Build the Mesa library for off-screen rendering.
+ + pax_kernel : Enable if the user plans to run the package under a pax enabled hardened kernel
- - pic : disable optimized assembly code that is not PIC friendly
+ + udev : Enable virtual/udev integration (device discovery, power and storage device support, etc)
- - vaapi : Enable Video Acceleration API for hardware decoding
+ + vdpau : Enable the VDPAU acceleration interface for the Gallium3D Video Layer.
- - video_cards_i915 : VIDEO_CARDS setting to build driver for Intel i915 video cards
- - video_cards_i965 : VIDEO_CARDS setting to build driver for Intel i965 video cards
- - video_cards_ilo : VIDEO_CARDS setting to build unofficial gallium driver for Intel gen6/7 video cards
- - video_cards_intel : VIDEO_CARDS setting to build driver for Intel video cards
- - video_cards_nouveau : VIDEO_CARDS setting to build reverse-engineered driver for nvidia cards
- - video_cards_r100 : VIDEO_CARDS setting to build only r100 based chips code for radeon
- - video_cards_r200 : VIDEO_CARDS setting to build only r200 based chips code for radeon
- - video_cards_r300 : VIDEO_CARDS setting to build only r300, r400 and r500 based chips code for radeon
- - video_cards_r600 : VIDEO_CARDS setting to build only r600, r700, Evergreen and Northern Islands based chips code for radeon
+ + video_cards_radeon : VIDEO_CARDS setting to build driver for ATI radeon video cards
+ + video_cards_radeonsi : VIDEO_CARDS setting to build only Southern Islands based chips code for radeon
- - video_cards_vmware : VIDEO_CARDS setting to build driver for vmware video cards
- - wayland : Enable support for dev-libs/wayland
+ + xa : Enable the XA (X Acceleration) API for Gallium3D.
- - xvmc : Enable the XvMC acceleration interface for the Gallium3D Video Layer.
# eselect mesa list
i915 (Intel 915, 945)
i965 (Intel GMA 965, G/Q3x, G/Q4x, HD)
r300 (Radeon R300-R500)
[1] gallium *
r600 (Radeon R600-R700, Evergreen, Northern Islands)
[1] gallium *
sw (Software renderer)
[1] gallium *
# ls -l /dev/dri/
total 0
crw-rw----+ 1 root video 226, 0 Jun 7 2015 card0
crw-rw---- 1 root video 226, 64 Jun 7 2015 controlD64
crw-rw---- 1 root video 226, 128 Jun 7 2015 renderD128
(as user) $ groups
disk wheel uucp audio cdrom video usb users vboxusers rjs games mount plugdev
|
Actually, looking at 'eselect mesa list':
There are sections for i915 and i965 intel cards that I don't have, fair enough.
But the two radeon sections are for r300 and r600, I don't have them either, and I certainly don't have video_cards_r300/600 set in make.conf.
Shouldn't there be a 'Southern Islands' or similar section in eselect mesa list? I've got the latest eselect-mesa installed, but the changelog says it hasn't changed much in 2 or even 4 years.
Is eselect mesa horrendously out of date and needs to be updated for the new Southern/Volcanic Islands?
Should/could I try adding video_cards_r600/300 etc to make.conf?
Or is eselect just lazy and thinking that r600 is Southern Islands and this doesn't mean anything?
| Code: | # grep -i radeon /usr/src/linux/.config
CONFIG_EXTRA_FIRMWARE="radeon/verde_ce.bin radeon/verde_mc.bin radeon/verde_me.bin radeon/verde_pfp.bin radeon/verde_rlc.bin radeon/verde_smc.bin radeon/TAHITI_uvd.bin"
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_UMS is not set
# CONFIG_FB_RADEON is not set
# grep -i drm /usr/src/linux/.config
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=m
...
CONFIG_DRM_RADEON=m
# lsmod | grep -i radeon
radeon 1102728 2
cfbfillrect 2938 1 radeon
cfbimgblt 1807 1 radeon
cfbcopyarea 2782 1 radeon
i2c_algo_bit 4269 1 radeon
drm_kms_helper 65830 1 radeon
ttm 56882 1 radeon
drm 223890 5 ttm,drm_kms_helper,radeon
i2c_core 16990 5 drm,i2c_piix4,drm_kms_helper,i2c_algo_bit,radeon
backlight 4893 1 radeon
fb 30835 5 fbcon,drm_kms_helper,radeon,softcursor,bitblit
hwmon 2530 4 it87,k10temp,radeon,thermal_sys
# lsmod | grep -i drm
drm_kms_helper 65830 1 radeon
drm 223890 5 ttm,drm_kms_helper,radeon
i2c_core 16990 5 drm,i2c_piix4,drm_kms_helper,i2c_algo_bit,radeon
fb 30835 5 fbcon,drm_kms_helper,radeon,softcursor,bitblit |
| Code: | # dmesg | grep -i drm
[ 1.605288] ata1.00: supports DRM functions and may not be fully accessible
[ 1.605837] ata1.00: supports DRM functions and may not be fully accessible
[ 2.330518] [drm] Initialized drm 1.1.0 20060810
[ 2.431449] [drm] radeon kernel modesetting enabled.
[ 2.431787] [drm] initializing kernel modesetting (VERDE 0x1002:0x683D 0x1458:0x2282).
[ 2.431803] [drm] register mmio base: 0xFDD80000
[ 2.431805] [drm] register mmio size: 262144
[ 2.432559] [drm] Detected VRAM RAM=2048M, BAR=256M
[ 2.432560] [drm] RAM width 128bits DDR
[ 2.432656] [drm] radeon: 2048M of VRAM memory ready
[ 2.432657] [drm] radeon: 1024M of GTT memory ready.
[ 2.432666] [drm] Loading verde Microcode
[ 2.432671] [drm] Internal thermal controller with fan control
[ 2.432721] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[ 2.440439] [drm] radeon: dpm initialized
[ 2.440455] [drm] GART: num cpu pages 262144, num gpu pages 262144
[ 2.441462] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[ 2.441466] [drm] PCIE gen 2 link speeds already enabled
[ 2.452154] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[ 2.452813] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.452814] [drm] Driver supports precise vblank timestamp query.
[ 2.452866] [drm] radeon: irq initialized.
[ 2.965308] [drm] ring test on 0 succeeded in 1 usecs
[ 2.965313] [drm] ring test on 1 succeeded in 1 usecs
[ 2.965318] [drm] ring test on 2 succeeded in 1 usecs
[ 2.965332] [drm] ring test on 3 succeeded in 9 usecs
[ 2.965338] [drm] ring test on 4 succeeded in 4 usecs
[ 3.142394] [drm] ring test on 5 succeeded in 2 usecs
[ 3.142399] [drm] UVD initialized successfully.
[ 3.142754] [drm] ib test on ring 0 succeeded in 0 usecs
[ 3.142789] [drm] ib test on ring 1 succeeded in 0 usecs
[ 3.142824] [drm] ib test on ring 2 succeeded in 0 usecs
[ 3.142866] [drm] ib test on ring 3 succeeded in 0 usecs
[ 3.142908] [drm] ib test on ring 4 succeeded in 0 usecs
[ 3.791385] [drm] ib test on ring 5 succeeded
[ 3.792509] [drm] Radeon Display Connectors
[ 3.792514] [drm] Connector 0:
[ 3.792518] [drm] HDMI-A-1
[ 3.792521] [drm] HPD1
[ 3.792527] [drm] DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578 0x657c 0x657c
[ 3.792530] [drm] Encoders:
[ 3.792534] [drm] DFP1: INTERNAL_UNIPHY2
[ 3.792537] [drm] Connector 1:
[ 3.792540] [drm] DVI-D-1
[ 3.792543] [drm] HPD3
[ 3.792549] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[ 3.792552] [drm] Encoders:
[ 3.792556] [drm] DFP2: INTERNAL_UNIPHY1
[ 3.792559] [drm] Connector 2:
[ 3.792562] [drm] DVI-D-2
[ 3.792565] [drm] HPD2
[ 3.792571] [drm] DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 0x658c
[ 3.792574] [drm] Encoders:
[ 3.792578] [drm] DFP3: INTERNAL_UNIPHY
[ 3.792581] [drm] Connector 3:
[ 3.792584] [drm] VGA-1
[ 3.792589] [drm] DDC: 0x65c0 0x65c0 0x65c4 0x65c4 0x65c8 0x65c8 0x65cc 0x65cc
[ 3.792593] [drm] Encoders:
[ 3.792596] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 3.845303] [drm] fb mappable at 0xD047A000
[ 3.845307] [drm] vram apper at 0xD0000000
[ 3.845309] [drm] size 14745600
[ 3.845312] [drm] fb depth is 24
[ 3.845314] [drm] pitch is 10240
[ 3.845393] fbcon: radeondrmfb (fb0) is primary device
[ 4.025334] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_switch failed
[ 4.083262] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 4.083288] [drm] Initialized radeon 2.41.0 20080528 for 0000:01:00.0 on minor 0
# dmesg | grep -i radeon
[ 2.431449] [drm] radeon kernel modesetting enabled.
[ 2.432555] radeon 0000:01:00.0: VRAM: 2048M 0x0000000000000000 - 0x000000007FFFFFFF (2048M used)
[ 2.432557] radeon 0000:01:00.0: GTT: 1024M 0x0000000080000000 - 0x00000000BFFFFFFF
[ 2.432656] [drm] radeon: 2048M of VRAM memory ready
[ 2.432657] [drm] radeon: 1024M of GTT memory ready.
[ 2.440439] [drm] radeon: dpm initialized
[ 2.452302] radeon 0000:01:00.0: WB enabled
[ 2.452305] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff8805159dac00
[ 2.452307] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff8805159dac04
[ 2.452309] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff8805159dac08
[ 2.452311] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff8805159dac0c
[ 2.452314] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff8805159dac10
[ 2.452811] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc900116b5a18
[ 2.452815] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[ 2.452845] radeon 0000:01:00.0: radeon: using MSI.
[ 2.452866] [drm] radeon: irq initialized.
[ 3.792509] [drm] Radeon Display Connectors
[ 3.845393] fbcon: radeondrmfb (fb0) is primary device
[ 4.025334] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_switch failed <--- as noted earlier, I can fix this with kernel line radeon.dpm=0, but that doesn't change anything otherwise.
[ 4.083262] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 4.083264] radeon 0000:01:00.0: registered panic notifier
[ 4.083288] [drm] Initialized radeon 2.41.0 20080528 for 0000:01:00.0 on minor 0
# dmesg | grep -i verde
[ 2.431787] [drm] initializing kernel modesetting (VERDE 0x1002:0x683D 0x1458:0x2282).
[ 2.432666] [drm] Loading verde Microcode |
| Code: | # grep -i kms /var/log/Xorg.0.log
[ 27.262] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 27.285] (II) [KMS] Kernel modesetting enabled.
[ 27.375] (II) RADEON(0): KMS Color Tiling: enabled
[ 27.375] (II) RADEON(0): KMS Color Tiling 2D: enabled
[ 27.375] (II) RADEON(0): KMS Pageflipping: enabled
# grep -i drm /var/log/Xorg.0.log
[ 27.237] (II) xfree86: Adding drm device (/dev/dri/card0)
# grep -i dri2 /var/log/Xorg.0.log
[ 27.285] (II) Loading sub module "dri2"
[ 27.285] (II) LoadModule: "dri2"
[ 27.285] (II) Module "dri2" already built-in
[ 27.364] (II) glamor: EGL version 1.4 (DRI2):
[ 27.502] (II) RADEON(0): [DRI2] Setup complete
[ 27.502] (II) RADEON(0): [DRI2] DRI driver: radeonsi
[ 27.502] (II) RADEON(0): [DRI2] VDPAU driver: radeonsi
[ 27.622] (II) GLX: Initialized DRI2 GL provider for screen 0 |
| Code: | # glxinfo
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:
...
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
...
GLX version: 1.4
GLX extensions:
...
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.5.6
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
...
OpenGL version string: 3.0 Mesa 10.5.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
...
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.5.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:
... etc
# LIBGL_DEBUG=verbose glxinfo | head
libGL: OpenDriver: trying /usr/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/radeonsi_dri.so
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: |
***
I've also tried putting in Phoronix Test Suite to see if that uncovers anything, rather than just using Scorched3D as a benchmark, but phoronix doesn't work either.
***
I also have no xorg.conf to speak of in /etc/X11, there's only:
| Code: | # grep -i xorg.conf /var/log/Xorg.0.log
[ 27.234] (==) Using config directory: "/etc/X11/xorg.conf.d"
[ 27.234] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
# cat /etc/X11/xorg.conf.d/20opengl.conf
Section "Files"
EndSection
# ls /usr/share/X11/xorg.conf.d
10-evdev.conf 10-quirks.conf |
and those last 2 files are just full of evdev/input class stuff.
I haven't written an xorg.conf for many many systems ago. Do I need one? Obviously I'm getting kdm working without one. But theotherjoe has one, and has better performance with an older card.
But then I read something like this including the line "Those wanting to use experimental 2D/3D support when running all of the latest code will for now need to set NoAccel to false in the xorg.conf." So that's about 18 months old, but still, there might be some line like that that I'm missing because I don't have an xorg.conf?
***
And finally, for years I booted to commandline, logged in as user, and used 'startx'. I could kill it and restart it any number of times I wanted.
About 5 years and 2 or 3 systems ago, that stopped working. Ever since then I've booted to commandline, logged in a root, and used 'kdm'. Then I get the kdm login screen, and log in as user. To get back to commandline, I have to logout as user to get back to the kdm login screen, and press Alt+n. Once I'm back at the commandline, I can't get back to kdm at all, I have to reboot.
Might that have something to do with any of this weirdness?
***
There are only a few other options I can think of.
Buy an R7 260X with money I don't have, and see if the GCN 1.1 with different microcode fixes it (my current R7 250X is a GCN 1.0).
Wait for the 4.2 kernel with the new AMDGPU I've been hearing about on phoronix, buy an even more expensive R9 285 and see if a GCN 1.2 card with new driver works.
Wait for KDE 5.4 to be un-hard-masked (or unmask it myself) and see if switching to Wayland/Weston fixes anything. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54220
Location: 56N 3W
|
| Posted: Sun Jun 07, 2015 8:07 pm Post subject: |
|
|
GNU nano 2.4.1 File: test Modified
Dr Croubie,
I'm not very good with the ATI binary blob because I don't use it but I can spot some problems in your build log.
You are building against | Code: | | KVER=4.0.4-hardened-r2-linFW |
Thats likely to be fragile as the only code built
in ati-drivers is a 'shim' to wrap the binary blob (closed source) part that does all the work.
When that breaks, only AMD/ATI can fix it.
As you are using spotting the fist error in the log, the only one we care about, is difficult,
you need make -j1, for that. However, working with what we have,
| Code: | /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.c: In function 'KCL_STR_Strnicmp':
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.c:172:5: \
error: implicit declaration of function 'strnicmp' [-Werror=implicit-function-declaration]
return strnicmp(s1, s2, count);
^
cc1: some warnings being treated as errors |
The key phrases here are | Code: | | some warnings being treated as errors |
and | Code: | | error: implicit declaration of function 'strnicmp' |
together with | Code: | | -Werror=implicit-function-declaration |
Taken together tells that the error here is due to a warning that gcc has been told to treat as an error.
There is no doubt that implicit declaration of functions is a very bad thing, but it need not cause builds to fail.
Implicit function declarations can work or they can cause linker and/or run time issues when they don't, as potential problems get past the compile phase.
If your hardened kernel indicates that you are running a hardened system, I wouldn't try binary blob drivers.
For entertainment value only - I don't have an ATI card, I removed the kernel checks from the ebuild and ran
| Code: | | MAKEOPTS="-j1" emerge -av1 ati-drivers |
It failed with | Code: | /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4501:9: \
error: implicit declaration of function 'read_cr4' [-Werror=implicit-function-declaration]
cr4 = read_cr4(); |
Maybe the kernel has changed and the driver needs to be updated to keep up.
On to Radeon
| Quote: | | I still don't know if I'm loading the right microcode. |
The driver will only load the right microcode for your card, Its easier to test this with the driver as a module, as testing only requires a reboot, not a kernel rebuild.
If there is no loadable microcode, the driver will tell what it wanted in dmesg. It might only tell the first file, so you provide that and next boot, it wants another one too. Eventually, you get them all.
| Quote: | | I'm blindly following what the wiki says, that's all I can do. |
I would say that you are validating the wiki, not following blindly. When it does not produce the expected results, you have been poking at the problem.
| Quote: | | That's why I wanted to try screwing with the lines in the kernel to load different ones. If ripping them all out gives me the same performance, then I know I'm loading the wrong ones. |
That's not nesseccarily true, unless you are running as root. You can have everything set up correctly then not have permissions to use direct rendering.
Your permissions and group memberships are correct.
[ 2.431787] [drm] initializing kernel modesetting (VERDE 0x1002:0x683D 0x1458:0x2282). Tells that you have a Radeon HD7770 card.
Thats about 3 years old now so it should be well supported.
it does indeed need radeonsi and verde microcode, so you are doing everything right here.
If there is no performace difference with and without microcode loaded, it does suggest that 3D hardware acceleration is not being used but it says nothing about why.
The microcode is stored in SRAM. You need to power down for a minuite or so, to be sure the contents are lost. A reboot will not remeve the microcode.
Its unlikely that eselect mesa is a problem. There used to be several different radean drivers but over the years most of them have been merged into radeon.
I still log into a user shell and run startx. If you want to run kde that way, create a ~/.xinit file that contains thats from memory. I use Xfce
If you want kdm to start at boot, read /etc/conf.d/xdm and add xdm to your default runlevel.
| Code: | # glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI |
that's correct for root. What does it say for a user?
You should not need any xorg.conf at all, if you can live with the defaults.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Thu Jun 11, 2015 3:42 am Post subject: |
|
|
| NeddySeagoon wrote: | As you are using spotting the fist error in the log, the only one we care about, is difficult,
you need make -j1, for that. |
I always thought that make -jx was related to the number of threads to simultaneously compile, ie number of cores in my cpu. I've got 6 cores, so I added another few for good measure (like if one thread has a cache miss, the other thread can get compiled while the first one is looking for its memory).
Nevertheless, I tried fglrx with -j1 and it still didn't compile, so yeah, not going to bother with it, at least the OS compiles.
Or you mean just to compile with -j1 to get the errors in order? I can do that:
| Code: | >>> Compiling source in /var/tmp/portage/x11-drivers/ati-drivers-15.1/work ...
* Preparing fglrx module
make -j1 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' GCC_VER_MAJ=4 KVER=4.0.4-hardened-r2-linFW KDIR=/lib/modules/4.0.4-hardened-r2/build 'CFLAGS_MODULE+=-DMODULE -DATI -DFGL' CFLAGS_MODULE+=-DCOMPAT_ALLOC_USER_SPACE=arch_compat_alloc_user_space kmod_build
make -C /lib/modules/4.0.4-hardened-r2/build SUBDIRS=/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x modules
make[1]: Entering directory '/usr/src/linux-4.0.4-hardened-r2'
CC [M] /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function ‘kcl_mem_pat_setup’:
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4501:9: error: implicit declaration of function ‘read_cr4’ [-Werror=implicit-function-declaration]
cr4 = read_cr4();
^
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4502:9: error: implicit declaration of function ‘write_cr4’ [-Werror=implicit-function-declaration]
write_cr4(cr4 & ~X86_CR4_PGE);
^
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: At top level:
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:6426:12: warning: ‘KCL_fpu_save_init’ defined but not used [-Wunused-function]
static int KCL_fpu_save_init(struct task_struct *tsk)
^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target '/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o' failed
make[2]: *** [/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o] Error 1
Makefile:1468: recipe for target '_module_/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x' failed
make[1]: *** [_module_/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x] Error 2
make[1]: Leaving directory '/usr/src/linux-4.0.4-hardened-r2'
Makefile:88: recipe for target 'kmod_build' failed
make: *** [kmod_build] Error 2
* ERROR: x11-drivers/ati-drivers-15.1::gentoo failed (compile phase):
* emake failed
|
| NeddySeagoon wrote: | However, working with what we have,
| Code: | /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.c: In function 'KCL_STR_Strnicmp':
/var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/kcl_str.c:172:5: \
error: implicit declaration of function 'strnicmp' [-Werror=implicit-function-declaration]
return strnicmp(s1, s2, count);
^
cc1: some warnings being treated as errors |
The key phrases here are | Code: | | some warnings being treated as errors |
and | Code: | | error: implicit declaration of function 'strnicmp' |
together with | Code: | | -Werror=implicit-function-declaration |
Taken together tells that the error here is due to a warning that gcc has been told to treat as an error.
There is no doubt that implicit declaration of functions is a very bad thing, but it need not cause builds to fail.
Implicit function declarations can work or they can cause linker and/or run time issues when they don't, as potential problems get past the compile phase.
If your hardened kernel indicates that you are running a hardened system, I wouldn't try binary blob drivers.
For entertainment value only - I don't have an ATI card, I removed the kernel checks from the ebuild and ran
| Code: | | MAKEOPTS="-j1" emerge -av1 ati-drivers |
It failed with | Code: | /var/tmp/portage/x11-drivers/ati-drivers-15.1/work/common/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4501:9: \
error: implicit declaration of function 'read_cr4' [-Werror=implicit-function-declaration]
cr4 = read_cr4(); |
Maybe the kernel has changed and the driver needs to be updated to keep up.
|
So that means that there is a problem with the ebuild and/or binary driver? Or that hardened-gcc just won't compile it because it's too flaky?
Totally aside: I've got a hardened profile and hardened kernel, but I've always wondered about gcc:
| Code: | # gcc-config -l
[1] avr-4.8.4 *
[2] avr-4.8.4-vanilla
[3] x86_64-pc-linux-gnu-4.8.4 *
[4] x86_64-pc-linux-gnu-4.8.4-hardenednopie
[5] x86_64-pc-linux-gnu-4.8.4-hardenednopiessp
[6] x86_64-pc-linux-gnu-4.8.4-hardenednossp
[7] x86_64-pc-linux-gnu-4.8.4-vanilla |
I chose 3 because I didn't want 'nopie', 'nossp', nor 'vanilla'. Maybe it's just semantics, but is option 3 actually hardened or not? If it is, couldn't we change the name to '-hardened' to remove ambiguity? Or is 3 just regular non-hardened gcc, and to get hardened I have to choose from 4/5/6 and forego either pie or ssp?
mmm, pie.
| NeddySeagoon wrote: |
On to Radeon
| Quote: | | I still don't know if I'm loading the right microcode. |
The driver will only load the right microcode for your card, Its easier to test this with the driver as a module, as testing only requires a reboot, not a kernel rebuild.
If there is no loadable microcode, the driver will tell what it wanted in dmesg. It might only tell the first file, so you provide that and next boot, it wants another one too. Eventually, you get them all.
| Quote: | | I'm blindly following what the wiki says, that's all I can do. |
I would say that you are validating the wiki, not following blindly. When it does not produce the expected results, you have been poking at the problem.
| Quote: | | That's why I wanted to try screwing with the lines in the kernel to load different ones. If ripping them all out gives me the same performance, then I know I'm loading the wrong ones. |
That's not nesseccarily true, unless you are running as root. You can have everything set up correctly then not have permissions to use direct rendering.
Your permissions and group memberships are correct.
[ 2.431787] [drm] initializing kernel modesetting (VERDE 0x1002:0x683D 0x1458:0x2282). Tells that you have a Radeon HD7770 card.
Thats about 3 years old now so it should be well supported. |
R7 250X actually, but yeah, it's the same Cape Verde GCN 1.0 core as the HD7770.
| NeddySeagoon wrote: | it does indeed need radeonsi and verde microcode, so you are doing everything right here.
If there is no performace difference with and without microcode loaded, it does suggest that 3D hardware acceleration is not being used but it says nothing about why.
The microcode is stored in SRAM. You need to power down for a minuite or so, to be sure the contents are lost. A reboot will not remeve the microcode.
Its unlikely that eselect mesa is a problem. There used to be several different radean drivers but over the years most of them have been merged into radeon.
|
OK, so I was thinking that the radeon-ucode and/or linux-firmware packages put the firmware into /lib/firmware, which then got compiled into the kernel through the CONFIG_EXTRA_FIRMWARE. So if radeon's a module, it loads the firmware via userspace from /lib/firmware each time?
With that in mind, I completely wiped /etc/portage/savedconfig/sys-kernel/linux-firmware-2015020, reinstalled it, and rebooted (to a kernel with nothing in config_extra_firmware, ergo all microcode comes from userspace).
On boot it came up with an 80x60 or whatever ugly screen, and in dmesg I could see:
| Code: | # dmesg | grep -i verde
[ 2.404780] [drm] initializing kernel modesetting (VERDE 0x1002:0x683D 0x1458:0x2282).
[ 2.405656] [drm] Loading verde Microcode
[ 2.407104] radeon 0000:01:00.0: Direct firmware load for radeon/verde_pfp.bin failed with error -2
[ 2.407126] radeon 0000:01:00.0: Direct firmware load for radeon/VERDE_pfp.bin failed with error -2
[ 2.407129] smc: error loading firmware "radeon/VERDE_pfp.bin" |
So to fix that, I did:
| Code: | # echo radeon/verde_pfp.bin > /etc/portage/savedconfig/sys-kernel/linux-firmware-20150206
# emerge -va linux-firmware
# reboot |
The next time I rebooted, it gave me a different missing firmware, so I added that in via linux-firmware and rebooted.
Eventually, on the second-last go, I got to a nice 2560x1440 screen, but it still had missing TAHITI_uvd.bin. After I added that one, it hasn't whinged about missing microcode. So currently I'm loading, in the order that it whinged that they were missing:
| Code: | # cat /etc/portage/savedconfig/sys-kernel/linux-firmware-20150206
radeon/verde_pfp.bin
radeon/verde_me.bin
radeon/verde_ce.bin
radeon/verde_rlc.bin
radeon/verde_mc.bin
radeon/verde_smc.bin
radeon/TAHITI_uvd.bin |
Which afaik is the same as the list in the wiki, so I suppose that's right (at least I've confirmed what it's looking for now, so that's another thing off the list).
Interesting to note, that each time it looked for the lower-case one, then the upper-case one (lower-case is for >3.17 kernels, according to the wiki), except once when it looked for verde_mc, VERDE_mc2, VERDE_mc, when I added in the verde_mc it didn't ask for either upper-case mc or mc2.
But whatever, I know now that it's not a microcode thingy.
| NeddySeagoon wrote: |
I still log into a user shell and run startx. If you want to run kde that way, create a ~/.xinit file that contains thats from memory. I use Xfce
If you want kdm to start at boot, read /etc/conf.d/xdm and add xdm to your default runlevel.
| Code: | # glxinfo
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI |
that's correct for root. What does it say for a user?
You should not need any xorg.conf at all, if you can live with the defaults. |
OK, so I get the same glxinfo as root and user:
| Code: | # LIBGL_DEBUG=verbose glxinfo | head
libGL: OpenDriver: trying /usr/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/radeonsi_dri.so
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:
(root)
$ LIBGL_DEBUG=verbose glxinfo | head
libGL: OpenDriver: trying /usr/lib64/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/radeonsi_dri.so
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:
(user) |
But I just thought to check:
| Code: | $ ls -l /usr/lib64/dri/radeonsi_dri.so
lrwxrwxrwx 1 root root 23 Jun 6 20:41 /usr/lib64/dri/radeonsi_dri.so -> ../mesa/radeonsi_dri.so
$ ls -l /usr/lib64/mesa/radeonsi_dri.so
-rwxr-xr-x 5 root root 7461600 Jun 6 20:41 /usr/lib64/mesa/radeonsi_dri.so |
even though
| Code: | $ ls -l /dev/dri/card0
crw-rw----+ 1 root video 226, 0 Jun 10 22:14 /dev/dri/card0
|
So 'video' has permissions to the device, although 'root' owns the dri.so? There's r/x on all of them anyway, so I suppose that won't make too much of a difference?
At any rate, trying xfce, xdm, twm, whatever are next on the list, I hope it doesn't come to that. But it's not the hardware inability to clock up, now it's not the microcode nor firmware, I'm not sure where I'm looking next. I could try a non-hardened kernel/gcc/profile, but that's probably a day of 'emerge -e' I'd rather not do.
ps, just as another test, someone go to earth.nullschool.net and tell me what you get. On my old work laptop, crappy intel graphics but a nice core i5, win7 and firefox, it was beautiful and smooth. On this system, kde and firefox, it runs about 1-2fps if I'm lucky. afaik that's just 2D vector rendering, although it may be doing some kind of 3D rendering for the colours, not sure. Does anyone else get beautiful or stuttery? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54220
Location: 56N 3W
|
| Posted: Thu Jun 11, 2015 6:45 pm Post subject: |
|
|
Dr Croubie,
| Dr Croubie wrote: | | Or you mean just to compile with -j1 to get the errors in order? I can do that: |
Exactly.
| Code: | | [3] x86_64-pc-linux-gnu-4.8.4 * |
is the hardened gcc.
The options below it are used to disable assorted hardened features.
| Dr Croubie wrote: | | OK, so I was thinking that the radeon-ucode and/or linux-firmware packages put the firmware into /lib/firmware, which then got compiled into the kernel through the CONFIG_EXTRA_FIRMWARE. So if radeon's a module, it loads the firmware via userspace from /lib/firmware each time |
Close enough. The firmware is loaded at every boot anyway.
When the modue and firmware are in the kernel, its loaded from the kernel. There is no userspace firmware loading any more. It was added back to the kernel when udev broke, then subsequently removed from udev.
Your trial and error got the fimware the card needed. The order the files are listed in CONFIG_EXTRA_FIRMWARE is not important. That just includes them in the kerel so the firmware loader can find them.
The permissions on the files that you listed are all correct too.
On a AMD 1090T with a GeForce 9800 GT and the nouveau driver, using Firefox, I get about 2Hz from your site. That's at 2560x1440 too.
Your next experiment should be to compare the rendering rates for a user who is and is not permitted to use direct rendering.
Try changing the permissions no the contents of /dev/dri/card0 from 660 to 600, so only root can use harware acceleration.
For completeness 666 is worth a try too.
glxgears will do for testing with. glxgeals is not a benchmark but we only want to detect the difference between hardware 3D and software 3D, so its good enough.
Be sure it does not run into vertical refresh sync clipping. Hmm, even full screen it hits the 60Hz limit for me, so you may need to turn off vertical refresh sync.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Marlena13
n00b
Joined: 19 Jun 2015
Posts: 1
|
| Posted: Fri Jun 19, 2015 2:47 pm Post subject: |
|
|
| Great guys. Amazing work |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Mon Jun 22, 2015 12:05 am Post subject: |
|
|
OK, so a few more tests, even though I really should be studying for exams, but meh.
So I compiled Kernel 4.0.5-hardened-r1 last night. All config options the same, except that I put radeon and drm into the kernel, not modules as before:
| Code: | $ grep -i radeon /usr/src/linux/.config
CONFIG_EXTRA_FIRMWARE="radeon/verde_pfp.bin radeon/verde_me.bin radeon/verde_ce.bin radeon/verde_rlc.bin radeon/verde_mc.bin radeon/verde_smc.bin radeon/TAHITI_uvd.bin"
CONFIG_DRM_RADEON=y
# CONFIG_DRM_RADEON_UMS is not set
# CONFIG_FB_RADEON is not set
$ grep -i drm /usr/src/linux/.config
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=y |
No change to before (except now I get a full 2560x1440 screen earlier in boot, it doesn't start as 60x80 and change when the module gets loaded).
One thing I did notice was that DISPLAYMANAGER="xdm" was set in /etc/conf.d/xdm, so I set it to "kdm", but that hasn't changed anything (and I don't even think I've got xdm installed anyway)
As for startx, that still doesn't work for my user. It crashes out with:
| Code: | $ tail ~/.local/share/xorg/Xorg.0.log
[ 129.827] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 129.827] (EE)
Fatal server error:
[ 129.830] (EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
[ 129.832] (EE)
[ 129.834] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 129.841] (EE) Please also check the log file at "/home/rjs/.local/share/xorg/Xorg.0.log" for additional information.
[ 129.843] (EE) |
And when I login as root from tty, start 'kdm', then kdm won't let me log in as root, "root logins are not allowed".
But I can login as root on tty, then 'startx', for some reason that works when 'startx' fails for user.
Anyway, using X as root, I run scorched3d and get exactly the same 4-6fps as before (4fps on 'ultra detail' and 1680x1050, 6fps if I set AA to 0).
So: it's not a kernel-module vs inbuilt thihng. It's not a permissions thing (unless root is also not allowed to use the card).
Just on the permissions, currently I've got
| Code: | # ls -l /dev/dri/
total 0
crw-rw----+ 1 root video 226, 0 Jun 7 2015 card0
crw-rw---- 1 root video 226, 64 Jun 7 2015 controlD64
crw-rw---- 1 root video 226, 128 Jun 7 2015 renderD128 |
Changing to 660 or 666 would make them executable, no? Haven't tried that yet, maybe tomorrow night after my exam. |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Mon Jun 22, 2015 1:17 am Post subject: |
|
|
ps, I don't normally watch movies on my computer, but I just did a test, and this has never happened before:
| Code: | $ mplayer Movies/Eddie\ Izzard\ -\ Circle.mpg
MPlayer SVN-r37373 (Gentoo)-4.8.4 (C) 2000-2015 MPlayer Team
Playing Movies/Eddie Izzard - Circle.mpg.
libavformat version 56.25.101 (external)
MPEG-PS file format detected.
VIDEO: MPEG1 720x576 (aspect 8) 25.000 fps 1600.0 kbps (200.0 kbyte/s)
Load subtitles in Movies/
Could not find a UTF-8 locale,
character keys beyond Latin-1 will not be handled.
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 56.26.100 (external)
Selected video codec: [ffmpeg1] vfm: ffmpeg (FFmpeg MPEG-1)
==========================================================================
==========================================================================
Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000)
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [vdpau] 720x576 => 720x576 Planar YV12
Movie-Aspect is 1.37:1 - prescaling to correct movie aspect.
VO: [vdpau] 720x576 => 786x576 Planar YV12
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
A: 0.7 V: 0.6 A-V: 0.178 ct: 0.007 4/ 4 ??% ??% ??,?% 2 0
[VD_FFMPEG] DRI failure.
A: 5.4 V: 5.4 A-V: 0.000 ct: 0.024 124/124 5% 5% 0.6% 3 0
Exiting... (Quit) |
I've never gotten the "[VD_FFMPEG] DRI failure." before. But I have recently added mesa +vdpau use flag, is that from that?
Sort of makes sense, if I can't use the 3D acceleration then I also can't use the vdpau decoder on the card either.
I'll recompile mesa without it and see if it changes... |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Wed Jun 24, 2015 7:00 am Post subject: |
|
|
| Dr Croubie wrote: | So: it's not a kernel-module vs inbuilt thihng. It's not a permissions thing (unless root is also not allowed to use the card).
Just on the permissions, currently I've got
| Code: | # ls -l /dev/dri/
total 0
crw-rw----+ 1 root video 226, 0 Jun 7 2015 card0
crw-rw---- 1 root video 226, 64 Jun 7 2015 controlD64
crw-rw---- 1 root video 226, 128 Jun 7 2015 renderD128 |
Changing to 660 or 666 would make them executable, no? Haven't tried that yet, maybe tomorrow night after my exam. |
Duh, I should have thought about that more, rw-rw---- is already 660.
But nevertheless, I changed it to 666, and even 777 rwxrwxrwx for the hell of it. First just card0, then all 3 of them.
Absolutely no change.
And on the 'startx' thing, neither 'startx' nor 'startkde' work for user, both work for root.
As user, both commands crash out with the error message above ('cannot connect to x server' or something).
So adding 'echo "exec startkde" > ~/.xinit && startx' didn't actually do much, because startkde won't work either.
So now I'm back to 100% out of ideas.
All that's left is to completely ditch KDE for XFCE, ditch KDE4 and unmask KDE5, with either of those options maybe Wayland and Weston might fix something?
I still haven't figured out why fglrx won't compile, probably because I'm hardened. Another very remote possibility is to un-harden and spend 2 days recompiling everything, and try the whole lot again. |
|
| Back to top |
|
|
redcap
n00b
Joined: 10 Jul 2010
Posts: 38
|
|
| Back to top |
|
|
theotherjoe
Guru
Joined: 22 Nov 2003
Posts: 393
|
| Posted: Sun Jun 28, 2015 5:49 pm Post subject: |
|
|
Just found that glmark2 benchmark is part of the x11 overlay.
I was actually expecting it to be in app-benchmarks 
Well, I built and installed it with these USE flags:
| Code: | | app-benchmarks/glmark2-2014.03::x11 USE="X opengl -drm -gles2 -wayland" |
and ran the executable in windowed mode:
| Code: | user@localhost ~ $ glmark2
=======================================================
glmark2 2014.03
=======================================================
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER: Gallium 0.4 on AMD CAPE VERDE
GL_VERSION: 3.0 Mesa 10.3.7
=======================================================
[build] use-vbo=false: FPS: 2399 FrameTime: 0.417 ms
[build] use-vbo=true: FPS: 3953 FrameTime: 0.253 ms
[texture] texture-filter=nearest: FPS: 3870 FrameTime: 0.258 ms
[texture] texture-filter=linear: FPS: 3847 FrameTime: 0.260 ms
[texture] texture-filter=mipmap: FPS: 3862 FrameTime: 0.259 ms
[shading] shading=gouraud: FPS: 3914 FrameTime: 0.255 ms
[shading] shading=blinn-phong-inf: FPS: 3935 FrameTime: 0.254 ms
[shading] shading=phong: FPS: 3922 FrameTime: 0.255 ms
[shading] shading=cel: FPS: 3900 FrameTime: 0.256 ms
[bump] bump-render=high-poly: FPS: 3064 FrameTime: 0.326 ms
[bump] bump-render=normals: FPS: 3889 FrameTime: 0.257 ms
[bump] bump-render=height: FPS: 3851 FrameTime: 0.260 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 3729 FrameTime: 0.268 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 2654 FrameTime: 0.377 ms
[pulsar] light=false:quads=5:texture=false: FPS: 3347 FrameTime: 0.299 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 1801 FrameTime: 0.555 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 1745 FrameTime: 0.573 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 492 FrameTime: 2.033 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 793 FrameTime: 1.261 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 582 FrameTime: 1.718 ms
[ideas] speed=duration: FPS: 837 FrameTime: 1.195 ms
[jellyfish] <default>: FPS: 3342 FrameTime: 0.299 ms
[terrain] <default>: FPS: 394 FrameTime: 2.538 ms
[shadow] <default>: FPS: 2300 FrameTime: 0.435 ms
[refract] <default>: FPS: 674 FrameTime: 1.484 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 3935 FrameTime: 0.254 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 3908 FrameTime: 0.256 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 3865 FrameTime: 0.259 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 3916 FrameTime: 0.255 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 3972 FrameTime: 0.252 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 3947 FrameTime: 0.253 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 3942 FrameTime: 0.254 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 3927 FrameTime: 0.255 ms
=======================================================
glmark2 Score: 2985
=======================================================
|
hope these numbers can help Dr. Croubie in his further 3D hardware/software investigations
as a reference since the GPUs are basicallly the same |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Tue Jul 07, 2015 8:27 am Post subject: |
|
|
| theotherjoe wrote: | Just found that glmark2 benchmark is part of the x11 overlay.
I was actually expecting it to be in app-benchmarks
Well, I built and installed it with these USE flags:
| Code: | | app-benchmarks/glmark2-2014.03::x11 USE="X opengl -drm -gles2 -wayland" |
and ran the executable in windowed mode:
| Code: | user@localhost ~ $ glmark2
=======================================================
glmark2 2014.03
=======================================================
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER: Gallium 0.4 on AMD CAPE VERDE
GL_VERSION: 3.0 Mesa 10.3.7
=======================================================
[build] use-vbo=false: FPS: 2399 FrameTime: 0.417 ms
[build] use-vbo=true: FPS: 3953 FrameTime: 0.253 ms
[texture] texture-filter=nearest: FPS: 3870 FrameTime: 0.258 ms
[texture] texture-filter=linear: FPS: 3847 FrameTime: 0.260 ms
[texture] texture-filter=mipmap: FPS: 3862 FrameTime: 0.259 ms
|
hope these numbers can help Dr. Croubie in his further 3D hardware/software investigations
as a reference since the GPUs are basicallly the same |
Thanks! I still haven't gotten phoronix working, so this will do in the meantime.
I've put it on and the results are pretty telling straight up, have a look at the first two. You're getting 2399 & 3953, vs my 1760 & 2423, that's 26% and 38% worse.
The next 3 on texture you're getting 3800s, I'm getting 2400s.
| Code: | $ glmark2
=======================================================
glmark2 2014.03
=======================================================
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER: Gallium 0.4 on AMD CAPE VERDE
GL_VERSION: 3.0 Mesa 10.6.1
=======================================================
[build] use-vbo=false: FPS: 1760 FrameTime: 0.568 ms
[build] use-vbo=true: FPS: 2423 FrameTime: 0.413 ms
[texture] texture-filter=nearest: FPS: 2345 FrameTime: 0.426 ms
[texture] texture-filter=linear: FPS: 2430 FrameTime: 0.412 ms
[texture] texture-filter=mipmap: FPS: 2413 FrameTime: 0.414 ms
|
Just a thing though, you don't have USE=drm. It's only used on this package though, so it hasn't affected any of my other packages.
But when I got to run 'glmark2-drm' (as user or root) it gives an error.
| Code: | [ebuild R ~] app-benchmarks/glmark2-2014.03::x11 USE="X drm opengl -gles2 -wayland" PYTHON_TARGETS="python2_7" 0 KiB
# equery h drm
* Searching for USE flag drm ...
[I-O] [ ] app-benchmarks/glmark2-2014.03:0
$ glmark2-drm
Error: Failed to find a suitable DRM device
Error: main: Could not initialize canvas
Segmentation fault |
But it's still official, I'm definitely not getting the performance that I should with this card.
Also, I tried bitcoin mining with 'bfgminer' the other day. Allegedly an HD7770 should get 200MH/s (according to bitcoin.it), but I'm only getting 70MH/s at the most (not that I'll bother mining with it, just using it as a way to benchmark).
In other news, as a standard rule I've got USE="-suid", because of the "with potential security risks" bit in use.desc.
But I've been cocked over by that before with user mounting usb drives and that, so I just gave in, enabled it globally and did an "emerge -N". Xorg-server was one that rebuilt. But that didn't change anything anyway, so it's not a suid problem either. |
|
| Back to top |
|
|
theotherjoe
Guru
Joined: 22 Nov 2003
Posts: 393
|
| Posted: Tue Jul 07, 2015 11:08 am Post subject: |
|
|
I've tried USE="drm" in a first built but got the same message about
no suitable device, so I built the package in the default way.
Same way, I wouldnt apply suid flag if I can avoid it.
But regarding your hardware: no further idea of what might go pearshaped there |
|
| Back to top |
|
|
Dr Croubie
Apprentice
Joined: 21 Nov 2006
Posts: 159
|
| Posted: Mon Aug 03, 2015 11:46 pm Post subject: |
|
|
OK, so in the last few weeks I have:
- Unhardened everything
| Code: | # cat /etc/portage/make.conf
...
-hardened -pax_kernel nopie nossp -pie -ssp
# eselect profile list
Available profile symlink targets:
[11] default/linux/amd64/13.0/no-multilib *
# eselect kernel list
Available kernel symlink targets:
[1] linux-4.0.5-gentoo *
# gcc-config -l
[1] avr-4.8.4 *
[2] x86_64-pc-linux-gnu-4.8.4 *
|
Rebuilt everything a few times:
| Code: | | # emerge -v gcc && emerge -ev --keep-going system && emerge -ev --keep-going system world |
Absolutely no change to anything. Same 6fps in Scorched3D, same scores in glmark.
I saw a good deal on a mildly-used R7-360, which has a GCN1.1 Bonaire core, a step up from the Cape Verde, same 2GB / 128bit RAM, roughly the same clock. Rebuilt the kernel with the modules one-by-one through the same steps as before (and again they match up with the list on the wiki, that's a good start).
So now I'm getting 15fps on Scorched3D, about 150% better performance for 20% more shaders, same RAM and same clockspeeds. So that's a start.
glmark2 is better than it was on my old card (cf 1760/2423/2345/2430/2413), but still only just slightly better than theotherjoe's much older card (2399/3953/3870/3847/3862). The first result is a lot better, but the rest are barely ~5% over (although it's possible that it's CPU/RAM/PCIe constrained at this point).
| Code: | $ glmark2
=======================================================
glmark2 2014.03
=======================================================
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER: Gallium 0.4 on AMD BONAIRE
GL_VERSION: 3.0 Mesa 10.6.2
=======================================================
[build] use-vbo=false: FPS: 3110 FrameTime: 0.322 ms
[build] use-vbo=true: FPS: 3998 FrameTime: 0.250 ms
[texture] texture-filter=nearest: FPS: 4117 FrameTime: 0.243 ms
[texture] texture-filter=linear: FPS: 4089 FrameTime: 0.245 ms
[texture] texture-filter=mipmap: FPS: 4092 FrameTime: 0.244 ms |
Now the problem is that I'm still getting the original matlab error that I was before. I swear it's a permissions thing, still, starting with the fact that I'm still logging in as root, executing 'kdm', then logging in as user to the desktop. So I want to fix this first, so that I can login as user and just do 'startx' as I had for years. So now, how do I go about fixing this? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Multimedia
