00:04imirkin_: jekstrand: fwiw this is what we do in nv50_ir -- an instruction may have a predicate, and if it's false, that ssa def just doesn't happen.
00:04imirkin_: and there's a "union" operation, which is like a phi, to combine inverted predicates
00:05imirkin_: e.g. a1 = x if p1; a2 = y if !p1; a = union(a1, a2)
00:05imirkin_: a lot like a phi
00:05imirkin_: but for non-edge-variables
01:00daniels: anholt_: shadeslayer had patches for generic BO naming out on dri-devel
01:02anholt_: daniels: ooh! nice
02:23Lightkey: https://www.mesa3d.org/relnotes/20.0.0.html "People who are concerned with stability and reliability should stick with a previous release or wait for Mesa 19.3.1. " :->
02:24kisak: patch it?
02:26kisak: https://gitlab.freedesktop.org/mesa/mesa/blob/master/docs/relnotes/20.0.0.html#L23 there's the line for you, make a merge request, mark it docs:
02:28kisak: (if my memory is right for skipping CI for docs)
02:41Lightkey: And take away the chance to show it around? Never.
03:55airlied: yay heaven renders
03:55airlied: my tcs fetch was broken for elts
03:58imirkin: and no piglit/deqp failed?
03:58imirkin: that's frightening
04:00airlied: imirkin: yep none failed!
04:01airlied: no piglits doing draw elements :-P
04:26Kayden: awesome work though! :)
04:41airlied: ah shader_runner doesn't support elements drawing
04:41imirkin: coz why would arrays and elements be different, duh!
05:45airlied: bleh draw defeats my attempts at making a simple test
06:34airlied: ickle: not sure why, but using latency top I occasionally see 1s latencies in __i915_gem_free_objects it really harshes my gnome-shell out
06:34airlied: running fedora 5.4.7 kernel
06:40airlied: okay llvmpipe tess rebased and ready for review/landing :-P
08:52pq: ajax, anholt, Kayden, see pointers from https://gitlab.freedesktop.org/mesa/drm/merge_requests/15
08:52gitbot: Mesa issue (Merge request) 15 in drm "WIP: RFC: Expose the DRM_IOCTL_HANDLE_SET/GET_LABEL with a userspace API" [Opened]
10:05ickle: airlied: we can stick a cond_resched() in there, but that's a mighty, mighty long list that must have accrued?
10:13maelcum: i'm getting compile errors in sfn here... pretty standard build configuration on linux. http://ix.io/2ci1
10:13maelcum: ‘dynamic_cast’ not permitted with ‘-fno-rtti’
10:15airlied: ickle: seems to back up under swap
10:15HdkR: maelcum: Time to enable rtti :)
10:16ickle: a new buffer per swap, no reuse? that'll be nice on !llc
10:16ickle: even for llc if it touches scanout
10:16ickle: anyway, cond_resched() it is then
10:19maelcum: HdkR: for the build system out of the box, not for me!
10:19maelcum: i have the strange idea that software should build with its own default configuration ;)
10:21pq: maelcum, makes one wonder how that got through CI.
10:21HdkR: Looking at meson it looks like if llvm is built without rtti then it can drop that flag in to the build flags
10:22HdkR: So whatever that system is built on probably has LLVM without rtti enabled
10:22pq: drop? you mean add?
10:22HdkR: yes, silly phrasing
10:23maelcum: it drops rtti :>
10:24pq: Is that an unfixable conflict? Aside from rebuilding LLVM with rtti.
10:25HdkR: Mesa already throws an error if you build without rtti but have nouveau or clover enabled. Looks like someone also needs to add a check for r600 now
10:25HdkR: Since sfn was added in December and needs it
10:26maelcum: option(LLVM_ENABLE_RTTI "Enable run time type information" OFF)
10:26maelcum: from llvm/cmake/modules/HandleLLVMOptions.cmake
10:26maelcum: seems like i didn't break it by setting an exotic flag
10:26HdkR: Yea, LLVM doesn't build with rtti by default :)
10:28maelcum: for now i'll just enable the flag in in llvm... *shrug*
10:29HdkR: Seems like it is still a bug in mesa meson though. Since r600 doesn't require llvm but requires RTTI
10:30HdkR: It's just LLVM options hecking with it :)
10:31HdkR: Something worthy of an issue being opened about it
11:48rellla: hi, what is the magic detecting flakes by mesa's CI? i mean, how are they marked as flakes?
12:33tomeu: rellla: if you refer to flakes in deqp, the runner has logic for repeating failed runs
12:34rellla: tomeu: ok thanks. i'm trying to fix lima ci, but everytime i add the newly reported flakes from the runner, a new one pops up :o
12:36rellla: https://gitlab.freedesktop.org/rellla/mesa/-/jobs/1696404 the most recent MR now doesn't have one though
12:41tomeu: rellla: yeah, I went through that with panfrost once, may be better to just fix them :)
12:42tomeu: have you already ran the flakes under valgrind or ubsan?
12:43tomeu: you may find something stupid that is faster to fix than to find the perfect list of skips
14:46shadeslayer: anholt: I could use with some advice on that patch btw, so if you'd like to discuss it, I'm happy to chat :)
14:49shadeslayer: anholt: I'd like to print the amount of memory allocated that's associated with a particular label to debugfs, but haven't been able to figure out how to store that info ( I'd use a string/size_t key/value map in userspace, but I can't find anything that allows me to do something similar in kernel space )
15:15FLHerne: ajax: Re. https://gitlab.freedesktop.org/mesa/mesa/issues/2479 , someone from Talos offered to provide a PPC instance for the CI on the Phoronix forum https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1140739-mesa-19-2-6-released-due-to-power-fallout?p=1141086#post1141086
15:15gitbot: Mesa issue 2479 in mesa "Enable piglit for big-endian llvmpipe" [Ci, Opened]
15:16FLHerne: So maybe send them a PM or something
15:42ajax: FLHerne: power9 is little-endian
15:42FLHerne: I thought it supports both?
15:43ajax: maybe in silicon
15:44MrCooper: kisak: skipping CI breaks Marge Bot, but a docs-only MR shouldn't run any build/test CI jobs
15:44ajax: i'm not aware of any vendor supporting it in BE mode. IBM certainly doesn't.
15:45kisak: MrCooper: what do you mean it breaks Marge Bot, iirc, there's a single summary pass test for docs changes, but I don't remember the criteria for telling gitlab it's a docs change
15:45FLHerne: ajax: https://www.talospace.com/2018/08/ad-linux-ported-to-talos-ii-big-endian.html
15:46FLHerne:looks for something more official
15:47MrCooper: kisak: I mean putting something like "[skip CI]" in a commit log will interact badly with Marge
15:47karolherbst: FLHerne: the bigger issue is that it's totally unsupported by Nvidia afaik , or at least there are only LE drivers available to the public ;)
15:47FLHerne: karolherbst: Ok, but for llvmpipe testing that doesn't seem relevant?
15:48karolherbst: the question is rather: who cares about BE at all?
15:48kisak: MrCooper: okay, I was thinking of https://gitlab.freedesktop.org/dbaker/mesa/-/jobs/1690831 and didn't suggest [skip CI]
15:48karolherbst: sure we can test it, I am just questioning the benefit
15:48ajax: karolherbst: s390x
15:48ajax: and m68k!
15:48ajax: but mostly s390x
15:49MrCooper: kisak: it's based on the paths changed by the MR, there's no separate marking mechanism
15:49karolherbst: well.. I still doubt many would want to run a sw OpenGL impl on s390x, alone running a desktop on it?
15:49karolherbst: desktop on s390x seems... odd?
15:49kisak: okay, thanks for the factoid
15:50MrCooper: karolherbst: tell that to the people who just fixed gnome-shell on s390x ;)
15:50karolherbst: I am just wondering.. is there actually s390x hardware out there where it makes sense to run a normal desktop on those?
15:51ajax: do people do VDI-like full desktop remoting from s390x hosts, no not so much
15:51karolherbst:should probably follow all the stuff a bit more
15:51ajax: do people run enough vnc to run the swing app to configure their java whosiwhatsit, yes
15:52karolherbst: and java remote stuff is even a thing
15:53karolherbst: but sure...
15:53ajax: and then, does that vnc insist on being attached to a desktop that's drawn with gl
15:54ajax: so in that sense the ci coverage we have for big endian is entirely fine, now
15:55ajax: except for the part where it's full of xfails
15:55FLHerne: ajax: Similarly, https://wiki.raptorcs.com/wiki/Operating_System_Compatibility_List lists a number of distros with both ppc64 and ppc64le support
15:57ajax: but it's one ~6 minute job to cross-build llvmpipe and run ninja test on it, which thanks to qemu runs just fine, and that covers the llvmpipe unit tests and the gallium format stuff
15:58karolherbst: I guess running GL tests would take way too much time
15:58ajax: put it this way
15:58karolherbst: maybe we could cheat and run only 1/1000th of all the tests each run...
15:59ajax: what rendering bug do you think would be exposed by actual gl, but not the above unit tests, that would be sensitive to endianness
15:59ajax: like... maybe you wrote an app that didn't bswap an image before uploading it to a texture?
15:59ajax: but that's your app's bug
16:00ajax: qemu emulates s390x about 10x slower than native, for me, so yeah probably too slow
16:00karolherbst: yeah dunno. in regards to endianess I kind of expect bugs to be everwhere... but maybe it's indeed fine for most stuff
16:01karolherbst: ajax: well.. I am sure 10 x86 machines are cheaper than one s390x... so maybe we can just throw more money on the problem :p
16:03MrCooper: ajax: .gitlab-ci/cross-xfail-s390x has 4 entries
16:04MrCooper: 2 of which are shared with .gitlab-ci/cross-xfail-ppc64el
16:05MrCooper: (not necessarily for the same bugs though)
16:12ajax: MrCooper: yeah, but saying you fail lp_test_format is a bit like saying you fail rendercheck
16:12ajax: may want to narrow it down, a bit. probably there are lots of failures. (and there are!)
16:18MrCooper: s390x fails PIPE_FORMAT_B5G5R5A1_UNORM, PIPE_FORMAT_B4G4R4A4_UNORM, PIPE_FORMAT_B5G6R5_UNORM, PIPE_FORMAT_R10G10B10A2_UNORM, PIPE_FORMAT_R32*_FLOAT (both float and unorm8 variants) and PIPE_FORMAT_R32(G32)_USCALED (float only)
16:18MrCooper: most of those could be straightforward byte swaps
16:20MrCooper: (of course, the test itself might have endianness bugs as well)
19:09airlied: karolherbst, ajax : there may be people running vdi from s390x
19:11airlied: mainly around developers using windows to develop s390x linux apps
19:15karolherbst: I can think of more pleasent ways of developing on remote targets without using virtualized desktops
19:16airlied: you can doesnt mean you have permission to
19:16imirkin_: to think? :)
19:16airlied: to role your thinking out organisation wide ;-p
19:16karolherbst: airlied: right... because ssh is a bigger security risk than VDI
19:17imirkin_: hackers use ssh!
19:17airlied: karolherbst: vnc over ssh
19:17karolherbst: please don't
19:18karolherbst: I mean, they are not developing GUI applications, right?
19:18airlied: karolherbst: they can be, but usually not
19:18airlied: its just the only eay their companies allow
19:19airlied: also people with aarch64 machines under their desk running vnc sessions for app development are out there
19:20karolherbst: aarch64 I can understand
19:20karolherbst: s390x, I can't
19:20karolherbst: it just doesn't make any sense
19:20airlied: nobody outside ibm understands how ppl use s390x
19:21airlied: but if you have an s390x you are likely to also have strange company IT security policies
19:22karolherbst: yes... and those companies are super high on the "companies with data leaks in the near future"-list
19:22airlied: ive heard scare stories about ppl doing things like EDA over vnc
19:22airlied: and i really hope they are lies
19:22karolherbst: I am sure by telling them, they won't get OpenGL on s390x, it will makes things only safer in the absolute worst case, in the best case, they even change things
19:23karolherbst: airlied: I am sure those aren't lies :p
19:23airlied: hey opengl on s390x may pay some of our wages :-p
19:24karolherbst: it's still wrong
19:24airlied: sw opengl is likely wrong everywhere
19:25airlied: except maybe CI
19:26airlied: ive been using VDI lately to access a windows box to teamviewer to another windows laptop to ssh to a machine
19:27karolherbst: I mean, they don't do that for security, right? Otherwise they wouldn't use teamviewer
19:31airlied: karolherbst: it's claimed to be for security :-)
19:41mattst88: airlied: that is... horrifying. is that to access an s390 machine as well? :)
19:42airlied: mattst88: in this case no, that would put me over the edge :-P
19:45Kayden: the things we do to help the users :)
19:45Kayden: well, mostly Dave does
19:47Kayden: by the way...neglecetd to mention this earlier. I'm going on vacation tomorrow for the next 2 months. Should be back April 19th or so.
19:47karolherbst: Kayden: have fun
19:47airlied: Kayden: nice! hope you don't bring a laptop!
19:47karolherbst: airlied: well, a laptop is a good place to review your photos your took on your vacation ;)
19:48karolherbst: or you have enough SD cards for 2 months
19:49Kayden: thanks :D
20:13krh: Kayden: woo, two months! enjoy
20:27Kayden: krh: thanks! :)
22:39cheakoirccloud: Hello, I've been working on a few Vulkan applications and from time to time I encounter software patterns that produce undefined behaviour(lockups). During development I think it would be important to have a SaftyNet layer that would validate that the calls won't ever produce a lockup. These cases(what needs detection and saving from) is likely driver specific.
22:39cheakoirccloud: These include, Not ending a command buffer. Not binding a vertex buffer, and not supplying vertex attribute descriptions.
22:39cheakoirccloud: Validation layers are not up to this task, they don't intervene in the rendering and in these cases the output is not accessible.
22:41jekstrand: Is there anything kicking around in piglit or similar which benchmarks atomic operations?
22:41jekstrand: shader atomics, that is. I don't care if it's SSBO or ABO
22:47imirkin_: jekstrand: i don't think so, but the image tests are built on a framework that should make that feasible
22:48jekstrand: imirkin_: Yeah, I'm just going to write a tiny crucible test