03:02airlied: dcbaker[m]: just pushed an llvmpipe fix it would be great to have in 20.2 final
03:03dcbaker[m]: airlied: cool. I need to get pulls done today still. I'm running a day behind because Monday was a holiday here
04:29jvesely: daniels: are there llvm-spirv tools that work with llvm <10?
04:32airlied: jvesely: do you mean packaged ones?
04:32airlied: jvesely: the github repo has branches going back a few llvm vers
04:33jvesely: ideally packaged for ubuntu bionic :), but in general I'm tying to figure out if the support for libclc spirv target needs to be limited to LLVM 10+
04:33airlied: jvesely: the project has bracnhes all the way back to 70
04:34airlied: but I'm not sure if the older version would have bugs we'd care about
04:37jvesely: hm, libclc supports llvm all the way back to 3.9 so even 7.0 needs to be handled in a conditional
04:38airlied: well you just won't find the sllvm-spirv tools I assume and fail to configure
04:39airlied: and not get the spirv support for clover
04:40airlied: I though libclc being part of the llvm tree wouldn't really care itself about being built against older llvms
04:42airlied: jvesely: do you mean to check in libclc repo or mesa?
04:43jvesely: libclc build/configure (cmake)
04:45jvesely: the plan was to keep backwards compatibility until libclc reaches clc1.1 (or 1.2) compliance and then switch to being part of llvm (and integrate the build process)
04:46jvesely: at that time I thought I'd have enough time to finish 1.1 in few weeks
04:46jenatali: jvesely: The SPIR-V target adds in enough for it to be clc1.2 on top of Mesa :)
04:47jvesely: anyway, libclc git can be built using llvm-3.9 and I've CI jobs to test that
04:48jvesely: so I'm trying to fix those
04:48jvesely: jenatali: does to correctly handle the full suite of 'convert_*' routines?
04:48jenatali: jvesely: Ah... yeah we're not currently getting those from libclc
04:48jvesely: which is good, 'cause those in libclc are broken :)
04:48jenatali: Yeah, we realized
04:50jvesely: anyway to rounding routines are mostly in place for float->half (used in vstore_half), so it's not much work to fix the rest
04:52jvesely: airlied: is anyone working on adding opencl to virgil?
04:57jvesely: jenatali: I'll push D85911 as soon as at least llvm<7 libclc CI runs pass
04:57airlied: jvesely: nope not as of yet
04:58jenatali: jvesely: Sounds good, thanks
04:59airlied: jvesely: not sure the nicest way to find correct llvm-spirv tool
04:59airlied: since it takes llvm IR it needs to be same as clang libclc calls
05:00airlied: jvesely: for vircl you need a host impl that works first :-p
05:03jvesely: you could use one of the CPU implementations. as a proof of concept, not that it would make much sense for any practical use
05:05airlied: we will have our own cpu impl soon :-p
05:52mlankhorst: airlied: forgot to actually send the pull req yesterday, belated enjoy!
05:53macc24: when i'm compiling mesa from source, can i disable softpipe from compilation?
05:54HdkR: Sure, just leave llvmpipe and swrast out of the dri-drivers and gallium-drivers options
05:56macc24: is kmsro needed?
05:57HdkR: Pretty sure that is mandatory for ARM devices unless you want to run headless
06:27tomeu: alimon: hi, did you find what you were looking for?
06:30mszyprow:is still looking for someone to help merging "[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse" patchset via drm-misc
07:06danvet: linusw, [PATCH v2 3/6] drm: Add SPI DBI host driver <- somehow the mailing list got lost from this thread, dunno why
08:08linusw: danvet: that explains a bit of my confusion :/
08:42danvet: sravn, looked at drm/kmb
08:42danvet: not perfect, but imo pretty enough that we can start with commit rights setup and merging
08:42danvet: and polishing in-tree
08:43danvet: assuming Anitha is up for that approach
09:12karolherbst: where should people file bugs against virtio_gpu
09:27airlied: karolherbst: not sure, maybe against drm/misc
09:30karolherbst: yeah.. but drm/misc sees like 3 issues a month :/
09:30karolherbst: and people might just not notice
09:30karolherbst: but I also couldn't find any official doc to tell users where to file bugs...
09:35MrCooper: can always tag relevant people in the issue so they see it
09:55danvet: sravn, sounds like bindings aren't even close to ready yet per narmstrong, so more rounds I guess
14:34emersion: danvet: just fyi https://gitlab.freedesktop.org/drm/amd/-/issues/1290#note_622690
15:06MrCooper: panfrost-t860-traces:arm64 job timed out twice: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4494274
15:09swick: when one sets the Colorspace property to "Default" what exactly does that mean? The comment says "For Default case, driver will set the colorspace" but the code would always select HDMI_COLORIMETRY_NONE which sounds a lot like "native color space"
15:11swick: so is this really an arbitrary driver specific color space or the display native color space?
15:40tomeu: MrCooper: have put that board offline, thanks for telling
15:52MrCooper: tomeu: thanks, seems to be chugging along now
16:01sravn: danvet: Thanks, bindings first. So Anitha can use the time to set up commit rights while polishing the bindings. I do not recall having reviewed the bindings, must have missed them somewhere
16:01danvet: they're not included
16:02danvet: probably should be
16:25Venemo: which version of c++ can we use in mesa currently? is it c++14 or 17?
16:25linkmauve: Venemo, meson.build says C++14.
16:25Venemo: ah, ok, thanks linkmauve
16:26linkmauve: It got bumped one year ago.
16:26linkmauve: See 1abe87383e1529a14498d70a0cf445728b9c338d.
16:28alimon: tomeu: hi, do you have an example of lava-deqp testjobs (expanded variables) for freedreno devices for take a look?
18:04ajax: re LTO: is the theory atm that most of the bugs are due to strict-aliasing abuse, or do we know of something more sinister?
18:06airlied: ajax: my goto is blaming the compiler first
18:06dcbaker[m]: Venemo: our c++ minimum is basically driven by whatever llvm uses
18:06airlied: so far I'm not sure I've been proven wrong
18:06airlied: other than simple ODR fixes
18:07ajax: airlied: enh. i've only encountered bugs that you could legitimately trip if your source was all-one-file-'d.
18:07ajax: have we actually seen like piglit failures from lto stuff, or do you need something heavyweight like a steam game usually?
18:08bnieuwenhuizen: ajax: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3239 (https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=66780083a0e79e5cb7c3acc8665aa47be4084a67)
18:08bnieuwenhuizen: was an LTO compler bug
18:08Venemo: dcbaker[m]: is there any plan to upgrade to 17?
18:09Venemo: just out of curiosity
18:09airlied: ajax: so far mostly games
18:09airlied: ajax: che has been building his copr with lto for a year or two now
18:09airlied: and it's nearly always been compiler bugs
18:10dcbaker[m]: Venemo: no one's proposed it afaik
18:17airlied: ajax: maybe we can get gcc CI to run steam games :-P
19:31mareko: airlied: is lowered IO planned for gallium/draw?
19:34airlied: mareko: there are no plans for anything in draw
19:35mareko: who here maintains panfrost?
19:35airlied: alyssa usually seems absent from irc
19:36airlied: mareko: would lowered io be useful?
19:37HdkR: Tagging an issue or MR on gitlab to panfrost will usually get someone's attentino
19:40airlied: my current plans for draw end at vk1.0 and maybe gles 3.2
19:41mareko: airlied: rasterpos is broken on radeonsi because draw can't handle the IO intrinsics
19:41bnieuwenhuizen: mareko: airlied: for panfrost try the #panfrost channel
20:17pinchartl: Lyude: your X.org board meeting report mentions that you've received replies from all but 3 people regarding the schedule change. was a reply expected ?
20:17Lyude: pinchartl: just an ok
20:17Lyude: it's appreciated at least, we just wanted to make sure the new schedule didn't cause anyone issues
20:18pinchartl: it may be good to mention that a reply is desired next time :-)
21:20DPA: I wanted to compare a simple test program I wrote between my laptop and my devkit. Got inconsistent results on my laptop (with nouveau).
21:20DPA: Checked with valgrind and found this: https://gitlab.freedesktop.org/-/snippets/1174
21:20DPA: And I saw something similar on radeon as well. This certainly doesn't make debugging any easier.
21:25DPA: It may seam harmless, but I've had such things always cause inexplicable problems way too often already.
21:29HdkR: It's always good to be asan clean
22:06mdnavare: hwentlan: quick question on VRR: We are working on adding VRR support in the gnome-mutter compositor which is common on all drivers and wanted to test the same with AMD Graphics card, the VRR code that Nicholas has written , is that tested with the AMD VEGA series or RX card?
22:09mdnavare: hwentlan: Or also is there a way we could use your help to test this out with AMD Graphics?