Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
Danct12 has quit []
heat has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
eukara has quit []
eukara has joined #dri-devel
eukara has quit []
fab has joined #dri-devel
JohnnyonF has joined #dri-devel
kts has joined #dri-devel
pallavim has quit [Remote host closed the connection]
saurabhg has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
f11f12 has joined #dri-devel
tzimmermann has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest2352
srslypascal has joined #dri-devel
kts_ has quit []
srslypascal is now known as Guest2353
srslypascal has joined #dri-devel
Guest2352 has quit [Ping timeout: 480 seconds]
Guest2353 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Quit: fab]
gio has joined #dri-devel
sdutt__ has quit [Read error: Connection reset by peer]
kts_ has joined #dri-devel
frytaped has joined #dri-devel
kts_ has quit []
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
frytaped has quit [Quit: WeeChat 3.5]
tursulin has joined #dri-devel
danvet has joined #dri-devel
lynxeye has joined #dri-devel
jkrzyszt has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
Vanfanel has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<eric_engestrom>
Venemo, alyssa: the tl;dr is that these cts tests use a local size of 512 which is above the minimum of 128 in the spec which makes it crash on some drivers like ours; itoral posted a cts fix last week, just waiting for it to go through the motions
rasterman has joined #dri-devel
macromorgan is now known as Guest2358
macromorgan has joined #dri-devel
Guest2358 has quit [Ping timeout: 480 seconds]
frytaped has joined #dri-devel
pcercuei has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<Venemo>
eric_engestrom: yes, I saw the Khronos bug about it.
<Venemo>
eric_engestrom: sorry for alarming you, I was just afraid it might be a regression from thar MR. but I re-ran the CI and then it was green so it's all good.
<eric_engestrom>
no worries, it never hurts to ask :)
<Venemo>
the MR touched some stuff around local invocation index usage and that's what triggered me
rgallaispou has left #dri-devel [#dri-devel]
frytaped has quit [Remote host closed the connection]
frytaped has joined #dri-devel
rgallaispou has joined #dri-devel
bmodem has joined #dri-devel
nchery has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
Vanfanel has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
kts has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
ella-0_ has joined #dri-devel
kem has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
tobiasjakobi has joined #dri-devel
bmodem has joined #dri-devel
tobiasjakobi has quit []
rgallaispou has joined #dri-devel
fahien has quit [Quit: fahien]
<knr>
mripard: can you comment on 20220905131125.bbqxihhipc37oshq@nostramo? And explain the "kunit filtering" angle you had in mind?
<knr>
(I'm asking since you acked the rename - and that's fine with me, but I'd just like to understand the usecase for wanting to filter by test case)
f11f12 has quit [Quit: Leaving]
rgallaispou has quit []
kts has joined #dri-devel
kalidows_ has joined #dri-devel
jewins has joined #dri-devel
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
kalidows_ has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
warpme___ has quit []
dakr has joined #dri-devel
Ryback_ has joined #dri-devel
Ryback_ has quit []
kts has joined #dri-devel
Ryback_ has joined #dri-devel
fahien has quit [Quit: fahien]
bmodem has quit []
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
Haaninjo has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
saurabhg has joined #dri-devel
Duke`` has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
oneforall2 has quit [Read error: Connection reset by peer]
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
oneforall2 has joined #dri-devel
warpme___ has joined #dri-devel
fahien has joined #dri-devel
fahien has quit []
fab has quit [Quit: fab]
kts has joined #dri-devel
<pepp>
anholt: re !18484, how can we end up using _mesa_texstore_s8_z24? (= I don't understand where MESA_FORMAT_Z24_UNORM_S8_UINT is used)?
<anholt>
I'd look for callers of _mesa_texstore, I guess.
<pepp>
hmm.. anyway, I think keepdepth is also useless since "srcFormat == GL_STENCIL_INDEX" shouldn't be possible
sdutt has quit []
sdutt has joined #dri-devel
fab has joined #dri-devel
gouchi has joined #dri-devel
<kisak>
pepp: !18484 caught my eye as well. It would be nice to know if the second commit is enough of an improvement versus the risk of regression for it to be queued for early backport to 22.2 in my PPA
<kisak>
it's not clear from the discussion if CS:GO needs both commits to get the majority of the init time improvement.
iive has joined #dri-devel
<kisak>
looks like yes from a re-read of the commit messages
ybogdano has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
YuGiOhJCJ has quit [Remote host closed the connection]
fab has quit [Quit: fab]
srslypascal is now known as Guest2399
srslypascal has joined #dri-devel
Guest2399 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
Vanfanel has joined #dri-devel
kalidows_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
Vanfanel has quit [Read error: Connection reset by peer]
digetx has joined #dri-devel
eukara has joined #dri-devel
kalidows_ has quit [Ping timeout: 480 seconds]
orbea has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
zehortigoza has joined #dri-devel
kalidows_ has joined #dri-devel
kalidows_ has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Battersea has joined #dri-devel
gio has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
h0tc0d3 has quit [Quit: Leaving]
ybogdano has joined #dri-devel
<karolherbst>
oh no.. last minute comment on the rusticl MR :(
<emersion>
your reply is not a very good reply
<karolherbst>
it's on point
<emersion>
…
<karolherbst>
nobody wants to work on clover
<karolherbst>
nor does anybody want to improve it
<karolherbst>
it's a dead project
<karolherbst>
I've talked with people, there were multiple opportunities to improve CL in mesa, but the reason it didn't happen were mostly "because clover is annoying to work with"
<karolherbst>
and from experience with it, I agree
gouchi has quit [Remote host closed the connection]
<emersion>
and so the solution is to RiiR
<karolherbst>
if clover is so good and everything, why is it still broken
<karolherbst>
sure
<karolherbst>
why not?
<karolherbst>
I looked at clover and my conclusion was to get proper CL support is to start something from scratch
<emersion>
there's no point in discussing this further, no matter what we say it won't change anything
<emersion>
that's why i didn't bother replying on the ML thread
<karolherbst>
I've been working on it for months and it was public knowledge
<karolherbst>
and now that I planed to merge it on the day, _now_ people come out and giove random crap reasons?
<karolherbst>
okay.. cool
rasterman has quit [Quit: Gettin' stinky!]
<emersion>
"oh we really need to move to gitlab to lower the barrier to entry"
<emersion>
… a few years later…
<emersion>
"oh we really need to force everybody to learn a whole new complicated extra language just because we can"
<emersion>
gj
<karolherbst>
I send out emails and mentioned stuff on IRC _multiple_ times
<karolherbst>
if you all miss it, why is that my fault if you obviously don't care
<emersion>
yeah, i was in the discussion
<karolherbst>
none of this is a secret
<karolherbst>
and none of this was worked on in secret
<emersion>
on IRC
<emersion>
but guess what? none of my concerns were addressed
<emersion>
it changed _nothing_
<karolherbst>
what concerns?
<emersion>
read the logs
<karolherbst>
you mean the "I refuse to learn rust" one?
<emersion>
i don't refuse
<emersion>
i tried multiple times
<karolherbst>
okay, you don't want to
<karolherbst>
I get it
<emersion>
and no, that's not the main concern
<karolherbst>
okay, so your point is you hate Rust...
<karolherbst>
anything else I missed?
<emersion>
okay, so your point is to sum up a discussion with garbage
<karolherbst>
sorry, but if people want to move forward, and I am not the only one, with Rust, then we can either get blocked by single persons or we find a compromise
<karolherbst>
but doing the "I hate this language so much I want to stop anything useing it" is not a good starting point
<karolherbst>
emersion: well. I checked the logs and your comments were in this direction all along
<emersion>
okay, i'll refresh you memory then
<emersion>
the main concern is that using rust directly with the core APIs is too much for a first step, adn it would be better to use rust at the edges of a driver at first
<karolherbst>
yeah, which is basically saying "don't bother with rust at all"
<emersion>
… no
<karolherbst>
there is _no_ sane way you could encapsulate it that much
<karolherbst>
you are asking for the impossible there
<karolherbst>
sure, I could move rusticl into another project so mesa doesn't contain any rust code interacting with it in any way, but then we need a stable gallium API
<karolherbst>
sounds like a good plan, no?
<karolherbst>
doesn't matter if e.g. rusticl uses the gallium API one way or the other. If something changes, Rust code has to be changed as well
lemonzest has quit [Quit: WeeChat 3.5]
<karolherbst>
if you know of a sane way of doing that, please go ahead and prototype something
<karolherbst>
also.. if somebody wants to write a DRM driver in rust, I am in full support to that. It's a cool project and I don't want to be "that guy" who says no to cool projects
<karolherbst>
and if somebody needs help figuring out rust code if MRs break it, I am here and available and would fix that stuff (or others for that matter)
<karolherbst>
so no, I don't think your concerns here is in any way constructive
<karolherbst>
anyway.. this was dicsussed on the email thread
<karolherbst>
feel free to chime in
<mattst88>
karolherbst: I think an appropriate reply could just be "The time for expressing concerns like this was many months ago"
<karolherbst>
that's even worse
<karolherbst>
:D
<karolherbst>
but yeah...
<karolherbst>
I was a second before just merging it regardless
<mattst88>
I think there's often an internal struggle when people see a project taking shape that they don't like -- should I spend the time now to look at it critically, or should I ignore it and hope it goes away?
<karolherbst>
maybe I am just stupid and don't understand the arguments or don't get them, but at least if somebody has concerns I kind of expect those aren't just "random made up reasons to make it impossible" but some I see that the people really thought about it and tried to find a solution
<danvet>
where is all this fun happening?
<danvet>
I'm not seeing the right threads on the MR I guess
<karolherbst>
if the reasons is "I don't like it and it shut get burned/closed down" I might get a little defensive in a crappy way as you might have noticed...
<danvet>
ah I didn't read that one as all that big of an issue
<danvet>
also I'm personally not a fan of C++
<karolherbst>
me neither
<danvet>
it's a bit much in the uncanny valley for me
<karolherbst>
yeah.. but...
<karolherbst>
the comment is bascially "we should focus on clover and kill rust, because clover is written in C++"
<karolherbst>
*rsuticl
<karolherbst>
or did I miss something more there?
<karolherbst>
also.. curro knew about this project even before the MR was there
<Frogging101>
I think you got it backwards. It sounds like "We should focus on Clover instead of adding Rust because the benefits of adding Rust are unclear compared to its costs"
<Frogging101>
(just interpreting, not judging)
<karolherbst>
yeah, and obviously I stated that focusing on clover is a dead end otherwise I wouldn't have asked for rusticl to get merged
<danvet>
karolherbst, oh I just read this as "as a project we need to acknowledge there's some cost in here, and it might not be worth it"
<danvet>
which yeah is the entire discussion that's been going on for like months by now
<Frogging101>
Why is it a dead end?
<karolherbst>
because I get a headache whenever I have to work on clover
<Frogging101>
That doesn't really sound like a reason why Clover is a dead end
<karolherbst>
well.. why didn't MS used clover to implement CL?
<karolherbst>
they have a d3d12 backend
<karolherbst>
funny, they came to the same conclusion
<Frogging101>
I have no idea why MS does or does not do anything
<karolherbst>
because they didn't want to work on clover
<karolherbst>
because it's a dead end
<karolherbst>
I am not the only one saying we need something new
<Frogging101>
So the two reasons why Clover is a dead end are: 1) You think so, and 2) You think that Microsoft thinks so too
<karolherbst>
no, we discussed this here on IRC
<karolherbst>
they stated so, that it was less work to create something new than to use clover
<Frogging101>
I don't really have a horse in this race, I'm just saying those just aren't really answers
<Frogging101>
Do you think more people will be willing to work on rusticl?
<karolherbst>
I think what annoys me most is that people come up with random technical reasons for social issues. If clover is so great, why did nobody really spend time on improving it?
<karolherbst>
I don't want to, because I don't like working with it
<karolherbst>
if others think clover is so great, they damn sure hid very well until now
jkrzyszt has quit [Ping timeout: 480 seconds]
<karolherbst>
I'd like to imrpove rusticl to get proper CL support
<karolherbst>
and that's more or less the situation
<Frogging101>
ok
<karolherbst>
sure, you can come up with 100 technical reasons why clover is the way to go and it still wouldn't help, because I thought rusticl is a cool project and others thought so too, and I enjoyed working on it
<karolherbst>
and that;s why I think clover is a dead end: nobody works on it and nobody wants to
<Frogging101>
well even if nobody works on rusticl, if it's better than clover then a net gain has been achieved
<karolherbst>
yeah, I pass the official CL 3.0 CTS on iris with rusticl
<karolherbst>
and random applications actually work with it
<agd5f>
I think the biggest problem with OCL is that we need to make sure we don't use the same IOCLs we use for gfx. They don't allow for long running shader kernels. That said, does anyone actually care about OCL these days?
<karolherbst>
agd5f: darktables does.. somewhat
<karolherbst>
but there are a bunch of commercial video editing tools which do
<Frogging101>
uh, yes? opencl is used by many things
<karolherbst>
reasearch might also use it for random things
<karolherbst>
anyway.. there are use cases and there are even some linux applications making use of it
<karolherbst>
but yeah.. the CL API isn't great
<Frogging101>
Folding@Home uses it, Blender uses it, "AI" uses it
<karolherbst>
oh right.. blender as well
<karolherbst>
wait a minute...
* anholt
is looking forward to interacting with rusticl. I have had reasons to touch clover in the past, and would never.
<agd5f>
I though blender dropped the OCL backend
<Frogging101>
What do they use now?
<karolherbst>
blender dropped it
<Frogging101>
vulkan compute?
<karolherbst>
Frogging101: sane compute APIs like CUDA
<agd5f>
in favor of CUDA/HIP/OneAPI
<Frogging101>
does CUDA work on AMD?
<karolherbst>
that's why they also support HIP
<Frogging101>
clearly I'm some years out of date on GPU compute, since I didn't even know what that is
<karolherbst>
anholt: yep... that's what I get a lot
<agd5f>
Frogging101, HIP provides conversion tools, but there is native HIP support as well
<karolherbst>
clover could be the technical best solution and even then I'd be in favour of dropping it if anybody even getting near it only wants to run away as fast as possible
<karolherbst>
Frogging101: part of ROCm
<bnieuwenhuizen>
agd5f: AFAIU CL is also surprisingly big as the compute API on Android even though Google is totally pushing Vulkan compute
<agd5f>
karolherbst, I hope rusticl takes off, but I feel like the world is paved with failed OCL implementations :)
<karolherbst>
agd5f: same
<agd5f>
just never seems to get traction
<karolherbst>
well.. not sure about that really
<karolherbst>
sure, it was always little
<karolherbst>
but somehow people become a little bit more interested I think
<karolherbst>
but yeah.. I think the biggest part is, that mesa never had a really capable CL impl so people usually didn't think of using it
<karolherbst>
one interesting idea would be to let vulkan consume OpenCL SPIR-Vs and see if one could make use of that instead
<karolherbst>
and maybe even glue some CL runtime on top of that (maybe through zink even)
<agd5f>
the winsys should use the ROCm runtime and whatever intel has for level 0 or whatever they call it otherwise long running kernels will be killed due to timeouts if you try and use the same winsys as gfx
<karolherbst>
agd5f: intels CL runtime also times out :)
<bnieuwenhuizen>
agd5f: wrt timeouts, I think in general we don't have timeouts on compute queues even through the gfx interface either?
<karolherbst>
well.. you have to know what you need to do in order to actually cause it to time out
<bnieuwenhuizen>
gfx being amdgpu rather than amdkfd
<karolherbst>
but I think on intel you can only dump the timeout by some factor, but can't eliminate it completely
<karolherbst>
but yeah.. once r600/radeonsi are wired up, I susepct we have to figure this out
<agd5f>
bnieuwenhuizen, no, all kernel queues timeout eventually
<agd5f>
by design
<agd5f>
the rocm queues are preemptable so they can run forever
<bnieuwenhuizen>
I thought in practice the compute queues don't have the inherent timeout and only hit the fence timeout if anybody actually waits on them?
<anholt>
karolherbst: chrome os has camera stuff using CL that matters to us a lot. there's work being done on clvk, but I can definitely imagine rusticl having a role if it takes a while for clvk to hit parity.
<karolherbst>
ahh
<bnieuwenhuizen>
how close is clvk to parity?
<karolherbst>
anholt: is there a simple way to try that on a linux desktop?
<karolherbst>
bnieuwenhuizen: can't reach it
<bnieuwenhuizen>
karolherbst: why not?
<anholt>
bnieuwenhuizen: I think conformance they're hoping for next few months.
<anholt>
karolherbst: it's on my list, to figure out how to get it built and test it on linux desktop, so we can put it in front of our vk drivers in CI
<karolherbst>
bnieuwenhuizen: though .. mhh maybe with newest VK extension it's now possible indeed.. but 64 bit pointers and all the fancy kernel stuff is really annoying to get right
<Frogging101>
camera stuff?
<karolherbst>
filters I suspect
<agd5f>
bnieuwenhuizen, I suppose no ring has an inherent timeout if no one ever queries the fences
<bnieuwenhuizen>
karolherbst: for pointers we have VK_KHR_buffer_device_address
<karolherbst>
yeah...
<karolherbst>
just recompiling the spir-v is brutal
<karolherbst>
though going from CL C that _might_ be possible
<karolherbst>
but CL is unstructured CFG
<karolherbst>
it has gotos :)
<karolherbst>
though I think implementations can reject that
<bnieuwenhuizen>
I thought CL C forbids gotos? (but the SPIR-V can definitely do it)
<karolherbst>
I think implementations are free to support it
<karolherbst>
but doesn't matter as spir-vs can do whatever they want anyway
<karolherbst>
we support that though and we structurize the CFG, but... it's a bit ugly
<karolherbst>
also compiling to a single function by inlining is a big no no
<karolherbst>
I was hitting 30GB RAM use with some CL kernels in mesa
<bnieuwenhuizen>
everyone else just ends up using LLVM and using some LLVM structurizer pass though
<karolherbst>
yeah.. we used to do that
<bnieuwenhuizen>
yeah we need a big push on compiler improvements for the various mesa drivers for CL
<karolherbst>
but the structurizer path doesn't lead to structurized spir-v :)
<karolherbst>
or maybe with recent llvm it does
<karolherbst>
I am sure that clspv can deal with 99% of the applications out there. There are just some very very nasty corner cases in use which will be tricky
<karolherbst>
anyway.. getting official conformance is simple, the CTS is really poor in terms of coverage
<karolherbst>
and once you get to CL 2.x features it becomes really really dfficult
<karolherbst>
like how to implement SVM on top of vulkan?
eukara has quit []
eukara has joined #dri-devel
mhenning has joined #dri-devel
<danvet>
karolherbst, the kernel patches to make CL not time out haven't reached upstream yet
<danvet>
but yeah otherwise what agd5f said, you need different context with different rules to make compute work properly
<karolherbst>
yeah.. anyway, none of this is hard to wire up I suspect
<danvet>
tldr is roughly 1. no dma_fence for sync at all 2. ctx preempt to allow them to run indefinitely
<karolherbst>
might need a new flag on pipe screen creation or something
<danvet>
yeah
<danvet>
and kernel support to wire it all through
<karolherbst>
anyway. nont of this is realted to rusticl though as clover has the same issue
<karolherbst>
*none
<karolherbst>
(and intels CL runtime anyway)
mhenning has quit [Read error: No route to host]
<danvet>
plus I guess for amd bnieuwenhuizen gets to wire it through amdgpu.ko, at least I'm not super sure porting mesa to amdkfd is a very bright idea
mhenning has joined #dri-devel
<danvet>
karolherbst, ah yeah, just noticed that discussion in the scrollback
<karolherbst>
do we really have to use a complete different winsys on AMD?
<danvet>
karolherbst, nah you can just add a flag to context creation or something and wire it all through
<karolherbst>
okay
<danvet>
it's a pile of screaming I guess
<karolherbst>
probably
<danvet>
for intel we just make it a ctx flag
<bnieuwenhuizen>
but my userspace submissions :(
<karolherbst>
:P
<danvet>
and then there's a long list of things you're not allowed to do anymore
<karolherbst>
well we'll get to that
<karolherbst>
but that's really nothing which impacts the frontend much
<danvet>
but also, a bunch of things you're then allowed to do
<danvet>
bnieuwenhuizen, like userspace submission
<danvet>
you really can't do that with gfx ctx
<karolherbst>
worst case mesa uses the graphics winsys for CL unless a driver cares and makes it all cool
<bnieuwenhuizen>
I thought some of the discussion on the AMD side was that it sounded like they could actually do that for gfx ctx on some future HW
<karolherbst>
nvidia does it in vulkan
<bnieuwenhuizen>
but then got into all the what to do with dma_fence mess
<danvet>
bnieuwenhuizen, compute ctx vs gfx ctx is pretty much a linux dma_fence issue
<danvet>
ofc if the hw can't support preempt, you can't really do an indefinite runtime compute ctx
<karolherbst>
CL wouldn't be able to use dma_fence anyway
<danvet>
yup
<karolherbst>
or at least.. it wouldn't help with anything
<danvet>
well people have tried everything :-)
<karolherbst>
sure
<bnieuwenhuizen>
don't you have sync with GL?
<danvet>
bnieuwenhuizen, block on cpu
<bnieuwenhuizen>
since CL can import GL stuff etc.
<karolherbst>
the bad part about CL is, that applications can enqueue "event"s
<danvet>
I mean this is were this all gets very nasty
<karolherbst>
well.. application events
<karolherbst>
and you signal them on the applications side
<danvet>
and were jekstrand starts to curl up and sob or something
<karolherbst>
and GPU events can depend on those
<karolherbst>
it's a huge mess really
<bnieuwenhuizen>
are usermode fence going anywhere or is that still in the sob stage?
<karolherbst>
in rusticl I have a GPU queue running in a thread waiting on all the fences to signal after each "cl command" more or less
<karolherbst>
so that works
<danvet>
yeah essentially our nice "magic implicit sync" facade comes down crashing and burning when you throw cl into the mix
<karolherbst>
but.. uhhh
<danvet>
bnieuwenhuizen, userspace memory fence is compute ctx
<danvet>
the interop is sob
<karolherbst>
I could potentially skip the wait if nobody waits on it, but I didn't get to it yet
<danvet>
since jekstrand wants this all for vk and with winsys
<agd5f>
we should be able to do user mode queues for all engines soon on certain hardware, but for all existing hardware, you'd need to use something like ROCm runtime
<bnieuwenhuizen>
danvet: I want to be able to use ^ on vulkan
<bnieuwenhuizen>
not even about timeouts, but fast submission
<danvet>
bnieuwenhuizen, yeah that's where the sobbing starts
<karolherbst>
ohh that GPU queue I have is probably a good reason why clover needs a huge rework anyway. How clover creates jobs for the GPU is really bad
<karolherbst>
and fencing is broken :(
<danvet>
as soon as you want to wrap that in a dma_fence it's all *boom*
<karolherbst>
probably
<danvet>
at least if you're sufficiently unlucky
<danvet>
and under enough memory pressure
<danvet>
which means any demo you create will work great
<karolherbst>
with CL that's not unlikely
<jekstrand>
danvet: Why am I crying?
<karolherbst>
danvet: heh.. luxmark is also just a "demo" but our compiler uses 30GB of RAM :)
<danvet>
umf vs dma_fence in vk
<jekstrand>
Well, yeah.
<danvet>
jekstrand, or at least you've already threatened me with a good time next week at plumbers :-/
<agd5f>
long running shader kenrels has always been the bane of OCL until we moved to over ROCm
<jekstrand>
danvet: If it's a good time, how can it be a threat? :P
<karolherbst>
agd5f: but I guess what ROCm does can also be done in mesa, no?
<danvet>
jekstrand, good time for spectators only maybe
<danvet>
karolherbst, you need a different winsys
* karolherbst
grabs popcorn
<agd5f>
karolherbst, right, you'd have to use the same underlying user mode queues that we expose through the ROCm runtime
<danvet>
or add the pieces to amdgpu.ko
<bnieuwenhuizen>
karolherbst: it is really about amdkfd (the kernel part) having a different model
<karolherbst>
yeah...
<karolherbst>
well.. the AMD stuff in mesa already abstracts the winsys away
<karolherbst>
could add a third impl :P
<bnieuwenhuizen>
honestly I'm kinda curious how hard an amdkfd winsys for radv would be
<danvet>
karolherbst, well it's more that the entire sync stuff goes out too
<danvet>
not sure you want to abstract that much, I guess you could
<karolherbst>
does radeonsi use any of that for fences?
<bnieuwenhuizen>
danvet: should be pretty pluggable with the vk_sync refactor jekstrand did
<bnieuwenhuizen>
just need to expose a device that can't export/import
<karolherbst>
well.. I also have an AMD card, so maybe I get to it once ACO is wired up in radeonsi :D
<jekstrand>
Yeah, vk is pretty well abstracted for sync
<jekstrand>
But the bigger problem is the kernel not letting you use both and not knowing at device init time which to use.
<agd5f>
Does ACO really buy you much for OCL?
<karolherbst>
yeah, not having to deal with LLVM
<karolherbst>
rusticl is nir only
<karolherbst>
and I don't plan to change that
<agd5f>
so is radeonsi
<bnieuwenhuizen>
tbh current path ir nir->llvm so you still wouldn't have to deal with llvm directly
<bnieuwenhuizen>
unless radeonsi is missing nir stuff for this
<bnieuwenhuizen>
like nobody is proposing the direct LLVM hell that clover chose
<karolherbst>
airlied told me there is this weird LLVM compute ABI
<bnieuwenhuizen>
you don't need to use it
<karolherbst>
ohh.. that would help
<bnieuwenhuizen>
just let radeonsi do compute shaders and ignore LLVM has this custom ABI made for Clover
<karolherbst>
the nir additions are really not big
<karolherbst>
maybe 5 intrinsics?
<karolherbst>
we have a special kernel input load thing, because the ubo0/1 situation is a bit of a mess atm
<karolherbst>
and I didn't get to cleaning all that up
<karolherbst>
but besides that there isn't really that much added on top
<karolherbst>
bnieuwenhuizen: okay.. will try that and see how well that works then
<bnieuwenhuizen>
are the others stuff we'd have implemented for vulkan?
<karolherbst>
there might be other things I implicitly require, like I think I lower away all derefs
<karolherbst>
but I'll be able to say more once I actually try it
<karolherbst>
we also have some gallium api additions, but nothing terrible
<karolherbst>
but for clover that's needed anyway
<karolherbst>
the biggest issue for now is just insanely huge kernels, but I might have a few ideas on improving the situation without requiring drivers to support nir function calls
Battersea has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
if you move to vulkan there is such a thing as callables using the RT extensions
<karolherbst>
right.. and Intel uses OpenCL C to create huge shaders being a single function again :)
<karolherbst>
though I suspect the callables are handled in special ways
<bnieuwenhuizen>
well, with RT there is huge pressure to support them as separate shaders
<karolherbst>
yeah..
<bnieuwenhuizen>
Intel already does and we're working on it
<karolherbst>
but for CL we really just want to be able to call functions
<karolherbst>
which I think is more or less the same thing?
<karolherbst>
though not sure how one deals with shared data in RT
<bnieuwenhuizen>
maybe pointers to scratch mem get weird
<karolherbst>
or if there is such thing
<karolherbst>
yeah... maybe
<bnieuwenhuizen>
(i.e. invocation local data further up the stack)
<karolherbst>
I suspect we'd need to fix a few nir passes to make it all work
<karolherbst>
but it's really mostly backend work to support it for real
<karolherbst>
but what's the most painful part is the builtin libclc lib which has a few builtins which are _massive_
<karolherbst>
so we might get around by only call them
<karolherbst>
and then we don't have any of the state mess
<karolherbst>
if your kenrel calls into some of them 15 times, your kernel explodes if you inline everything
<karolherbst>
mhhhh
<karolherbst>
actually...
<karolherbst>
yeah maybe that would be a good first step
Haaninjo has quit [Quit: Ex-Chat]
iive has quit [Quit: They came for me...]
<JohnnyonFlame>
is there a "spec correct" way of allocating with gbm in a way I can share the same buffer on two different EGL Contexts, e.g. so I can transparently render to a surface using it and then draw that as a texture with zero copy?
<JohnnyonFlame>
a few specific mali drivers im using kinda exposes internals which I learned could be used to create Pixmap buffers from dma_buf descriptors, and that works, but it's not really a portable solution at all
Mangix has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
<daniels>
emersion: ‘just because we can’ is a very unfair