00:04 imirkin_: 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:04 imirkin_: and there's a "union" operation, which is like a phi, to combine inverted predicates
00:05 imirkin_: e.g. a1 = x if p1; a2 = y if !p1; a = union(a1, a2)
00:05 imirkin_: a lot like a phi
00:05 imirkin_: but for non-edge-variables
01:00 daniels: anholt_: shadeslayer had patches for generic BO naming out on dri-devel
01:02 anholt_: daniels: ooh! nice
02:23 Lightkey: 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:24 kisak: patch it?
02:26 kisak: 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:28 kisak: (if my memory is right for skipping CI for docs)
02:41 Lightkey: And take away the chance to show it around? Never.
03:55 airlied: yay heaven renders
03:55 airlied: my tcs fetch was broken for elts
03:58 imirkin: and no piglit/deqp failed?
03:58 imirkin: that's frightening
04:00 airlied: imirkin: yep none failed!
04:01 airlied: no piglits doing draw elements :-P
04:26 Kayden: :(
04:26 Kayden: awesome work though! :)
04:41 airlied: ah shader_runner doesn't support elements drawing
04:41 imirkin: coz why would arrays and elements be different, duh!
05:45 airlied: bleh draw defeats my attempts at making a simple test
06:34 airlied: 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:34 airlied: running fedora 5.4.7 kernel
06:40 airlied: okay llvmpipe tess rebased and ready for review/landing :-P
08:52 pq: ajax, anholt, Kayden, see pointers from https://gitlab.freedesktop.org/mesa/drm/merge_requests/15
08:52 gitbot: Mesa issue (Merge request) 15 in drm "WIP: RFC: Expose the DRM_IOCTL_HANDLE_SET/GET_LABEL with a userspace API" [Opened]
10:05 ickle: airlied: we can stick a cond_resched() in there, but that's a mighty, mighty long list that must have accrued?
10:13 maelcum: i'm getting compile errors in sfn here... pretty standard build configuration on linux. http://ix.io/2ci1
10:13 maelcum: ‘dynamic_cast’ not permitted with ‘-fno-rtti’
10:15 airlied: ickle: seems to back up under swap
10:15 HdkR: maelcum: Time to enable rtti :)
10:16 ickle: a new buffer per swap, no reuse? that'll be nice on !llc
10:16 ickle: even for llc if it touches scanout
10:16 ickle: anyway, cond_resched() it is then
10:19 maelcum: HdkR: for the build system out of the box, not for me!
10:19 maelcum: i have the strange idea that software should build with its own default configuration ;)
10:21 pq: maelcum, makes one wonder how that got through CI.
10:21 HdkR: Looking at meson it looks like if llvm is built without rtti then it can drop that flag in to the build flags
10:22 HdkR: So whatever that system is built on probably has LLVM without rtti enabled
10:22 pq: drop? you mean add?
10:22 HdkR: yes, silly phrasing
10:23 maelcum: it drops rtti :>
10:24 pq: Is that an unfixable conflict? Aside from rebuilding LLVM with rtti.
10:25 HdkR: 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:25 HdkR: Since sfn was added in December and needs it
10:26 maelcum: option(LLVM_ENABLE_RTTI "Enable run time type information" OFF)
10:26 maelcum: from llvm/cmake/modules/HandleLLVMOptions.cmake
10:26 maelcum: seems like i didn't break it by setting an exotic flag
10:26 HdkR: Yea, LLVM doesn't build with rtti by default :)
10:28 maelcum: for now i'll just enable the flag in in llvm... *shrug*
10:29 HdkR: Seems like it is still a bug in mesa meson though. Since r600 doesn't require llvm but requires RTTI
10:30 HdkR: It's just LLVM options hecking with it :)
10:31 HdkR: Something worthy of an issue being opened about it
11:48 rellla: hi, what is the magic detecting flakes by mesa's CI? i mean, how are they marked as flakes?
12:33 tomeu: rellla: if you refer to flakes in deqp, the runner has logic for repeating failed runs
12:34 rellla: 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:36 rellla: https://gitlab.freedesktop.org/rellla/mesa/-/jobs/1696404 the most recent MR now doesn't have one though
12:41 tomeu: rellla: yeah, I went through that with panfrost once, may be better to just fix them :)
12:42 tomeu: have you already ran the flakes under valgrind or ubsan?
12:42 rellla: no
12:43 tomeu: you may find something stupid that is faster to fix than to find the perfect list of skips
14:46 shadeslayer: 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:49 shadeslayer: 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:15 FLHerne: 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:15 gitbot: Mesa issue 2479 in mesa "Enable piglit for big-endian llvmpipe" [Ci, Opened]
15:15 FLHerne: s/Talos/OpenPOWER/
15:16 FLHerne: So maybe send them a PM or something
15:42 ajax: FLHerne: power9 is little-endian
15:42 FLHerne: I thought it supports both?
15:43 ajax: maybe in silicon
15:44 MrCooper: kisak: skipping CI breaks Marge Bot, but a docs-only MR shouldn't run any build/test CI jobs
15:44 ajax: i'm not aware of any vendor supporting it in BE mode. IBM certainly doesn't.
15:45 kisak: 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:45 FLHerne: ajax: https://www.talospace.com/2018/08/ad-linux-ported-to-talos-ii-big-endian.html
15:46 FLHerne:looks for something more official
15:47 MrCooper: kisak: I mean putting something like "[skip CI]" in a commit log will interact badly with Marge
15:47 karolherbst: 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:47 FLHerne: karolherbst: Ok, but for llvmpipe testing that doesn't seem relevant?
15:48 karolherbst: the question is rather: who cares about BE at all?
15:48 kisak: MrCooper: okay, I was thinking of https://gitlab.freedesktop.org/dbaker/mesa/-/jobs/1690831 and didn't suggest [skip CI]
15:48 karolherbst: sure we can test it, I am just questioning the benefit
15:48 ajax: karolherbst: s390x
15:48 karolherbst: uff
15:48 ajax: and m68k!
15:48 ajax: but mostly s390x
15:49 MrCooper: kisak: it's based on the paths changed by the MR, there's no separate marking mechanism
15:49 karolherbst: well.. I still doubt many would want to run a sw OpenGL impl on s390x, alone running a desktop on it?
15:49 karolherbst: desktop on s390x seems... odd?
15:49 kisak: okay, thanks for the factoid
15:50 MrCooper: karolherbst: tell that to the people who just fixed gnome-shell on s390x ;)
15:50 karolherbst: :D
15:50 karolherbst: I am just wondering.. is there actually s390x hardware out there where it makes sense to run a normal desktop on those?
15:51 ajax: do people do VDI-like full desktop remoting from s390x hosts, no not so much
15:51 karolherbst:should probably follow all the stuff a bit more
15:51 ajax: do people run enough vnc to run the swing app to configure their java whosiwhatsit, yes
15:51 karolherbst: ehhhh
15:52 karolherbst: and java remote stuff is even a thing
15:53 karolherbst: but sure...
15:53 ajax: and then, does that vnc insist on being attached to a desktop that's drawn with gl
15:54 ajax: so in that sense the ci coverage we have for big endian is entirely fine, now
15:55 ajax: except for the part where it's full of xfails
15:55 FLHerne: ajax: Similarly, https://wiki.raptorcs.com/wiki/Operating_System_Compatibility_List lists a number of distros with both ppc64 and ppc64le support
15:57 ajax: 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:57 karolherbst: mhhh
15:58 karolherbst: I guess running GL tests would take way too much time
15:58 ajax: put it this way
15:58 karolherbst: maybe we could cheat and run only 1/1000th of all the tests each run...
15:59 ajax: 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:59 ajax: like... maybe you wrote an app that didn't bswap an image before uploading it to a texture?
15:59 ajax: but that's your app's bug
16:00 ajax: qemu emulates s390x about 10x slower than native, for me, so yeah probably too slow
16:00 karolherbst: yeah dunno. in regards to endianess I kind of expect bugs to be everwhere... but maybe it's indeed fine for most stuff
16:00 karolherbst: dunno
16:01 karolherbst: 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:03 MrCooper: ajax: .gitlab-ci/cross-xfail-s390x has 4 entries
16:04 MrCooper: 2 of which are shared with .gitlab-ci/cross-xfail-ppc64el
16:05 MrCooper: (not necessarily for the same bugs though)
16:12 ajax: MrCooper: yeah, but saying you fail lp_test_format is a bit like saying you fail rendercheck
16:12 ajax: may want to narrow it down, a bit. probably there are lots of failures. (and there are!)
16:18 MrCooper: 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:18 MrCooper: most of those could be straightforward byte swaps
16:20 MrCooper: (of course, the test itself might have endianness bugs as well)
19:09 airlied: karolherbst, ajax : there may be people running vdi from s390x
19:11 airlied: mainly around developers using windows to develop s390x linux apps
19:15 karolherbst: I can think of more pleasent ways of developing on remote targets without using virtualized desktops
19:16 airlied: you can doesnt mean you have permission to
19:16 imirkin_: to think? :)
19:16 airlied: to role your thinking out organisation wide ;-p
19:16 karolherbst: airlied: right... because ssh is a bigger security risk than VDI
19:17 imirkin_: hackers use ssh!
19:17 airlied: karolherbst: vnc over ssh
19:17 karolherbst: crap
19:17 karolherbst: please don't
19:18 karolherbst: I mean, they are not developing GUI applications, right?
19:18 airlied: karolherbst: they can be, but usually not
19:18 airlied: its just the only eay their companies allow
19:18 karolherbst: :/
19:19 airlied: also people with aarch64 machines under their desk running vnc sessions for app development are out there
19:20 karolherbst: aarch64 I can understand
19:20 karolherbst: s390x, I can't
19:20 karolherbst: it just doesn't make any sense
19:20 airlied: nobody outside ibm understands how ppl use s390x
19:21 airlied: but if you have an s390x you are likely to also have strange company IT security policies
19:22 karolherbst: yes... and those companies are super high on the "companies with data leaks in the near future"-list
19:22 airlied: ive heard scare stories about ppl doing things like EDA over vnc
19:22 airlied: and i really hope they are lies
19:22 karolherbst: 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:23 karolherbst: airlied: I am sure those aren't lies :p
19:23 airlied: hey opengl on s390x may pay some of our wages :-p
19:24 karolherbst: it's still wrong
19:24 airlied: sw opengl is likely wrong everywhere
19:25 airlied: except maybe CI
19:26 airlied: ive been using VDI lately to access a windows box to teamviewer to another windows laptop to ssh to a machine
19:26 karolherbst: ahhhhh
19:27 karolherbst: I mean, they don't do that for security, right? Otherwise they wouldn't use teamviewer
19:31 airlied: karolherbst: it's claimed to be for security :-)
19:32 karolherbst: right....
19:41 mattst88: airlied: that is... horrifying. is that to access an s390 machine as well? :)
19:42 airlied: mattst88: in this case no, that would put me over the edge :-P
19:45 Kayden: the things we do to help the users :)
19:45 Kayden: well, mostly Dave does
19:47 Kayden: 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:47 karolherbst: Kayden: have fun
19:47 airlied: Kayden: nice! hope you don't bring a laptop!
19:47 karolherbst: airlied: well, a laptop is a good place to review your photos your took on your vacation ;)
19:48 karolherbst: :p
19:48 karolherbst: or you have enough SD cards for 2 months
19:49 Kayden: thanks :D
20:13 krh: Kayden: woo, two months! enjoy
20:27 Kayden: krh: thanks! :)
22:39 cheakoirccloud: 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:39 cheakoirccloud: These include, Not ending a command buffer. Not binding a vertex buffer, and not supplying vertex attribute descriptions.
22:39 cheakoirccloud: 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:41 jekstrand: Is there anything kicking around in piglit or similar which benchmarks atomic operations?
22:41 jekstrand: shader atomics, that is. I don't care if it's SSBO or ABO
22:47 imirkin_: jekstrand: i don't think so, but the image tests are built on a framework that should make that feasible
22:48 jekstrand: imirkin_: Yeah, I'm just going to write a tiny crucible test