Created attachment 141948 [details] both glxinfo outputs In my Slackware-current installation I noticed wrong glxinfo output when I changed Mesa 18.1.6 to 18.2.0 and later. That resulted in problems with starting VariCAD 3D cad software. I had to downgrade to 18.1.6.
Hi, Could you please provide version of Slackware-current you have and version of kernel? It is 32-bit OS version, right? I've tried to reproduce this bug on 64- and 32-bit mesa and mesa-utils versions having mesa-18.2.0, 18.2.1 and the latest 18.3.0 and have no such issue. Also use Skylake GT2: Intel® HD Graphics 520; CPU Intel Core i3-6006U. OS: Ubuntu 18.04 x86_64 kernel 4.17.18-generic.
Slackware-current means that this is 14.2 version upgraded to the latest packages (latest means up to several days ago - so it is still hot!). Kernel is 4.14.74-smp and the processor is i5-6300U CPU @ 2.40GHz. I use 32-bit version of Linux. I have 2 driver packages installed as a normal system component: intel-vaapi-driver-2.2.0-i586-1 xf86-video-intel-20180906_25c9a2fc-i686-1
Hello, brodo@o2.pl. Could you, please, provide (just for case) a result of command (files glxinfo.trace and glxinfo.loggg): apitrace trace -o ./glxinfo.trace strace glxinfo > ./glxinfo.loggg 2>&1
Created attachment 141972 [details] apitrace trace result
Brodo, are you able to check with newer kernel? 4.17 or 4.18?
I changed kernel to 4.18.13-smp. No difference :-(
I discovered that mesa up to 18.1.9 works well along with llvm-6.0.1. Mesa 18.2.0 and higher was compiled with llvm-7.0.0. That combination results in errors in glxinfo and my problems with VariCAD. I use Slackware-current 32-bit.
How can I perform regression test between 18.2.0 and 18.1.9 ? A comprehensive guide/doc would be useful now !
LLVM mismatches would be a distro bug, right? Mesa has to update LLVM when the radeon driver requires it. The resulting dependency conflicts are one of the drawbacks of using LLVM in the first place... How do other distros handle this issue?
Here is my bisecting result: 66c61797ada12e0e2b396affcc2dc495b6cc04ed is the first bad commit commit 66c61797ada12e0e2b396affcc2dc495b6cc04ed Author: Eric Engestrom <eric.engestrom@intel.com> Date: Mon Jun 4 18:06:30 2018 +0100 autotools: add missing android file to package Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106779 Fixes: ff904978a1d299a36b587 "gallium/util: Android backtrace support" Reviewed-by: Dylan Baker <dylan@pnwbakers.com> Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> :040000 040000 9419f28cdee4ad4586beac1d2cbc4ddf8f22d1d4 d76ec8f1a9698f1a62a34ceccf05d8ab6b0de499 M src
I bisected 18.2.0 and 18.1.9. Here is the result: 66c61797ada12e0e2b396affcc2dc495b6cc04ed is the first bad commit commit 66c61797ada12e0e2b396affcc2dc495b6cc04ed Author: Eric Engestrom <eric.engestrom@intel.com> Date: Mon Jun 4 18:06:30 2018 +0100 autotools: add missing android file to package Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106779 Fixes: ff904978a1d299a36b587 "gallium/util: Android backtrace support" Reviewed-by: Dylan Baker <dylan@pnwbakers.com> Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> :040000 040000 9419f28cdee4ad4586beac1d2cbc4ddf8f22d1d4 d76ec8f1a9698f1a62a34ceccf05d8ab6b0de499 M src
Hi Brodo, Finally I managed to reproduce this issue on 32x Ubuntu 16.04 (unfortunately had bad luck with Slackware). Also checked mentioned commit 66c61797ada12e0e2b396affcc2dc495b6cc04ed and from my side glxinfo has no issues on it. Here is my result of bisecting: a363bb2cd0e2a141f2c60be005009703bffcbe4e is the first bad commit commit a363bb2cd0e2a141f2c60be005009703bffcbe4e Author: Kenneth Graunke <kenneth@whitecape.org> Date: Tue Apr 10 01:18:25 2018 -0700 i965: Allocate VMA in userspace for full-PPGTT systems. This patch enables soft-pinning of all buffers, allowing us to skip relocation processing entirely. All systems with full PPGTT and > 4GB of VMA should gain these benefits. This should be most Gen8+. Unfortunately, this excludes a few systems: - Cherryview (only has 32-bit addressing, despite 48-bit pointers) - Broadwell with a 32-bit kernel - Anybody running pre-4.5 kernel. We may enable it for Cherryview in the future, but it would require some tweaks to the memory zone. Used environment: Intel® HD Graphics 520; Intel Core i3-6006U; kernel 4.18.13-041813-generic;
Marina's bisect points to a commit that requires a recent kernel, IIRC. Brodo's bisect seems implausible. Not sure how that commit could affect anything.
I'll try to repeat my bisect ; maybe some wrong declaration drove to bad results.
Finally I got the same result as Marina. My previuos attempt suffered possibly from one mistake. So I confirm Marina's result.
bash-4.4$ git bisect bad a363bb2cd0e2a141f2c60be005009703bffcbe4e is the first bad commit commit a363bb2cd0e2a141f2c60be005009703bffcbe4e Author: Kenneth Graunke <kenneth@whitecape.org> Date: Tue Apr 10 01:18:25 2018 -0700 i965: Allocate VMA in userspace for full-PPGTT systems. This patch enables soft-pinning of all buffers, allowing us to skip relocation processing entirely. All systems with full PPGTT and > 4GB of VMA should gain these benefits. This should be most Gen8+. Unfortunately, this excludes a few systems: - Cherryview (only has 32-bit addressing, despite 48-bit pointers) - Broadwell with a 32-bit kernel - Anybody running pre-4.5 kernel. We may enable it for Cherryview in the future, but it would require some tweaks to the memory zone. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Trying to send patch for the kernel: 0001-ppgtt-i915-memory-address-masks.patch but don't see it on https://patchwork.freedesktop.org/project/intel-gfx/patches So attaching it here. Brodo, are you able to try that patch with kernel drm-tip (https://01.org/linuxgraphics/documentation/build-guide-0) and check if VariCAD 3D works?
Created attachment 142168 [details] [review] 0001-ppgtt-i915-memory-address-masks.patch
The compiling of 2018Q1 Intel Graphics Stack Recipe seems not to be trivial. How this relates to x section of Slackware 32-bit (my distro) x-window source tree ? : http://ftp.slackware.com/pub/slackware/slackware-current/source/x/
I wouldn't recommend that site for tips on how to build your graphics stack. Usually, distros are ahead of what they put there, and have concerns that are not met by the documentation.
You don't need to build whole stack. As i wrote: need to build only kernel with applied patch. Also ensure that mesa is 18.2.x or over. Building kernel is in paragraph 'BUILDING KERNEL' of https://01.org/linuxgraphics/documentation/build-guide-0
Patch to the kernel: https://patchwork.freedesktop.org/patch/258425/
Sergii - what would be the output of this kernel compiling ? How can I insert it into my distro's structure ? : X section of Slackware 32-bit (my distro) x-window source tree: http://ftp.slackware.com/pub/slackware/slackware-current/source/x/
Hi, i don't use slackware, but... < http://ftp.slackware.com/pub/slackware/slackware-current/source/x/ Seems that is the user-space drivers. But issue is in system-space: in the kernel-drivers. As i can see your kernel is 4.19.0 (http://ftp.slackware.com/pub/slackware/slackware-current/kernels/VERSIONS.TXT). < Sergii - what would be the output of this kernel compiling ? Output is vmlinuz. So ATM patches that should fix issue are already in queue for the next kernel. And you need to wait for update of it if you don't want build it yourself. < How can I insert it into my distro's structure ? Fix is under that structure. So the simplest way for you (workaround till kernel updated) seems is to just revert commit a363bb2cd0e2a141f2c60be005009703bffcbe4e of http://ftp.slackware.com/pub/slackware/slackware-current/source/x/mesa/ and most likely it will work.
Sergii - what commands should I use for reverting this specific commit ? I mean on a local copy of mesa git on my HDD. I'm not used to use git.
Yes, the problem is gone. I've compiled kernel 4.19.0 with Sergii's patch. glxinfo's output seems then to be normal, VariCAD works well. Thanks Sergii !
Ken, do you agree that this bug should be assigned to the kernel?
Chris's version: https://patchwork.freedesktop.org/series/51505/
commit 9125963a9494253fa5a29cc1b4169885d2be7042 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 25 10:18:22 2018 +0100 drm/i915: Mark up GTT sizes as u64 commit 6fc4e48f9ed46e9adff236a0c350074aafa3b7fa Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 25 10:18:23 2018 +0100 drm/i915: Compare user's 64b GTT offset even on 32b
Although I confirmed proper behaviour of VariCAD 2.09, but there are some graphical weird phantoms during rotating or moving 3D view position. Downgrading back to mesa 18.1.9 eleminates this problem. So not all is resolved, unfortunately. How can I track/debug these phantoms to get some useful info ?
Hi. I would suggest to create a new issue, because it sounds really like a new, not related to current. Then, would be helpful to provide video of issue. I checked glance this app - it looks free for trial, so also would be helpful to provide a 3d model, which we can load and reproduce the problem. If issue is really disappears for lower mesa versions, I will bisect it quite fast
Created attachment 142299 [details] Example VariCAD file
Created attachment 142300 [details] pics of the problem
In order to show the artifacts you should rotate the point of view or zoom the objects several times.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.