08:12 udovdh: hello!
08:13 udovdh: What was the root cause for https://gitlab.freedesktop.org/drm/amd/issues/1028 ?
08:13 gitbot: drm issue 1028 in amd "5.4.x: amdgpu 0000:0a:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0x80000a600 flags=0x0000] and MUCH MORE" [Opened]
08:13 udovdh: As I was not at the keyboard when it started I have no idea what initiated this
08:16 udovdh: I see an sdma0 timeout, a recovery and then a WARNING: CPU: 5 PID: 150183 at include/linux/dma-fence.h:533 drm_sched_resubmit_jobs+0x141/0x150 [gpu_sched]
08:16 udovdh: 4 times actually
08:16 udovdh: then another gpu reset
08:17 udovdh: another WARNING: CPU: 5 PID: 150183 at include/linux/dma-fence.h:533 drm_sched_resubmit_jobs+0x141/0x150 [gpu_sched]
08:17 udovdh: and another sdma0 timeout
08:18 udovdh: then the kernel compains about a hung task Workqueue: events drm_sched_job_timedout [gpu_sched]
08:18 udovdh: a few times
08:21 udovdh: we are running 5.4.13 so the quick occurrence of https://gitlab.freedesktop.org/drm/amd/issues/934 should not happen
08:21 gitbot: drm issue 934 in amd "[5.2/5.3][drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted!" [Amdgpu, Bugzilla, Opened]
08:23 udovdh: the result was a non-responsive gui and thus a total failure of the functionality of this pc as seen from the user
08:23 udovdh: we do run the latest firmwares for vega10
08:24 udovdh: from the linux-firmware git tree
08:44 kode54: would this be considered a Mesa bug, or Windows shading compilers being too loose with the language?
08:45 kode54: I encountered a windows program that uses fairly old GL, running in wine, so it's practically forwarding the shaders as-is
08:45 kode54: it does: "vec4 color = <some color operations>" then later "color /= 4"
08:45 kode54: mesa is barfing on that, saying it can't determine the arithmetic operation to perform
08:46 kode54: it "works" if I change the shader to do "color /= vec4(4)"
08:48 udovdh: kode54, this is not about https://gitlab.freedesktop.org/drm/amd/issues/1028 ?
08:48 gitbot: drm issue 1028 in amd "5.4.x: amdgpu 0000:0a:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0x80000a600 flags=0x0000] and MUCH MORE" [Opened]
08:49 kode54: no
08:49 kode54: this is about a shader compilation failure
08:49 kode54: which, in this case, causes the app to spew an int 0x3 crash, since it has debug breakpoints on shader compile errors
08:53 kode54: aha
08:53 Kayden: depending on the shading language version, that is technically an app bug. it would have to be color /= 4.0
08:53 kode54: aha
08:53 kode54: shader does not use any version tags
08:54 Kayden: yeah, then it gets 1.10 which doesn't support any implicit int -> float conversions
08:54 MrCooper: okias[m]: https://paste.centos.org/view/92055d76
08:54 kode54: looks like Windows compiler for whatever drivers this was made with just accept the error as a quirk, which is broken
08:54 Kayden: If I recall correctly GLSL 1.20 does though
08:55 Kayden: I would expect force_glsl_version=120 to fix it
08:55 Kayden: (as an environment variable)
08:56 Kayden: (that just tells mesa to pretend no #version line means 1.20)
08:56 Kayden: for a long time, some of the closed drivers interpreted no #version line as "the latest version" - which is bogus - but made things like that often work
09:00 Kayden:-> zzz
09:00 MrCooper: good night
09:03 kode54: yup, that also fixes it
09:08 mlankhorst_: ickle: did you have a newer version of extract execbuf flags from i915_vma? mine fails, wondering if you had a new version or if I should just debug it
09:55 mlankhorst_: nm think I found it
09:57 okias[m]: MrCooper thank you.
10:03 MrCooper: np
12:29 daniels: robclark, seanpaul: is this what qcm does? don't you secretly virtualise planes behind the scenes? https://lists.freedesktop.org/archives/wayland-devel/2020-January/041131.html
14:01 serkanvb: hi. I would like to know if it is possible to turn off/on a monitor and change the resolution by using libdrm. I suspect one has to use drmModeSetCrtc. any help would be appreciated
14:03 pq: serkanvb, as a command line tool, no. You'll have to talk to your display server instead.
14:04 karolherbst: ehhh.. can we get rid of this auto downloading of build time dependencies? or is there at least some option to disable it?
14:04 serkanvb: pq: it is not guaranteed that the machine has x11 or wayland. I am only sure of the driver which is vmwgfx.
14:05 serkanvb: pq: is this about 'only one entity can be the master of the kms API"?
14:05 pq: serkanvb, there is no common way. You have to talk to the display server, or if it's about fbcon I'm not sure that even supports changing anything.
14:06 pq: serkanvb, yes.
14:06 pq: karolherbst, --wrap-mode=nodownload?
14:07 karolherbst: pq: thanks.. that helps
14:07 pq: serkanvb, there is no Wayland way either. btw,
14:07 serkanvb: pq: I have seen libdrm example making query of the devices, connectors, etc. they work on x11. but I guess changing monitor setup does need more than just querriying
14:07 pq: serkanvb, yes.
14:08 karolherbst: the nameing "wrap" is a bit odd as even if you see it in meson configure you don't know it's that what you are looking for
14:09 pq: kerberizer, only wraps ever download stuff, unless the project explicitly does it in its scripts.
14:09 pq: sorry, karolherbst ^
14:09 serkanvb: pq: this is for controlling the number of the monitors and their resolutions of a virtual machine. currently it is done thru the calls to vmwgfx. but I cannot find a way to disable/enamble monitors thru that API. so I thought using libdrm directly might be a better solution
14:09 karolherbst: pq: well.. right now if you forgot to install libz and expat devel packages, meson just downloads those deps
14:09 karolherbst: when building mesa
14:10 pq: serkanvb, nope, won't work.
14:10 serkanvb: pq: ok. can you think of any other way than going thru display server?
14:11 pq: serkanvb, whatever display server you might be running would either overwrite your settings immediately or get very confused as things stopped working if you were able to do that.
14:11 pq: serkanvb, no.
14:11 pq: serkanvb, going through the display is the intended way.
14:11 serkanvb: pq: ok. thanks a lot. at least that confirms my suspicions
14:11 pq: *display server
14:11 serkanvb: ok
14:16 serkanvb: pq: I just wonder what is the use case of the libdrm then? is it intended to be used when there is no display server and one wants to drawing and GPGPU etc?
14:18 pq: serkanvb, libdrm is a library, not a tool. Probably all display servers on Linux use it.
14:19 pq: libdrm is primarily a convenience wrapper around kernel DRM KMS ioctls.
15:01 karolherbst: heh.. is there still no solution in meson when you have a cross file but also pass in c_args into the build?
15:02 karolherbst: or am I missing something?
15:03 MrCooper: solution for what problem exactly?
15:04 karolherbst: command line c_args overwrite cross compile c_args
15:04 karolherbst: so the -m32 is gone
15:05 MrCooper: using an actual cross compiler instead of -m32 should avoid that
15:06 karolherbst: ...
15:07 karolherbst: yeah.. maybe that's actually the better thing, let me see
15:08 karolherbst: well, fedora doesn't seem to have those
15:08 karolherbst: at least not for i68
15:09 karolherbst: 6
15:10 karolherbst: MrCooper: anyway.. there still need to be a solution to kind of not overwrite what you put in the cross file
15:10 karolherbst: one way or the ohter
15:10 MrCooper: yeah, just noticed that as well :(
15:11 MrCooper: well, with a cross compiler there should be no need for special flags
15:11 karolherbst: well.. we suggest such files though: https://www.mesa3d.org/meson.html
15:11 karolherbst: "32-bit build on x86 linux:" part
15:12 MrCooper: AFAIR I could never get that to work
15:12 karolherbst: well.. did you pass in custom c_args ;)
15:13 MrCooper: don't remember, I switched to cross compilers a while ago on my Debian systems
15:13 karolherbst: anyway, usually a real 32 bit pkg-config thing helps a lot getting rid of the 64/32 bit library mix
15:14 karolherbst: otherwise pkg-config finds 64 bit libs in your 32 bit build and that is super annoying
15:14 karolherbst: I mean, I know it works, I just have a new system with a clean installation here
15:41 robclark: daniels: yup, we do that for 4k scanout and various other things... mdp5 does it a bit better than dpu
16:47 maccraft123: bbrezillon: can we talk on /query?
16:57 daniels: robclark: is it all virtualised planes?
16:57 daniels: or does that leak into userspace at some point?
17:13 robclark: daniels: virtualized
17:14 robclark: mdp5 also picks hwpipes (sspp's) based on whether scaling/yuv/etc is required.. and sooner or later I think we'll teach dpu to do the same
17:15 robclark: the hw also has some tricks, in certain cases it can re-use the same sspp for two planes, etc.. so we can have 1 sspp to two planes, or 2sspp for one plane
17:15 robclark: w/ atomic state, it isn't so hard to handle that in the kernel
17:16 daniels: heh
17:19 robclark: it might be kinda nice to extend the atomic interface so userspace could just hand the kernel a bunch of layers and have the kernel tell userspace which layers it should handle on the gpu.. I guess that basically becomes hwc then..
17:22 daniels: yeah, DRM_IOCTL_HWCOMPOSER2
17:22 daniels: or DRM_IOCTL_LIBLIFTOFF
17:25 robclark: heheh, yeah.. although it might be simpler to just extend the return status per kms obj that you want to set properties on, so some planes can fail and others succeed..
17:26 daniels: meh, the brute-force works well enough atm I think
17:27 daniels: and it lets userspace do the optimality/criticality sort to determine which views are going to hit composition rather than direct scanout, rather than putting that into the kernel
17:27 daniels: e.g. userspace knows which surfaces are the most frequently updated, the kernel doesn't
17:28 vsyrjala: at least in i915 we abort everything as soon as anything fails, so per-obj errno wouldn't really work without some rearchitecting
17:29 robclark: hmm, I could see brute force sucking if you were trying to make heavy use of sub-surfaces
17:29 robclark: as far as priortizing, sort the planes in order of priority before calling ioctl
17:30 robclark: vsyrjala: thb I haven't thought that much about implementation, but if userspace sorted order of planes updated in ioctl, you could just mark everything after the first fail as no-good, I guess
17:31 daniels: mm, but surely that's going to end up in the kernel pretty much just doing a while (req->num_planes > 0) { if (atomic_check(req) == 0) break; req->num_planes--; }
17:31 daniels: which isn't really a huge amount less overhead than userspace doing the same thing
17:32 robclark: yeah, but 1 ioctl for test per frame, instead of N.. I guess doesn't make sense if N is small, but if started to get into 10's or so maybe it matters..
17:33 robclark: but it would be more useful if helpers didn't bail after first fail..
17:33 robclark: esp for hw that can do tricks like multiple planes per hw pipe..
17:34 vsyrjala: plowing on after an error seems hard. lots of state you simply can't check later if some of the earlier results are junk
17:36 robclark: I guess it would only make sense at the granularity of whole kms objects (ie. so when one plane fails, just revert it's state?) As long as driver did checks that mutate it's global atomic state last, I think that could be workable
17:37 robclark: (that said, it isn't something that I'm about to start working on.. plenty of lower hanging fruit if I had spare time for kms)
20:21 linearain: hello, does anyone know if Sis (silicon integrated systems) onboard gpus (sis mirage 1, sis662 on intel d201gly2a mobo) have 3d acceleration?
20:21 linearain: i mean if there are any drivers for it on linux
20:23 airlied: nope
20:27 linearain: airlied, a random question, if directx works on windows, does that necessarily mean the gpu also supports opengl? opengl doesnt seem to work though
20:30 kisak: there's no hard requirements in OpenGL, you're allowed to fake any missing hardware support on the CPU, but it might be so slow that it's not worth the effort
20:33 airlied: linearain: those old SiS might be able for DX7/8, or GL 1.4
20:33 airlied: ah dx7
20:33 linearain: airlied, well it runs gta 3 well
20:34 HdkR: Latest Snapdragon devices are only shipping D3D drivers on Windows even
20:43 linearain: i thought i might make a minimal pc from it but i guess it will just have to be a headless server some day
20:56 robclark: HdkR: did qcom ever ship gl on windows? I assumed qcom's windows stuff was d3d only (and I also assume that is why they have some gl features in hw that aren't in gles)
21:01 HdkR: robclark: I don't believe so
22:11 danilo82: hello