Tiny Core Linux
Tiny Core Extensions => TCE Talk => Extension requests => Topic started by: pq5190362 on July 28, 2016, 02:44:02 PM
-
Hi,
any chance you could update the Xorg-7.7-3d.tcz extension in the x86 and x86_64 repos with Mesa 12.x:
http://www.mesa3d.org/
?
Regards
-
Hmm - that's not a small task - it might have to wait for tc-8.x...
-
Updated in the X86_64 repo - x86 to follow.
Take care to update all X related extensions at the same time
-
updated in the x86 repo
-
Will the xf86-video* extensions need a rebuild as well or do I need to reconfigure something?
Before the update, none of the 3D applications I tried ran properly. Graphical artifacts or displaying just black.
Now 3D works but it's extremely slow compared to TC-6.x.
I'm using:
Xorg-7.7-3d.tcz
xf86-video-intel.tcz
TC-7.x x86
Netbook MSI Wind U100
sudo lspci -v -s $(lspci | grep VGA | awk '{print $1}')
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] Device 0110
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at dfe80000 (32-bit, non-prefetchable) [size=512K]
I/O ports at d100 [size=8]
Memory at c0000000 (32-bit, prefetchable) [size=256M]
Memory at dff00000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Kernel driver in use: i915
lspci -n -s $(lspci | grep VGA | awk '{print $1}')
00:02.0 0300: 8086:27ae (rev 03)
OLD: glxinfo | grep 'renderer string'
OpenGL renderer string: Mesa DRI Intel(R) 945GME x86/MMX/SSE2
NEW: glxinfo | grep 'renderer string'
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
in /var/log/Xorg.0.log this is new (checked with meld)
(II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
-
$ glxgears
libGL error: unable to load driver: i915_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i915
549 frames in 5.0 seconds = 109.771 FPS
708 frames in 5.0 seconds = 141.489 FPS
712 frames in 5.0 seconds = 142.231 FPS
716 frames in 5.0 seconds = 143.157 FPS
671 frames in 5.0 seconds = 134.106 FPS
...
-
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
This means that software acceleration is being used.
You mentioned that you got a black screen previously, which would seem to indicate that hardware acceleration doesn't work with either the old or the new version for you?
-
Do you get this when the kms driver loads:
WARNING: CPU: 1 PID: 3338 at drivers/gpu/drm/i915/intel_display.c:12326 0xffffffffa01a9b49()
pipe state doesn't match!
Modules linked in: drbg ctr ccm iwlmvm mac80211 iwlwifi cfg80211 cpufreq_userspace cpufreq_conservative cpufreq_stats cpufreq_powersave i915 drm_kms_helper i2c_designware_platform i2c_designware_core drm intel_gtt agpgart i2c_algo_bit i2c_i801 squashfs lz4_decompress loop dell_wmi sparse_keymap ppdev parport_pc parport sdhci_acpi 8250_fintek sdhci_pci sdhci video backlight mmc_core e1000e ptp pcspkr pps_core 8250_dw wmi intel_smartconnect dell_rbtn battery intel_rst mei_me mei ac lpc_ich xhci_pci xhci_hcd
CPU: 1 PID: 3338 Comm: Xorg.wrap Tainted: G W 4.2.9-tinycore64 #1999
Hardware name: Dell Inc. Latitude E7240/05PTPV, BIOS A18 04/28/2016
0000000000000000 0000000000000009 ffffffff81514b36 ffff88040690b8f8
ffffffff81069070 ffff88040690b8f0 ffffffffa01a9b49 ffffffffa0207904
ffff8804071aa000 ffff88040540d000 0000000000000001 ffff88040690b988
Call Trace:
[<ffffffff81514b36>] ? 0xffffffff81514b36
[<ffffffff81069070>] ? 0xffffffff81069070
[<ffffffffa01a9b49>] ? 0xffffffffa01a9b49
[<ffffffff810690cd>] ? 0xffffffff810690cd
[<ffffffffa01a9b49>] ? 0xffffffffa01a9b49
[<ffffffff810107f0>] ? 0xffffffff810107f0
[<ffffffff810a8916>] ? 0xffffffff810a8916
[<ffffffff810107f0>] ? 0xffffffff810107f0
[<ffffffffa01b8b94>] ? 0xffffffffa01b8b94
[<ffffffff81108513>] ? 0xffffffff81108513
[<ffffffffa01b99ae>] ? 0xffffffffa01b99ae
[<ffffffffa01568fa>] ? 0xffffffffa01568fa
[<ffffffffa01286d7>] ? 0xffffffffa01286d7
[<ffffffffa0157eb1>] ? 0xffffffffa0157eb1
[<ffffffffa01595c6>] ? 0xffffffffa01595c6
[<ffffffffa01c6099>] ? 0xffffffffa01c6099
[<ffffffffa01e677e>] ? 0xffffffffa01e677e
[<ffffffffa01e6778>] ? 0xffffffffa01e6778
[<ffffffffa011ef31>] ? 0xffffffffa011ef31
[<ffffffffa011f414>] ? 0xffffffffa011f414
[<ffffffff81112680>] ? 0xffffffff81112680
[<ffffffff8107c6b2>] ? 0xffffffff8107c6b2
[<ffffffff8100a4b9>] ? 0xffffffff8100a4b9
[<ffffffff815198fc>] ? 0xffffffff815198fc
---[ end trace 8de49e2169362044 ]---
[drm:0xffffffffa01a9b28] *ERROR* mismatch in ips_enabled (expected 1, found 0)
..but even with that I get this: $ glxinfo | grep 'renderer string'
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
-
Try to find the cause for that "driver pointer missing", maybe "strace glxgears" or Xorg.0.log shows something.
edit: Also try LIBGL_DEBUG=verbose glxgears
-
You mentioned that you got a black screen previously, which would seem to indicate that hardware acceleration doesn't work with either the old or the new version for you?
Yes. Neither the old nor the new version works.
Do you get this when the kms driver loads:
Haven't seen that so far. Where would it be displayed? While booting using loglevel= bootcode?
LIBGL_DEBUG=verbose glxgears
libGL: OpenDriver: trying /usr/local/lib/dri/tls/i915_dri.so
libGL: OpenDriver: trying /usr/local/lib/dri/i915_dri.so
libGL: dlopen /usr/local/lib/dri/i915_dri.so failed (/usr/local/lib/dri/i915_dri.so: undefined symbol: __sync_val_compare_and_swap_8)
libGL error: unable to load driver: i915_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: i915
libGL: OpenDriver: trying /usr/local/lib/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/local/lib/dri/swrast_dri.so
libGL: Can't open configuration file /home/tc/.drirc: No such file or directory.
libGL: Can't open configuration file /home/tc/.drirc: No such file or directory.
574 frames in 5.0 seconds = 114.632 FPS
strace glxgears >/tmp/strace-glxgears 2>&1 output attached.
Xorg.0.log contains no (EE)'s, not even (WW)'s except for missing font directories.
-
Attached /var/log/messages .
-
libGL: dlopen /usr/local/lib/dri/i915_dri.so failed (/usr/local/lib/dri/i915_dri.so: undefined symbol: __sync_val_compare_and_swap_8)
This line is the culprit. The i915 driver requires -march=i586 minimum.
-
OK - I'll look tomorrow - do we want to use i686 for this as a minimum?
-
I'm not sure if there's 3d users on old cpus really, and the performance improves a lot with newer targets. Something like -march=pentium-m just for mesa might be ok. Maybe ask here if there's users on older ones and wait a week?
-
Will the xf86-video* extensions need a rebuild as well or do I need to reconfigure something?
Really couldn't hurt to update the DDX drivers.
Especially xf86-video-intel. xf86-video-intel is in constant development, but the Tiny Core Linux repos only have an old snapshot from 2015.
So, it couldn't hurt to update the Tiny Core Linux repos with a fresh snapshot of xf86-video-intel, directly from git.
By the way:
In recent events, Debian and Ubuntu more or less have deprecated xf86-video-intel in favour of xf86-video-modesetting, for more details see:
https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/intel-linux/886898-ubuntu-debian-abandon-intel-x-org-driver-for-most-hardware-moves-to-modesetting-ddx
https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/
xf86-video-modesetting no longer is a separate package. xf86-video-modesetting is built into xorg-server since xorg-server 1.17.0.
To get the latest version of xf86-video-modesetting, it would be necessary to update xorg-server to the latest version, which is 1.18.4 at the time of writing this:
https://cgit.freedesktop.org/xorg/xserver/
;)
-
FWIW, I agree with Phoronix. Modesetting is not a usable replacement.
-
After some checking, I discovered that the previous Xorg-7.7-3d extension had been compiled for i686 after it failed to compile for i484.
This newer version does compile for i484, but then apparently fails to run.
My concern in using pentium-m would be that the i915 driver might run, but not i965 for example.
-
Pentium-m is above pentium3, so I don't think it would hinder i965 any way.
-
To get the latest version of xf86-video-modesetting, it would be necessary to update xorg-server to the latest version, which is 1.18.4 at the time of writing this:
The xorg-server was updated to 1.18.4 :P
..let us know how the modesetting driver works.
-
On my hardware the xorg-server doesn't seem to want to use modesetting...
[ 1319.947] (==) AIGLX enabled
[ 1319.947] (==) Matched intel as autoconfigured driver 0
[ 1319.947] (==) Matched modesetting as autoconfigured driver 1
[ 1319.947] (==) Matched fbdev as autoconfigured driver 2
[ 1319.947] (==) Matched vesa as autoconfigured driver 3
[ 1319.947] (==) Assigned the driver to the xf86ConfigLayout
[ 1319.947] (II) LoadModule: "intel"
[ 1319.948] (WW) Warning, couldn't open module intel
[ 1319.948] (II) UnloadModule: "intel"
[ 1319.948] (II) Unloading intel
[ 1319.948] (EE) Failed to load module "intel" (module does not exist, 0)
[ 1319.948] (II) LoadModule: "modesetting"
[ 1319.948] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[ 1319.948] (II) Module modesetting: vendor="X.Org Foundation"
[ 1319.948] compiled for 1.18.4, module version = 1.18.4
[ 1319.948] Module class: X.Org Video Driver
[ 1319.948] ABI class: X.Org Video Driver, version 20.0
[ 1319.948] (II) LoadModule: "fbdev"
[ 1319.949] (WW) Warning, couldn't open module fbdev
[ 1319.949] (II) UnloadModule: "fbdev"
[ 1319.949] (II) Unloading fbdev
[ 1319.949] (EE) Failed to load module "fbdev" (module does not exist, 0)
[ 1319.949] (II) LoadModule: "vesa"
[ 1319.949] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so
[ 1319.949] (II) Module vesa: vendor="X.Org Foundation"
[ 1319.949] compiled for 1.18.0, module version = 2.3.4
[ 1319.949] Module class: X.Org Video Driver
[ 1319.949] ABI class: X.Org Video Driver, version 20.0
[ 1319.949] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 1319.949] (II) VESA: driver for VESA chipsets: vesa
[ 1319.949] (--) using VT number 2
[ 1319.952] (EE) open /dev/dri/card0: No such file or directory
[ 1319.952] (WW) Falling back to old probe method for modesetting
[ 1319.952] (EE) open /dev/dri/card0: No such file or directory
[ 1319.952] (EE) Screen 0 deleted because of no matching config section.
[ 1319.952] (II) UnloadModule: "modesetting"
[ 1319.952] (II) Loading sub module "vbe"
[ 1319.952] (II) LoadModule: "vbe"
[ 1319.952] (II) Loading /usr/local/lib/xorg/modules/libvbe.so
[ 1319.953] (II) Module vbe: vendor="X.Org Foundation"
[ 1319.953] compiled for 1.18.4, module version = 1.1.0
[ 1319.953] ABI class: X.Org Video Driver, version 20.0
[ 1319.953] (II) Loading sub module "int10"
[ 1319.953] (II) LoadModule: "int10"
[ 1319.953] (II) Loading /usr/local/lib/xorg/modules/libint10.so
[ 1319.955] (II) Module int10: vendor="X.Org Foundation"
[ 1319.955] compiled for 1.18.4, module version = 1.0.0
[ 1319.955] ABI class: X.Org Video Driver, version 20.0
[ 1319.955] (II) VESA(0): initializing int10
[ 1319.956] (II) VESA(0): Primary V_BIOS segment is: 0xc000
[ 1319.956] (II) VESA(0): VESA BIOS detected
-
So, it couldn't hurt to update the Tiny Core Linux repos with a fresh snapshot of xf86-video-intel, directly from git.
done for x86 and x86_64
-
Xorg-7.7-3d recompiled for pentium-m and reposted.
I get this: $ glxinfo | grep -i device
Device: Mesa DRI Intel(R) Haswell Mobile x86/MMX/SSE2 (0xa16
-
This forces modesetting to be used:
$ cat /usr/local/share/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
Option "AccelMethod" "glamor"
Option "DRI" "3"
EndSection
..but dri3 is not enabled.
With this dri3 is enabled: Section "Device"
Identifier "Intel Graphics"
Driver "intel"
Option "DRI" "3"
EndSection
-
FWIW, I agree with Phoronix. Modesetting is not a usable replacement.
Why not? Care to elaborate? Also, have you filed a bug for whatever issues you are experiencing with xf86-video-modesetting:
https://bugs.freedesktop.org/buglist.cgi?component=Driver%2Fmodesetting&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=xorg&query_format=advanced&resolution=---
?
:P
..but dri3 is not enabled.
You should read the following thread:
https://bbs.archlinux.org/viewtopic.php?id=211792
In a nutshell:
xf86-video-modesetting does in fact use DRI3 by default, but Xorg.0.log does not seem to report it properly for whatever reason.
However, you should be able to check if DRI3 is enabled with the following command from a terminal:
LIBGL_DEBUG=verbose glxinfo | grep libgl
You should see:
libGL: Using DRI3 for screen 0
Do you?
;)
-
Yes, with the modesetting driver I get this:
$ LIBGL_DEBUG=verbose glxinfo | grep libgl
libGL: Can't open configuration file /home/tc/.drirc: No such file or directory.
libGL: pci id for fd 4: 8086:0a16, driver i965
libGL: OpenDriver: trying /usr/local/lib/dri/tls/i965_dri.so
libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
libGL: Can't open configuration file /home/tc/.drirc: No such file or directory.
libGL: Using DRI3 for screen 0
..seems odd that it doesn't appear in the xorg log though...
-
Why not? Care to elaborate?
Because it uses glamor, ie emulates 2d acceleration on OpenGL. This means that for anything with 2d functionality, it is likely slower, uses more memory, and requires lots of disk space for OpenGL support - this has been confirmed by phoronix benchmarks repeatedly.
By being a generic driver, it also cannot use any card-specific functionality, such as anti-tearing, proper XV acceleration, colorspace conversion, etc that have their own units.
-
Benchmark scores
Integrated Graphics Chipset: Intel(R) HD Graphics 4400, corepure64 v7.2
glmark2 2014.03
=======================================================
OpenGL Information
GL_VENDOR: Intel Open Source Technology Center
GL_RENDERER: Mesa DRI Intel(R) Haswell Mobile
GL_VERSION: OpenGL ES 3.0 Mesa 12.0.1
[intel dri2]
glmark2 Score: 1890
glmark2-es2 Score: 1853
[intel dri3]
glmark2 Score: 1726
glmark2-es2 Score: 1722
[modesetting]
glmark2 Score: 1658
glmark2-es2 Score: 1646
-
Hmm. Intel driver now loads successfully but I'm back at unusable 3D.
I guess I'd have to go back to 6.x to get 3D working.
-
Because it uses glamor, ie emulates 2d acceleration on OpenGL. This means that for anything with 2d functionality, it is likely slower, uses more memory, and requires lots of disk space for OpenGL support
That is a moot argument.
xf86-video-ati and xf86-video-amdgpu are also using glamor, just like xf86-video-modesetting :).
this has been confirmed by phoronix benchmarks repeatedly.
What you are saying is not true, but see for yourself:
https://www.phoronix.com/scan.php?page=news_item&px=GLAMOR-EXA-2D-Ubuntu-16.04
https://www.phoronix.com/scan.php?page=news_item&px=Radeon-Modesetting-DDX-Xenial
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DDX-Modesetting
https://www.phoronix.com/scan.php?page=news_item&px=Intel-DDX-May-Tests
:)
Hmm. Intel driver now loads successfully but I'm back at unusable 3D.
Have you tried xf86-video-modesetting? Does 3D work with xf86-video-modesetting?
I guess I'd have to go back to 6.x to get 3D working.
Maybe it's the kernel (i.e. the DRM driver) which is causing your issue?
-
..but both the tests you link to for intel ddx versus modesetting and my own testing with glmark2 show that intel ddx is faster than modesetting, no?
-
..but both the tests you link to for intel ddx versus modesetting and my own testing with glmark2 show that intel ddx is faster than modesetting, no?
xf86-video-modesetting might be a bit slower in 2D performance than xf86-video-intel according to the benchmarks, but by how much?
Do you notice a difference?
I have to admit I am using xf86-video-intel @ SNA @ DRI3 @ TearFree myself, but I am not a fanboy of xf86-video-intel and still like the idea of a unified DDX driver (xf86-video-modesetting).
I mainly am using xf86-video-intel because it has the TearFree option, which works quite well (although not quite perfect).
With xf86-video-modesetting there is tearing. Admittedly though, that apparently could be fixed by using a compositor (which I currently do not): https://whirm.eu/posts/fix-for-xorgs-modesetting-driver-tearing/ .
-
Have you tried xf86-video-modesetting? Does 3D work with xf86-video-modesetting?
Via an Xorg config?
Section "Device"
Identifier "Card0"
Driver "modesetting"
Option "AccelMethod" "glamor"
Option "DRI" "2"
EndSection
I tried DRI 1, 2, and 3. Results in:
[ 16549.418] (WW) glamor requires at least 128 instructions (64 reported)
[ 16549.418] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time.
[ 16549.418] (EE)
Fatal server error:
[ 16549.418] (EE) AddScreen/ScreenInit failed for driver 0
[ 16549.418] (EE)
[ 16549.418] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 16549.418] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 16549.418] (EE)
[ 16549.434] (EE) Server terminated with error (1). Closing log file.
Maybe it's the kernel (i.e. the DRM driver) which is causing your issue?
Well, something is broken since 7.0 with intel i195.
-
Via an Xorg config?
You could probably also uninstall all xf86-video-* drivers, which should result in xf86-video-modesetting being used (it's built into xorg-server).
I tried DRI 1, 2, and 3.
You can not configure what type of DRI is being used with xf86-video-modesetting. xf86-video-modesetting does not have an option for configuring what type of DRI is being used.
Just type the following command into a terminal and see for yourself:
man modesetting
As you can see from the manpage, there is no such option. xf86-video-modesetting uses DRI3.
Results in:
[...]
Well, something is broken since 7.0 with intel i195.
Hmm, no idea, maybe Juanito and curaga can help.
-
Results in:
Looks like your hardware does not support glamor (which is being used by xf86-video-modesetting), see:
https://lists.freedesktop.org/archives/xorg/2016-July/058152.html
-
Well, something is broken since 7.0 with intel i195.
I believe it's the drm pointer error, which I presume is fixed in later kernel versions, but I have not seen a patch for our kernel version.
On another note, I compiled the intel vulkan driver, but have not yet figured out how to test it...
-
That is a moot argument.
xf86-video-ati and xf86-video-amdgpu are also using glamor, just like xf86-video-modesetting :).
If you don't care about disk, RAM, and performance, why not use Ubuntu?
-ati certainly does not default to glamor, it defaults to EXA. -amdgpu doesn't matter, because the hw supported by it does not have any 2d functionality.
Also, your own Intel link showed the Intel driver is faster. Cough.
-
-ati certainly does not default to glamor, it defaults to EXA.
You certainly should type this into a terminal:
man radeon
and then read this:
Option "AccelMethod" "string"
Chooses between available acceleration architectures. Valid
values are EXA (for pre-TAHITI GPUs) and glamor (for R300 or
higher). The default is glamor as of TAHITI, otherwise EXA.
:D
-
I'm aware. Tahiti is one of the last GPUs it supports. The huge majority defaults to EXA.
-
In some cases glamor is much faster than EXA on AMD hardware, and xf86-video-modesetting @ glamor is even faster than xf86-video-ati @ glamor:
https://www.phoronix.com/scan.php?page=news_item&px=GLAMOR-EXA-2D-Ubuntu-16.04
;)
-
seems the intel vulkan driver is not quite there yet:
$ VK_ICD_FILENAMES=/usr/local/share/vulkan/icd.d/intel_icd.json vulkaninfo
WARNING: Haswell Vulkan support is incomplete
gen7_pipeline.c:213: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
...
===========
VULKAN INFO
===========
Vulkan API Version: 1.0.21
INFO: [loader] Code 0 : Found manifest file /usr/local/share/vulkan/icd.d/intel_icd.json, version "1.0.0"
Instance Extensions:
====================
Instance Extensions count = 3
VK_KHR_surface : extension revision 25
VK_KHR_xcb_surface : extension revision 5
VK_EXT_debug_report : extension revision 3
Layers: count = 0
=======
Presentable Surface formats:
============================
GPU id : 0 (Intel(R) Haswell Mobile)
Surface type : VK_KHR_xcb_surface
Format count = 1
B8G8R8A8_SRGB
Device Properties and Extensions :
==================================
GPU0
VkPhysicalDeviceProperties:
===========================
apiVersion = 0x400005 (1.0.5)
driverVersion = 1 (0x1)
vendorID = 0x8086
deviceID = 0x0a16
deviceType = INTEGRATED_GPU
deviceName = Intel(R) Haswell Mobile
...
..and if I try to run any of the test images, except smoketest: $ VK_ICD_FILENAMES=/usr/local/share/vulkan/icd.d/intel_icd.json tri
WARNING: Haswell Vulkan support is incomplete
gen7_pipeline.c:213: FINISHME: VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO
...
Segmentation fault
-
I'm aware. Tahiti is one of the last GPUs it supports. The huge majority defaults to EXA.
Will no longer be true with xf86-video-ati 7.9.0, see:
https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=f11531c99fcd6473f58b4d10efaf3efd84304d8e
;)