02:23 imirkin: pendingchaos: didn't you have a series to use SULDP everywhere, and implement the GL ext for not having to specify the read format?
02:55 karolherbst: imirkin: btw, any preference on gitlab vs mailing list? I think it would be easier to keep track of patches not merged yet than with patchwork and I could start putting all my more or less finished things as MRs on gitlab
02:56 imirkin: might be easier to keep track (questionable), but certainly makes it less likely to get reviewed
02:57 imirkin: i'm good at checking email, reading it, replying. gitlab's yet-another thing to log into and check
02:57 imirkin: and forget about
02:58 imirkin: the fact remains that the author of the patch has to want to get it in, in order for the patches to get the necessary attention
02:58 imirkin: whether they're no a mailing list, patchwork, gitlab, or where-ever
02:58 imirkin: on a*
03:07 imirkin: but ... i doubt anyone cares about my opinion, given that it's definitely happening
03:07 imirkin: and for people who're working on this stuff full time, perhaps it does make more sense
03:08 imirkin: which is the majority of the mesa contribution base
05:05 HdkR: imirkin: Oh, you thinking about getting shader_image_load_formatted supported?
05:05 imirkin: i'm sure pendingchaos sent patches
05:06 imirkin: https://patchwork.freedesktop.org/series/44872/
05:07 HdkR: ah
05:07 HdkR: Nice :D
05:07 imirkin: mareko had some minor comments on the first one
05:08 imirkin: pendingchaos: any interest in picking that up again?
05:09 HdkR: Hoping Intel picks it up on Gen 11+ or w/e it is to have it without hardware bugs :)
05:10 imirkin: hehe
16:13 stoatwblr: hi guys, what's support like for K1+K2+K20 in the same box?
16:13 stoatwblr: as in "for opencl purposes"
16:16 stoatwblr: and yes, I know that's an oddball setup to have in one box.
16:18 karolherbst: stoatwblr: nouveau doesn't support any compute API out of the box
16:18 karolherbst: but technically you could use them for compute without any issues, it just might be a little slow
16:18 stoatwblr: I noted it's tagged WIP
16:19 karolherbst: well I don't expect CL 1.2 to be supported in the next 5 years
16:19 karolherbst: except somebody else taks over after I am done with adding the general support for CL
16:19 karolherbst: and that's moving quite slowly
16:20 stoatwblr: would access to the devices assist?
16:20 karolherbst: no
16:20 stoatwblr: ok
16:21 karolherbst: I usually have access to various kind of hardware to test things. That's not the issue
16:21 karolherbst: it's more of a lack of developers kind of thing and more pressing issues
16:21 stoatwblr: I know that feeling
16:25 karolherbst: I hope that I am getting everything merged for getting CL 1.1 running (or at least what clover supports), but even support for images is questionable as it depends on various things
16:27 stoatwblr: ok
16:29 karolherbst: imirkin: I ran the GLES3 CTS and I think we might have new fails (or there are old, dunno): https://gist.githubusercontent.com/karolherbst/646e813e8fea0bad9b9abcf813082655/raw/0ed1486e78345fd662f0413d2b6a01c6bc67259b/gistfile1.txt
16:29 karolherbst: know anything about those?
16:29 karolherbst: the 5 first I know what those are about
16:29 karolherbst: I assume that those copy_tex_image_conversions tests are just new
16:30 karolherbst: hum "[GL_RGBA4]=>[GL_RGBA32UI] conversion [src target=GL_TEXTURE_2D, dst target=GL_TEXTURE_2D] caused [1286] error instead of GL_INVALID_OPERATION."
16:30 karolherbst: passes on intel though
17:03 karolherbst: ohh those are RGBA4 -> something conversions... meh
17:55 karolherbst: imirkin: mhhh, the CTS indeed hardcodes RGBA4 to be renderable :/
19:03 pendingchaos: imirkin: I think what's left for the series is to rebase, finish the 1st patch and for the 4th and 5th patches to be reviewed
19:03 pendingchaos: so I think I'll do the first two sometime
19:03 pendingchaos: I don't have my 1060 plugged in, so I can't easily test it
19:03 pendingchaos: but I think it should be fine, afaik nothing changed in a way that could break the series
19:06 karolherbst: imirkin: okay, so GL_RGBA4 is required to be color renderable for GLES
19:06 karolherbst: so I guess we more or less have to disable RGBA4 at least for GLES
19:51 karolherbst: ahhhh disabling RGBA4 leads to even more fails :/
19:58 imirkin_: yeah, i'm getting a bit sick of fighting the RGBA4 fight
19:58 imirkin_: i'm pretty sure i'm right
19:58 imirkin_: but ... everyone else is writing conformance tests that say i'm wrong
19:59 karolherbst: imirkin_: I think for GLES the situation is clear
19:59 imirkin_: "color renderable" doesn't necessarily mean what you want it to mean
19:59 karolherbst: ohh
19:59 imirkin_: it means "is a valid enum to be passed in in certain places"
19:59 imirkin_: but i'm fairly sure you can decline to render to an attached texture for any reason at all
19:59 imirkin_: including phase of the moon
19:59 karolherbst: okay so rendering into a texture might be enough to satisfy this
19:59 karolherbst: hum
20:00 karolherbst: but now with disabling it, it gets even more annoying
20:00 karolherbst: the CTS tries to copy RGBA4 into RGBA8
20:00 karolherbst: and expect this to fail
20:00 karolherbst: because bit size changes
20:00 imirkin_: ;)
20:00 karolherbst: but... we fall back to RGBA8 because RGBA4 isn't supported
20:00 imirkin_: that would fail on radeonsi too
20:00 karolherbst: so we do the copy
20:00 karolherbst: appearantly the test is happy with intel
20:00 karolherbst: didn't test radeonsi
20:01 imirkin_: they probably expose RGBA4 =]
20:01 karolherbst: ohh, probably
20:01 imirkin_: and they don't use the st/mesa code
20:02 imirkin_: [unless you were testing iris]
20:02 karolherbst: imirkin_: btw, I saw those black rectangles running nouveau in chromium here
20:02 imirkin_: yay
20:02 imirkin_: what gpu?
20:02 karolherbst: gm204
20:03 imirkin_: is that with the uniform whatever fixes?
20:03 karolherbst: currently on 2b876bc922
20:03 karolherbst: mhh let me check
20:03 imirkin_: which is newer than several months ago?
20:04 karolherbst: yeah, from this month
20:04 imirkin_: i wonder if we should just ask distros to not include nouveau_dri by default
20:04 karolherbst: that would be harsh
20:04 imirkin_: lots of people have lots of hard-to-debug problems
20:05 imirkin_: and aren't explicitly choosing to use nouveau
20:05 imirkin_: if you then install nouveau, then fine
20:05 karolherbst: right, but those weren't as bad if we wouldn't cause X to freeze eg
20:05 karolherbst: just because some channel got messsed up
20:05 imirkin_: but many times they do
20:05 karolherbst: that's what annoys me the most right now
20:05 karolherbst: was playing some game, channel broken -> X froze to death, no way to get into the tty
20:06 karolherbst: killing the application -> X unfreezes
20:06 imirkin_: yep
20:06 karolherbst: that's just a super stupid situation
20:06 karolherbst: maybe we should just sigkill the application from nouveau ...
20:07 karolherbst: I was able to have an event listener thing set up to handle that within mesa, but it doesn't work if the same application listens to vsync events as it's basically the same thing :(
20:07 karolherbst: so, no glamor or wayland compositors
20:08 karolherbst: skeggsb told me/us that the command submission rework would fix that as we would get notified about this through the API, but....
20:08 karolherbst: ...
20:09 karolherbst: this just sound like stupid issues we should be able to solve in no time
20:09 karolherbst: seriously
20:09 imirkin_: i guess you'll be sending a patch shortly then :p
20:09 karolherbst: thing is, skeggsb already wrote those
20:09 karolherbst: he just doesn't publish them as those changes are important for vulkan as well
20:09 karolherbst: and he wants to mockup those while working on a vulkan driver
20:10 karolherbst: and I just don't want to spend time writing patches and get told later "huh, I already have something like that"
20:15 karolherbst: *sigh*, I guess I could do event dispatching within libdrm to solve that vsync event issue. let's see how painful that would be
21:14 karolherbst: imirkin_: okay, maybe you know of a simple fix to solve that. Currently I do a poll of the nouveau_drm.fd to get whatever event the kernel module wants to pass me in. Thing is, for the vblanks we more or less do the same, but on a different fd. Now I have the issue that both events arrive at both fds used :/ any ideas?
21:15 karolherbst: the fd is created via a fcntl(fd, F_DUPFD_CLOEXEC, 3); of the fd passed into nouveau_drm_screen_create
21:52 pmoreau: karolherbst: I just saw you updated a couple of branches; I should be looking at “nouveau_nir_v9” for reviewing the final patches and running “nouveau_nir_spirv_opencl_hmm_v3” if I want to test it out, right?
21:57 karolherbst: nouveau_nir_spirv_opencl_hmm_v2 if you want to test it out
21:58 karolherbst: v3 needs some major rework I think
21:58 karolherbst: it works, but not that well
22:00 karolherbst: pmoreau: and “nouveau_nir_v9” for reviewing nir is correct