06:45saru: I want to load a kernel module using debugger. Does gdb allow that ? Any documentation to read will be helpful
06:56EdB: karolherbst: sure
07:06MrCooper: DPA: -2 is -ENOENT, meaning the GEM handle you passed to drmModeAddFB* isn't valid (for the DRM file descriptor you passed in)
07:07soreau: saru: https://01.org/linuxgraphics/gfx-docs/drm/dev-tools/gdb-kernel-debugging.html
07:11saru: Thanks soreau.
07:19DPA: MrCooper: Thanks, I thought I had checked that the GEM handle was allocated for the right DRM file descriptor and that it hadn't been destroyed yet, but I'll doublecheck tonight, maybe I missed something...
07:21MrCooper: how do you get the GEM handle?
07:24DPA: MrCooper: It's being allocated right here: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c#L1056
07:26MrCooper: and the DRM file descriptor is the same one as passed to gbm_create_device ?
07:27MrCooper: hold on, that line assigns a gbm_bo pointer, not a GEM handle
07:28MrCooper: you'd need to retrieve the GEM handle with gbm_bo_get_handle(bo->gbm)
07:29DPA: MrCooper: I thought so, but I'll have to doublecheck when I'm back home, I'm not entirely sure anymore.
07:29DPA: The gbm_bo_get_handle and drmModeAddFB is here: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c#L1004
07:54pq: eric_engestrom, if the *display server* is showing broken content on areas not covered by blender, then it's a problem in the display server or lower. Since you say it happens on both Sway and Xorg, it's probably something below both: libdrm, Mesa, kernel.
07:55pq: eric_engestrom, FWIW, there have been reports on Weston to have two completely unrelated windows get their contents switched, which sounds bizarre to me.
07:56dj-death: pq: eric_engestrom established it's an actual hang ;)
07:57pq: DPA, AddFB, AddFB2, and AddFB2WithModifiers all take different arguments, so I'm not sure what you mean by "the same arguments".
07:59MrCooper: DPA: which Mesa driver / version are you testing?
08:01pq: dj-death, a hang that still shows two alternating old frame?
08:02dj-death: pq: yeah, I think it's probably just things failing in cascade...
08:11emersion: two alternating old frames → looks similar to a damage issue to me…
08:12MrCooper: sounds like the KMS flipping still works, but the GPU isn't drawing anything to the buffers anymore
08:13MrCooper: e.g. due to GL robustness functionality, where after a GPU hang drawing commands are dropped on the floor for existing contexts
08:14emersion: ah, we don't yet handle robustness in wlroots
08:14emersion: but that seems like wlroots context is still alive
08:15pq: but if you don't enable robustness in the compositor, would it still drop commands on floor?
08:15MrCooper: yeah, it's actually the kernel dropping them
08:15emersion: i'd just expect the compositor to die :P
08:15MrCooper: at least with amdgpu, but I assume could be the same with i915
08:16pq: any error returned anywhere, or do you have to use the robustness extension to figure out anything?
08:16MrCooper: the latter I think
08:16MrCooper: there might be a GL error state as well
08:16emersion: ah, so eglSwapBuffers and other functions like this fake success after gpu reset?
08:16pq: yeah, I'd expect the compositor to die or get errors on e.g. eglSwapBuffers or glGetError
08:17MrCooper: wouldn't be very robust, would it :)
08:17pq: exactly - the compositor didn't tell the driver to use robustness
08:17MrCooper: this is GL, not Vulkan
08:17pq: doesn't mean new extensions can't use a bit of sanity?
08:17MrCooper: there's no opt-in mechanism for extensions
08:18pq: um, yes there is: extensions expose API, you call the API to make use of the extension
08:19pq: if you change behaviour by merely exposing an extension, you break apps
08:19MrCooper: I'd have to check the robustness specs for something like that as well
08:20MrCooper: looking forward to the spec reference which requires that GPU hangs result in dying apps ;)
08:20pq: I'm just asking for to keep the behaviour that existed before robustness was implemented, then robustness is not explicitly enabled.
08:22pq: if the behaviour was no different, then I have no point
08:22MrCooper: I'm afraid it's a few years too late for that, given the robustness extensions exist already
08:22MrCooper: but it's possible they do have that functionality, I'd just need to check again as well
08:28pq: at least ARB_robustness seems to have no wording towards happens in apps that do not explicitly use the extension
08:28pq: *what happens
08:32pq: EGL_EXT_create_context_robustness says the default is EGL_NO_RESET_NOTIFICATION_EXT.
08:32pq: nothing is said about chaning EGL call behaviour
08:32pq: like SwapBuffers
08:33daniels: in practice, that behaviour is abort() at least on Intel
08:33pq: daniels, that would be better than the behavior described above.
08:36pq: in the above it was said that when robustness is implemented in a driver, you can no longer find out that anything might be wrong with the the GPU unless you call this new extension function. Everything will just keep running and not doing anything.
08:39MrCooper: FWIW, what I described is what I'd expect to happen with amdgpu after a GPU hang currently; i915 might be different
08:51EdB: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4974/diffs?commit_id=16812f9b83570b3bc5349f6d7502a53d4218684a
08:51EdB: I add to make some little change to be able to apply it because there is other change on your branch that are not on master
08:52pq: right, I take it that you don't insist amdgpu is doing it "right", and I'd say one could also do better than abort() even without robustness.
08:53pq: I'd wish a GPU hang/crash could be interpreted as a "power management event" so that EGL could raise EGL_CONTEXT_LOST.
09:02MrCooper: that would seem natural, given the robustness extensions talk about "lost context"
09:08daniels: I believe that does in fact happen, yes
09:08MrCooper: (side note, "Power Management event" seems to be a thinly veiled euphemism for "nvidia can't preserve VRAM contents across suspend/resume" though :)
10:46Vanfanel: Hi. With the ATOMIC interface, is there a way to avoid having to pre-multiply ALPHA in an ARGB8888 cursor that's used for FB_ID in a cursor plane?
10:46Vanfanel: With drmModeSetCursor(), alph-apremultiplication seemed to be mandatory
10:46Vanfanel: is it still mandatory?
10:47Vanfanel: In other words, is it possible to set an ARGB8888 cursor withour alpha-premultiplication using the ATOMIC interface? (ie: FB_ID prop of a cursor plane)
11:02karolherbst: EdB: ahh, yeah.. I went over it and it looked okay.
11:03MrCooper: Vanfanel: re your earlier question about getting an error with the primary plane disabled, https://patchwork.freedesktop.org/patch/387230/ may explain some things
11:06Vanfanel: MrCooper: If I understand correctly, that patch will allow setting props on a CURSOR plane even if the PRIMARY plane is disabled (ie: PRIMARE props FB_ID and CRTC_ID set to ZERO), right? On AMDGPU, I mean.
11:14emersion: Vanfanel: everything assumes pre-multiplied alpha right now, but if the "pixel blend mode" property is supported by the GPU, you can use something else
11:16emersion: see the docs: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties
11:16emersion: i should inline the docs in drmdb somehow
11:16Vanfanel: emersion: But "pixel blend mode" is not supported by all GPUs right now, is it?
11:17Vanfanel: Oh, even VC4 isn't supporting it yet, which is what I mainly target SDL2 KMSDRM backend. So alpha-premultiplication it will be for now :)
11:23Vanfanel: emersion: Also, what I am doing before destroying GBM buffers that are being read by the PRIMARY plane, is setting the FB_ID and CRTC_ID props of the PRIMARY plane to ZERO. It works right in VC4. Is that the right thing to do in well-behaving drivers?
11:25emersion: i think so, but some drivers may refuse to set those to zero without disabling the CRTC
11:25emersion: (active = 0, and detach all connectors)
11:25emersion: i don't remember the details
11:29Vanfanel: emersion: I believe that's related to the patch that MrCooper just pointed me to?
11:30emersion: let's see
11:30emersion: ah, yes
11:31Vanfanel: emersion: so, all in all, correct behaviour would be to accept FB_ID and CRTC_ID to ZERO, right?
11:31Vanfanel: emersion: ie, a driver not doing so is "wrong", right?
11:31Vanfanel: (without having to disable CRTC, etc.. )
11:32emersion: i don't think so
11:33emersion: > my opinion as a userspace developer is that enabling a CRTC without a
11:33emersion: primary plane has traditionally not worked, so userspace cannot *rely*
11:33emersion: on it ever working
11:34Vanfanel: emersion: so... what's the right thing to do then? Disable the CRTC (active = 0) and detach all connectors BEFORE setting FB_ID and CRTC_ID on the PRIMARY plane to 0?
11:35emersion: everything happens atomically, so the order doesn't matter
11:36emersion: but you'll need to disable the connector + CRTC + planes, yes
11:36Vanfanel: emersion: then I can safely destroy the GBM buffers read by the PRIMARY plane, then re-activate CRTC?
11:38emersion: but it's more about the KMS FBs than the GBM buffers
11:45Vanfanel: emersion: Thanks! :)
11:45emersion: np :)
12:28Vanfanel: emersion: Should it be possible to keep the PRIMARY plane connected with the CRTC and set FB_ID to 0? ie: only setting FB_ID to 0, while keeping the same CRTC_ID
12:29emersion: some drivers might understand it as "plane disabled" anyway
12:29emersion: but the correct way to do it is to properly disable the plane
12:29emersion: by setting both to zero
12:30Vanfanel: emersion: ok, so, to destoy the KMS buffers being read by the PRIMARY plane, is: 1) Disconnect the CRTC 2) set the plane CRTC_ID and FB_ID to 0 3) delete the KMS buffers
12:30Vanfanel: emersion: am I right?
12:32emersion: also set the connector's CRTC_ID to zero?
12:33Vanfanel: emersion: ok
12:34pq: Vanfanel, more like: 1) set and commit all relevant KMS props; 2) ensure the atomic commit has finished; 3) destroy buffers.
12:37linkmauve: dj-death, pq, that flipping of older frames looks exactly like what happens on Weston (running on iris) when displaying a PRIME buffer from amdgpu and the AMD GPU crashes.
12:38Vanfanel: pq: Yes, I will do blocking atomic_commit, but inside your step 1, I guess it is: 1) Set CONNECTOR prop CRTC_ID to 0, set CRTC prop ACTIVE 0 and CONNECTORS 0, set PLANE props FB_ID and CRTC_ID to 0 -> ATOMIC COMMIT all that
12:38linkmauve: I’ll look into robustness if that could make Weston resume after that happens.
12:38Vanfanel: pq: right?
12:38pq: Vanfanel, yeah, sounds about right
12:39Vanfanel: pq: thanks :)
12:40MrCooper: linkmauve: does it work again after restarting the app using PRIME?
12:41emersion: ah, right, it's important to block
12:42pq: linkmauve, but weston never has a context on amdgpu in that case, does it?
12:43pq: you'd need the robustness code in the app, not weston
12:45MrCooper: right, and the response to a lost context is creating a new one, same as restarting the app
12:48alyssa: I'm afraid to ask about this horrifying edge case but..
12:49alyssa: Is it possible to use point sprites with a fragment shader?
12:49alyssa: In particular, replacing a varying input, but also reading gl_PointCoord?
12:49alyssa: and having different orientations for the point sprite replacement vs the fragment builtin?
12:49alyssa: the *-compat.pdf specs are... scary
12:52linkmauve: MrCooper, I don’t know, Weston stops rendering anything after that, I have to stop it (Ctrl-Alt-Backspace works usually, not always) and then restart it.
12:53alyssa: I guess this is one of those edge cases so obscure nobody will notice if it's broken :p
12:53linkmauve: pq, no, it doesn’t have a context, but maybe iris considers Weston’s context to be busted because it’s waiting on amdgpu’s buffer which will never happen.
12:54alyssa: oh, it looks like point sprites are only defined at all for fixed-function frag, so it doesn't matter :+1: thank you
12:54pq: linkmauve, I would assume amdgpu's buffers simply don't have anything to wait for at that point.
12:55linkmauve: They mostly don’t exist anymore, since the card is completely unusable at this point.
12:55pq: linkmauve, was the app fullscreen or windowed? Does the whole weston stop updating, or just the output, or just the window?
12:56linkmauve: I tested both, same behaviour.
12:56linkmauve: But even windowed it was going to a plane IIRC.
12:56pq: linkmauve, no, no. The buffers exist just fine. They just don't get written to.
12:56linkmauve: Does the buffer exist if the card (and thus its memory) doesn’t?
12:57pq: memory does not disappear just because GPU stops... unless there is some IOMMU action that needs GPU alive?
12:57linkmauve: I only tested with one output but I could try with more; the whole weston and its only output stop updating (but I do get the old frames alternating when I e.g. move the pointer).
12:58pq: or do you mean that the whole card disappears from the PCI bus?
12:59pq: linkmauve, and you are sure Weston was on iris, not amdgpu?
13:00linkmauve: I get this in loop, not sure about the PCI bus, dmesg from back then doesn’t indicate anything about that:
13:00linkmauve: [ 242.453656] amdgpu: [powerplay]
13:00linkmauve: failed to send message 200 ret is 0
13:00linkmauve: pq, certain.
13:00linkmauve: When I run Weston on amdgpu instead, it freezes entirely and start showing weird colours.
13:01pq: it's hard to imagine how it can pull weston over the table like that
13:02linkmauve: I guess this calls for more debugging. :)
13:05TheRealJohnGalt: "it freezes entirely and start showing weird colours." sounds like usual crash behavior for amdgpu.
13:08linkmauve: Yeah, it happens a few minutes after starting a game, seemingly less quickly if the game isn’t very GPU intensive but it still always happens.
13:08linkmauve: A shame because otherwise this GPU seems pretty capable. :(
13:09linkmauve: And I have no idea where to start with debugging.
13:14Vanfanel: emersion: Does CRTC even have a CONNECTOR prop? According to https://drmdb.emersion.fr/properties?object-type=3435973836, it does not...
13:15Vanfanel: emersion: I am asking because you said: < emersion> (active = 0, and detach all connectors)
13:15emersion: because multiple connectors can be attached to the same CRTC
13:15emersion: instead, connectors have a CRTC_ID prop
13:16Vanfanel: emersion: so I have to do CRTC_ID 0 on the CONNECTORs instead, right?
13:17emersion: that's a lot of props to toggle, but at least all props agree on what the state should be
13:36pq: linkmauve, you sure it's not overheating? :-)
13:37linkmauve: Pretty sure, when it crashes on a light game I can still see it at like 35℃ over ssh (using sensors).
13:37TheRealJohnGalt: Unstable factory OC?
13:37linkmauve: It’s just much faster on a more intensive game, where it’ll go to like 70℃.
13:37linkmauve: TheRealJohnGalt, how can I check that?
13:38TheRealJohnGalt: Well, is it factory overclocked?
13:38linkmauve: I don’t know. :x
13:39linkmauve: Is there a tool I could get this information from?
13:40TheRealJohnGalt: linkmauve: there's /sys/kernel/debug/dri/0/amdgpu_pm_info to see clocks and compare to reference to know if factory overclocked.
13:41TheRealJohnGalt: You can also use the sysfs interfaces with amdgpu.ppfeaturemask=0xffffffff set to underclock and see if there's a change. There are also simple scripts to help, like https://github.com/sibradzic/amdgpu-clocks
13:42linkmauve: https://linkmauve.fr/files/amdgpu_pm_info.txt (but I only just booted the card, didn’t try rendering anything yet).
13:43linkmauve: TheRealJohnGalt, thanks, I’ll have a try. :)
13:45TheRealJohnGalt: Oh, would need to be loaded to show clocks there. I have custom table set right now so I'm not positive this will do it for you, but you could check /sys/class/drm/card0/device/pp_od_clk_voltage to see if you can see all clocks there to know if factory overclocked.
13:46TheRealJohnGalt: example: http://ix.io/2v6x
13:47linkmauve: I don’t even have this file here, I guess I have to reboot with amdgpu.ppfeaturemask=0xffffffff first.
13:47linkmauve: Or hmm, could I rmmod amdgpu and modprobe it with this argument?
13:48TheRealJohnGalt: I unfortunately don't know. Was just an idea that perhaps it has a factory oc that's unstable (wouldn't be the first time).
13:54Vanfanel: emersion: just to sum up props, please confirm if you can: PRIMARY PLANE-> CRTC_ID, FB_ID = 0; CRTC in use-> ACTIVE = 0; CONNECTOR in use-> CRTC_ID = 0;
13:54Vanfanel: emersion: am I missing something else on the "to-do" list before securely destroying the KMS buffers used by the PRIMARY plane?
13:59Vanfanel: pq: I would also value your input here ;)
14:00pq: Vanfanel, I don't remember that much off-hand. Grab https://github.com/ascent12/drm_info , look at all the properties it lists, and check their docs in https://www.kernel.org/doc/html/latest/gpu/drm-kms.html .
14:04emersion: that sounds fine, can't remember anything else
14:06Vanfanel: emersion: And after blocking ATOMIC COMMIT & KMS buffers destruction, I should re-connect the CONNECTOR to the CRTC, and set the CRTC ACTIVE againg, right?
14:07Vanfanel: pq: I have found WAY more convenient way to look at OBJ/PROPS tables here: https://drmdb.emersion.fr
14:07Vanfanel: pq: I believe that's the same information, right?
14:08pq: you can see it asks you to run drm_info to submit your data, so yeah :-)
14:09pq: if that website also has precise link to UAPI docs, that would be awesome
14:25Vanfanel: emersion: Also, when re-setting CRTC prop ACTIVE to 1 and CONNECTOR prop CRTC_ID to the crtc_id of the CRTC in use, I would need to re-set PRIMARY PLANE props FB_ID and CRTC_ID to non-zero values, all in the same atomic request, right?
15:02emersion: > if that website also has precise link to UAPI docs, that would be awesome
15:02emersion: actually i've been working on exactly fixing this
15:03emersion: deploying now…
15:04Yuti: Setting link_status as BAD using drm_connector_set_link_status_property function in atomic enable causes deadlock. Can we use this set_link_status_property in atomic functions?
15:04emersion: and deployed!
15:04emersion: drmdb now displays kernel docs
15:04emersion: example: https://drmdb.emersion.fr/properties/3435973836/ACTIVE
15:07emersion: hrm, my little server VM is now spinning at 100% CPU, i should really change how the DB works…
15:10Vanfanel: emersion: Also, when re-setting CRTC prop ACTIVE to 1 and CONNECTOR prop CRTC_ID to the crtc_id of the CRTC in use, I would need to re-set PRIMARY PLANE props FB_ID and CRTC_ID to non-zero values, all in the same atomic request, right? (sorry to repeat, I got disconnected)
15:33emersion: all right, should be fixed now
15:34emersion: Vanfanel: yes
15:35pcercuei: what are "fences"?
15:45bl4ckb0ne: pcercuei: synchronization method
15:49Vanfanel: emersion: Then, what FB_ID should I set the PRIMARY PLANE to??? I was told that the original FB where the TTY console lives is not guaranteed to be there...
15:49emersion: if you want to enable the plane, you have a new FB, right?
15:50emersion: if you don't have a FB, you can keep the plane/CRTC/connector disabled
15:50Vanfanel: emersion: well, what if I am quitting the program? No new FB, the old was just destroyed...
15:50emersion: then disable everything?
15:52Vanfanel: emersion: oh! So I can just leave everything disabled after destroying the old KMS FBs?? No need to re-activate CRTC, no need to re-attach CONNECTOR to the CRTC, no need to set FB_ID and CRTC_ID of the PRIMARY PLANE to non-zero values?? Just leave and hope that TTY takes over again?? :D
15:52emersion: yeah, the TTY will take over again
15:52Vanfanel: emersion: not in AMDGPU.. in VC4, it does
15:53emersion: are you releasing the session properly?
15:53emersion: hm, weird that it works with one driver and not the other
15:53emersion: > yeah, the TTY will take over again
15:53emersion: incorrect, fbcon will take over again
15:54Vanfanel: emersion: what do you mean by release the session properly? I close the drm FD on quit.. isn't that enough?
15:56emersion: ah, so you don't do any of the TTY ioctls?
15:58pcercuei: bl4ckb0ne: thanks, so can I somehow "lock" the DRM driver so that it temporarily pauses operations during a modeset?
16:00Vanfanel: emersion: nope... There's been many years since I did an ioctl. What should I do to properly let the FB go?
16:01Vanfanel: emersion: if you have an example at hand I could use... It can't be complicated, can it?
16:04emersion: i have no idea how a KMS client without any kind of TTY handling is supposed to work wrt. releasing the TTY
16:05emersion: what i know is that KMS clients need root to open /dev/dri/card0 in some cases
16:05emersion: and to open input devices as well
16:06emersion: so generally they offload the work of opening devices to a daemon
16:06emersion: TTY handling is also necessary to allow users to VT-switch (Ctrl+Alt+Fn)
16:08emersion: tl;dr you have two ways to handle TTY: (1) do it yourself and you need root (2) offload the work to a daemon (logind, seatd)
16:09emersion: if you want an easy way to handle all of this, you can use libseat: https://git.sr.ht/~kennylevinsen/seatd
16:10Vanfanel: emersion: ok, thanks! :)
16:15emersion: btw, on amdgpu switching from my compositor with a screen off to fbcon works and enables the screen
16:16agd5f_: hanetzer, AMD GPU driver developer?
16:16pcercuei: emersion: https://github.com/opendingux/SDL
16:17pcercuei: emersion: we worked on that recently. Uses KMS and libudev for video/input, no TTY handling required
16:17pcercuei: runs as non-root as long as your user is in the video & audio groups
16:17pcercuei: so it's definitely possible
16:18emersion: does it handle Ctrl+Alt+F2?
16:18emersion: my guess is that it doesn't
16:18pcercuei: probably not, no
16:18emersion: how does it handle input?
16:18emersion: evdev? libinput?
16:19pcercuei: it reads evdev nodes
16:19emersion: root is required for this
16:19emersion: well, otherwise a keylogger would be too easy to write :P
16:19emersion: maybe you're in the input group?
16:20emersion: or somehting
16:20emersion: that essentially allows any app to be a keylogger
16:20emersion: (probably same for video btw)
16:20pcercuei: this is for a small MIPS handheld, we don't care about keyloggers there ;)
16:20emersion: yeah, fine for embedded, not fine for general use :)
16:22emersion: but yeah, i don't know why Vanfanel is hitting this disabled screen issue not turning back on when the app exits
16:22emersion: since it works fine for me
16:22Vanfanel: emersion: It's only happening in AMDGPU.. maybe AMDGPU is missbehaving. The same exact code works great on VC4.
16:23pcercuei: nothing in dmesg? I get that when the DRM driver OOPSes
16:23Vanfanel: pcercuei: let me see
16:28Vanfanel: pcercuei: There's this -> "[amdgpu]] Atomic check failed with err: -22". BUT it's coming from the failure to set a cursor on the CURSOR PLANE while CRTC is disabled (ACTIVE=0, connector CRTC_ID=0)
16:29Vanfanel: If I comment out the cursor stuff, there are no atomic -22 failures
16:30pcercuei: do you close the file descriptor of the DRM dev node in your app?
16:30pcercuei: or open() with O_CLOEXEC?
16:31Vanfanel: pcercuei: yes, I do "close(viddata->drm_fd);"
19:15karolherbst: EdB_: you might want to pull this commit into your CL 1.2 branch as well to deal with reqd_work_group_size: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/5855a7c362b1079b5e7a81e3a3ecbc87f440e5a9
20:27DPA: The device file used in bo creation and drmModeAddFB have been the same, I've now doblechecked that.
20:27DPA: MrCooper: The mesa commit I was trying it with initially was 782ba8d3ae55af392da8ca829f3a185c10bbecfc with mr 3449 applied, but I've now also tried
20:27DPA: the version tagged as mesa-20.1.6 with mr 3449 applied, with the same result.
20:27DPA: I'm using libdrm commit 9fbae6f6ad7994240e25e7823573604d4a9be4c4.
20:27DPA: I'm trying this on a Librem5 devkit, so the drivers involved are mxsfb, dcss and etnaviv, I think.
20:27DPA: pq: This failure happens when I try to enable the output of the second of both dri devices in Xorg, regardless which one that is. The first one
20:28DPA: which it enables automatically works just fine.
20:28DPA: pq: With "the same arguments", I meant that the arguments passed to those functions when using the Xorg configuration using which drmModeAddFB works,
20:28DPA: compared to the ones passed to them, for the same device, using the configuration where drmModeAddFB fails, are the same.
20:28DPA: This even happens if I configure X to use independent Xscreens for the devices, so it has nothing to do with the prime stuff in Xorg.
20:28DPA: If I configure X in that way (mutiple Xscreens), I can make both screens work if I disable glamor for the second one (in that case it uses drm dumb buffers
20:28DPA: instead of allocating one with gbm). Disabling glamor for the first one doesn't make a difference in that case.
21:43Prf_Jakob: keithp: Howdy, do you have a newer version of your VK_GOOGLE_display_timing patch laying around?
21:46keithp: Prf_Jakob: I haven't updated it in a while; is there some chance it will get merged?
21:47Prf_Jakob: I will look at it myself and kick and scream at the people here at Collabora that are more qualified to look at it as well.
21:47Prf_Jakob: So hopefully that's a yes :)
21:49Prf_Jakob: My two attempts at getting it into master or a tree from around Jan failed.
21:49kisak: Prf_Jakob: looking at my notes, https://lists.freedesktop.org/archives/mesa-dev/2018-November/209762.html is the most recent revision from keithp, and I have a slightly modified variant that compiles against 19.2.6 (I dropped it in my 19.3 build)
21:50keithp: kisak: awesome. sounds like I should go figure out where things have changed and get it working again
21:50Prf_Jakob: kisak: I think this is the latest one https://lists.freedesktop.org/archives/mesa-dev/2020-January/224044.html
21:51kisak: okay good, that's a good bit newer than when I dropped it
21:51keithp: january seems so long ago now
21:52Prf_Jakob: How young and innocent we where then :P
21:59ccr: "long, long time ago, on a #dri-devel far, far away .."
21:59keithp: I could leave the country back then
22:00craftyguy: mareko: your series seems to be causing lots of regressions on Iris, on all platforms that use that driver: https://mesa-ci.01.org/mesa_master/builds/22205/group/63a9f0ea7bb98050796b649e85481845
22:00mareko: craftyguy: do you know the first bad commit?
22:01craftyguy: mareko: not yet, ngcortes is bisecting to find it
22:04pendingchaos: probably https://gitlab.freedesktop.org/mesa/mesa/-/issues/3456 ?
22:05craftyguy: yeah that seems likely
22:05craftyguy: Kayden: ^
22:05craftyguy: nchery: beat us to it :P
22:06Kayden: mareko: it's because of nir_lower_interpolation... nir_intrinsic_load_fs_input_interp_deltas doesn't have a SEMANTICS const_index
22:06Kayden: but add_const_offset_to_base_block is trying to fetch it
22:06Kayden: in nir_lower_io
22:07Kayden: I'm not sure whether it makes sense to add them there, though?
22:08Kayden: it probably does...that has a location, and location seems to be in semantics
22:14Kayden: I suspect https://gitlab.freedesktop.org/kwg/mesa/-/commit/a4f473dd7b3b14de8ad08539e4bb58bcc543f3fa will fix it?
22:14Kayden: craftyguy: just sent that to my dev/kwg CI branch
22:14craftyguy: Kayden: ah thanks. I was about to send it
22:15Kayden: guessing other drivers aren't using this bit of lowering so it got missed
22:15Kayden: I thought freedreno did, but maybe not
22:24Prf_Jakob: keithp: Give me a ping when you have the patch updated.
22:33ngcortes: Kayden, craftyguy, mareko bisected to 01ab308edc78cda777bc66f2e8110fbd8c21aa18 fwiw
22:35Kayden: Yep, makes sense
23:18karolherbst: jenatali: how important is it for you to pass the CTS on real hw as well? I am wondering if I should focus on the precision lowering for CL
23:19jenatali: karolherbst: The Khronos certification criteria for mapping layers is on 2 drivers, at least one of which must be hardware
23:19jenatali: I wouldn't complain about having more high-precision lowering available :)
23:20karolherbst: okay, cool
23:21karolherbst: kind of want to get most of my stuff merged before moving on to new things :D
23:23karolherbst: I managed to end up with 92 patches now...
23:23karolherbst: most of them are just random MRs not being merged though
23:24jenatali: Yep, sounds about right
23:24jenatali: Is there something I should be trying to push through that I'm not at the moment?
23:24karolherbst: that libclc fma issue is really annoying :/
23:24jenatali: Yes, I agree :P
23:24karolherbst: it kind of feels like I talked with somebody about this like a year ago
23:25karolherbst: let's see..
23:25karolherbst: nope.. most of the patches are nouveau or clover related
23:31karolherbst: fp64 will be terrible to support
23:31karolherbst: that kills compilers
23:42karolherbst: jenatali: ehhh... my idea won't work as a nir lowering pass :/
23:42karolherbst: native_sqrt vs sqrt
23:42jenatali: Ahh, native has no precision requirements
23:43karolherbst: but I also kind of don't want to depend on the precise flag to be set?
23:43karolherbst: jekstrand: any ideas on how to deal with it?
23:43karolherbst: I kind of don't want to spread the precision lowering around
23:44jenatali: karolherbst: Add a new opcode, and lower it to the native one if the driver claims it's precise?
23:44jenatali: Though I don't really see much benefit to that beyond just implementing it in vtn
23:44karolherbst: I kind of also don't want to add multiple variants of the same opcode if not required :D
23:45karolherbst: jenatali: with the clc stuff we don't set exact on the alu ops, right?
23:45karolherbst: but I also kind of don't want to abuse .exact for that
23:45jenatali: No we don't currently
23:46karolherbst: the issue I kind of have is that even "spirv instructions" don't really meet the requierments CL has.. or rather the requierments are different compared to GL/Vulkan
23:46karolherbst: I don't think there is much else besides (r)sqrt and div but ....
23:46karolherbst: still.. I don't like to have that be done in multiple palces
23:47jenatali: I just found a super fun perf bug in CLOn12... I was doing a full recompile (spirv -> nir -> dxil -> driver) if the app created a second kernel from the same program. Whoops
23:47karolherbst: it's kind of fun that spir-v doesn't have sqrt ...
23:48karolherbst: it's inside the glsl spec extension
23:48karolherbst: and I guess fdiv should be handled the same :D
23:49karolherbst: ohhh.. libclc doesn't have a fp64 ffma implementation? ufffff
23:50karolherbst: but it sounds like it loweres that to int math so shouldn't be all that much worse :D
23:50karolherbst: fp64 in CL is so overkill
23:51jenatali: Yeahh it's assumed that if you're doing fp64 you have real implementations of it I guess?
23:51jenatali: Same for fp16
23:51keithp: fp64 lowered to integer maths? hilarity ensues
23:52karolherbst: jenatali: tell me which GPU does have it :p
23:52mattst88: keithp: yeah... I had to do that for Icelake...
23:52karolherbst: I think on nv we have like ... 5 fp64 ops natively?
23:52keithp: mattst88: presumably ieee compliant arithmetic
23:52jenatali: DXIL's in a similar boat IIRC
23:52karolherbst: and three of them are f2f, i2f and f2i :p
23:53jenatali: Just the conversions and a couple basic ops
23:53karolherbst: there are a few more, but you get the idea
23:53mattst88: karolherbst: having mul/add/mad/cmp would solve like 80% of the problems
23:53mattst88: keithp: yeah, but kind of worse -- ICL doesn't have any fp64 hardware at all, so we have to emulate everything
23:54karolherbst: turing has 6: dfma, dmul, dsetp, f2i, i2f and f2f
23:54karolherbst: so yeah
23:54karolherbst: the ones you asked for :p
23:54imirkin: karolherbst: i mean ... there's dadd too, no?
23:54Kayden: craftyguy, ngcortes, mareko: looks like my patch fixed most of the breakage, but edgeflags are still broken.
23:54karolherbst: imirkin: nope
23:54imirkin: there used to be ;)
23:54karolherbst: but you've got dfma
23:54keithp: mattst88: that's awful
23:54Lyude: mattst88: lol really? why\
23:54imirkin: is add done with dfma? sigh
23:55karolherbst: imirkin: turing also doesn't have iadd
23:55imirkin: karolherbst: what about rcp/rsq? completely gone? or same helpers as there are on earlier gens?
23:55karolherbst: you either use iadd3 or imad
23:55hanetzer: agd5f_: btw. regarding the NAVI TILEd display/dc bug; is that something you'd actually be able to fix? (as in, have the hardware to do so?)
23:55karolherbst: imirkin: mhh.. let's see
23:55keithp: Lyude: one doesn't usually need to ask -- some spec required it, presumably :)
23:55karolherbst: imirkin: ahhh, right, we still have mufu
23:55mattst88: Lyude: there's a certain logic to it -- it's a super uncommonly used feature and it takes up a lot of die space
23:55mattst88: so if they cut it out, they can give you more EUs on the same sized die
23:55karolherbst: but still just the rsq/rcp variants with awfull precision
23:56Lyude: ah, makes sense
23:56mattst88: but since GL 4.0 requires FP64... the software people (i.e., me) gets stuck holding the bag
23:56imirkin: also a mild curiousity, the G200 (GTX 265/270/280) had fp64 add/mul, but no rcp/rsq.
23:56airlied: mattst88: it's a pity they didn't ask the sw people which bits would ahvd been useful :-P
23:56karolherbst: jenatali: I bet dxil has a bit more than we do :p
23:56imirkin: i had a branch where i tried to add support, but it didn't "just work" and i only had remote access, so ... it never happened.
23:57mattst88: airlied: no kidding
23:57karolherbst: imirkin: ohh, that is.. itneresting
23:57jenatali: Maybe, I didn't look too close beyond just seeing "oh there's like nothing here" and deciding we weren't going to support it yet :P
23:57karolherbst: imirkin: libclc kind of loweres everything on top of add/mul/mad
23:57mattst88: airlied: months and months later, the HW architect guy was baffled when I and a dude from the Windows driver team told him that implementing soft FP64 was horrible
23:57karolherbst: so that could be enough
23:57imirkin: karolherbst: yeah, that makes sense. and in fact the "lowering" we use on fermi+ for rcp doesn't involve the rcp64h thing (or the one for rsq, i forget)
23:57karolherbst: mattst88: :D no kidding
23:58karolherbst: for graphics that's not as bad though
23:58karolherbst: CL is brutal
23:59imirkin: the people who are more likely to want fp64 in CL are less likely to run that on intel gen hw :)