<alyssa>
I guess turnip is using kernel style SPDX now
<alyssa>
(or always?)
<karolherbst>
good
<karolherbst>
:pain:
heat_ has joined #dri-devel
<karolherbst>
"Note that the required accuracy for the OpenCL C fmod and remainder built-in functions is 0 ULP so if we do define the accuracy of the SPIR-V OpFMod and OpFRem based on the OpenCL C fmod then they will need to be very accurate as well." why...
heat has quit [Read error: Connection reset by peer]
<karolherbst>
please don't do this to me
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
I do see that there's no standard way to use SPDX comments in Mesa
<alyssa>
special shout out to bin/gen_calendar_entries.py for using both the SPDX identifier AND the full text
<alyssa>
(-:
<karolherbst>
cursed
<Quipyowert>
How do I compile Mesa? its giving me "../include/vulkan/vulkan.h:41:10: fatal error: wayland-client.h: No such file or directory" but the file definitely exists in "/usr/include/wayland" (I checked with `rpm -ql wayland-devel | grep -i client`). I'm not familiar with Meson (more familiar with CMake) so I don't know how to add an include directory.
<alyssa>
^ would appreciate an ack on the new files with SPDX headers
<alyssa>
I think I did it right (copying turnip) but..
<alyssa>
anholt: do you trust dEQP? do you really trust dEQP?
<airlied>
Quipyowert: check if it found wayland when meson configured it
<airlied>
if you are on fedora just do sudo dnf builddep mesa
<Quipyowert>
meson said "Run-time dependency wayland-client found: YES 1.19.0" and I installed the dependencies with `sudo zypper source-install --build-deps-only Mesa`
<Quipyowert>
the reason I'm asking is AddressSanitizer thinks there is a stack buffer overflow in swrast_dri.so and I wanted to compile Mesa to get a better backtrace because `bt full` has a lot of <optimized out> in it. I think it might be memcpying too much memory into a buffer.
<Quipyowert>
opensuse btw
inverted has joined #dri-devel
<mhenning>
hmm. here on arch I have /usr/include/wayland-client.h, not /usr/include/wayland/wayland-client.h
<mhenning>
maybe take a look at what flags opensuse builds with?
elongbug has quit [Remote host closed the connection]
<alyssa>
mhenning: oh hi
<alyssa>
i just wanted to say i really liked your stop doing zink infographic
<alyssa>
it convinced me to give up on vulkan and focus on gallium for a living (-:
<karolherbst>
what did I miss?
* karolherbst
planned on doing zink
<mhenning>
alyssa: thanks :P I'm glad people have found it informative
<tzimmermann>
oh, that ended up in my junk folder. :/ a-b: me. i'll merge it together with the other fb fixes
<javierm>
tzimmermann: ah, I see that danvet already acked. I'll review your other series now that my meeting ended
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<danvet>
tzimmermann, thx
ahajda has joined #dri-devel
apinheiro has quit [Quit: Leaving]
xroumegue has joined #dri-devel
JohnnyonFlame has joined #dri-devel
bgs has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
itoral has quit []
rgallaispou has quit [Read error: Connection reset by peer]
* karolherbst
wonders if we are able to file for panfrost CL conformance before December or not
<tjaalton>
tarceri: hi, there's a typo in mesa 675bcbb7a1c0111dc, comma missing after "GetObjectLabelEXT" in the list of functions. this means that the next function is dropped, which is how I found this
<alyssa>
karolherbst: no
<alyssa>
unless you want to put in a lot of work
<alyssa>
which I'd be good with C:
<karolherbst>
I've heard that somebody wanted to send me hardware or something, maybe I remember incorrectly :P
alyssa has left #dri-devel [#dri-devel]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
kts has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, your review comments are only typos. can i fix them when i merge the patches?
fxkamd has quit []
<javierm>
tzimmermann: sure, the code itself looked good to me
<tzimmermann>
great, thanks
<javierm>
tzimmermann: yw
fab has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
<danvet>
tzimmermann, just stumbled over drmm_mutex_init and it's neat :-)
<tzimmermann>
ok, thanks :)
<danvet>
it's a bit a bummer that C can't fold error paths like rust does, but can't have it all
<tzimmermann>
there should probably be a linux-wide implementation of the drmm_ functionality. i was asked about such functionality for sound drivers already
<danvet>
yeah, I tried to lift the devm one into someone you can just attach
<danvet>
the issue is that if you make it too generic then it becomes really ugly
<danvet>
and a distinction between devm and drmm is a Good Thing since you really don't want to mix up the sw/hw cleanup domains for almost all drivers
<danvet>
like one idea I had was to lift this to struct kdev or whatever it is that's shared among everything in the driver model
<danvet>
but then the casting becomes so terrible it's really ugly
<danvet>
so that's why I ended up reimplementing parts of devm for drmm
<danvet>
maybe gregkh has grown a good idea meanwhile, dunno
<dj-death>
jekstrand: chasing some CTS failures where we're failing when doing a CmdCopyImageToBuffer() right after a RenderPass that resolves an MSAA image
<dj-death>
jekstrand: and I'm failing to see where VK_SUBPASS_EXTERNAL is dealt with in the common code
agd5f_ has joined #dri-devel
Duke`` has joined #dri-devel
ybogdano has joined #dri-devel
<jekstrand>
dj-death: hrm...
<jekstrand>
dj-death: Maybe I didn't?
<dj-death>
we're kind of missing the TRANSFER_READ_BIT access from the renderpass that would trigger the right flush for us
<jekstrand>
I'm kinda surprised we haven't noticed this.
<dj-death>
so the CmdCopy is unsynchronized with the resolve operation
<jekstrand>
Yeah, I don't see us handling them anywhere. :-/
<dj-death>
I'll probably fix it
<jekstrand>
Hrm... Actually, we handle source SUBPASS_EXTERNAL just fine. Just not the final one
<jekstrand>
Something like that should add handling for external deps. What that doesn't add is the implicit external deps which happen if you don't specify any.
<jekstrand>
IDK if we add those today or not
<jekstrand>
I'm not seeing code for it
mbrost has joined #dri-devel
<jekstrand>
Looks like no. Annoyingly, that's all per-view so we'd need to do something clever if we wanted to be optimal.
<jekstrand>
Hrm... Given that we do a big fat barrier and not individual image barriers, maybe we can do something simple?
<jekstrand>
I think we can do some sort of a graph walk and look for subpasses with no dep chain that goes back to a SUBPASS_EXTERNAL and adding a dep for those.
<jekstrand>
Annoying but tractable.
<dj-death>
can't we do like what we had in Anv
<dj-death>
which is an additional fake subpass at the end to do the finishing barrier
<dj-death>
or can you transition to external from any subpass?
<jekstrand>
You can. It's annoying, especially with multiview. I've got an idea.
<jekstrand>
Well, it depends on $STUFF
<jekstrand>
We're making a lot of immediate-mode renderer assumptions so we probably can.
<jekstrand>
dj-death: The 2nd patch is a bit scorched-earth but I also kinda don't care. It's Begin/EndRenderPass(). You're gonna stall there anyway. Even on a tiler where you are trying to do subpass reorder/merge, you're going to end up stalling at whole render pass boundaries.
<jekstrand>
I should probably add comments. 😅
<jekstrand>
Ok, comments added.
<jekstrand>
hakzsam: ^^
<hakzsam>
saw it
<hakzsam>
it could explain the regressions
<jekstrand>
Seems plausible.
<jekstrand>
I threw it on the bug so hopefully the reporter can give it a try.
<hakzsam>
yeah, thanks, let's see
<dj-death>
why does it take so much time figuring out why you can't checkout out through ssh
<jekstrand>
:shrug:
<dj-death>
that you eventually give up and check the entire http://.../jekstrand ;)
<dj-death>
jekstrand: yeah that's fixing my problem
<jekstrand>
dj-death: May as well. There's lots of good stuff in there! :-P
<dj-death>
indeed!
<jekstrand>
Including some more 🦀🦀🦀🦀 as of Yesterday.
frieder has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
<anholt>
oh my. rusticl is a whole copy of clang plus also another copy of the gallium driver?
<karolherbst>
what do you mean? :D
<anholt>
"couldn't we just build rusticl in the normal debian-testing build path and have fewer artifacts variants" -> bloaty -d symbols build/src/gallium/targets/rusticl/libRusticlOpenCL.so.1.0.0 -> oh no
<karolherbst>
heh...
<karolherbst>
yeah... linking clang and llvm and gallium is "fun"
<anholt>
yeah, and there's clearly some binary size wins to be had if we could strip unused targets (perhaps my x86 build doesn't need clang::targets::AArch64TargetInfo::BuiltinInfo)
<karolherbst>
right....
<karolherbst>
sadly that's not really how it works.. but maybe I've done something wrongly and it can be forced to do dynamic linking only to llvm/clang?
<karolherbst>
dunno
<anholt>
but even just duplicating iris_dri.so probably means cros won't touch it.
lynxeye has quit [Quit: Leaving.]
<karolherbst>
yeah.. but that's how we do static pipeloader stuff
<karolherbst>
it will become massive once we also include radeonsi and all the other drivers
<karolherbst>
but...
<karolherbst>
removing clover also means nuking the dynamic stuff at least
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
DemiMarieObenour[m] is now known as DemiMarie
<danvet>
mairacanal, v2 lgtm
Akari has quit [Ping timeout: 480 seconds]
<MrCooper>
anholt karolherbst: AFAICT the x86_build image has libclang-cpp<major>-dev installed, so rusticl should be able to link libclang-cpp dynamically
<karolherbst>
yeah.. should
<mairacanal>
thanks for the review danvet!
mvlad has quit [Remote host closed the connection]
Lucretia has quit []
kov has joined #dri-devel
Lucretia has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
iive has joined #dri-devel
Haaninjo has joined #dri-devel
ngcortes has joined #dri-devel
<DavidHeidelberg[m]>
karolherbst: clang + llvm + gallium; also I heard someone wanted to try that on Alpine :D
<karolherbst>
fun
<karolherbst>
I am sure mesa next will be a way better target though
<karolherbst>
given that I will try my best to land radeonsi and zink support