ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
jewins has quit [Ping timeout: 482 seconds]
LexSfX has joined #dri-devel
<mhenning>
re Some of the talk about function calls above: sometimes I wonder if it's worth it to implement nonrecursive function calls in nir
<mhenning>
that is, if you inline away any cycles in the call graph at the nir level, the remaining calls can be implemented without a stack pointer - locals can be stored at fixed addresses
<mhenning>
which might be simpler to implement for backends
<karolherbst>
mhenning: that's why I was thinking about doing only calls into libclc
<karolherbst>
because those really only depends on inputs
<karolherbst>
*depend
<mhenning>
yeah, that might be a good special case to start with
<karolherbst>
you still have to save registers and that needs some driver internal ABI to not overwrite registers, but that might be easy enough to implement
co1umbarius has joined #dri-devel
<mhenning>
yeah, you still need to save registers and return address somewhere
columbarius has quit [Ping timeout: 480 seconds]
<karolherbst>
on volta+ GPUs we even have to save the return address, but yeah.. details :)
<daniels>
emersion: I do definitely understand the 'why frontend rather than backend?' argument though. we did look at doing the Valhall compiler for Panfrost in Rust instead, with the same idea of limiting the damage. our conclusion was that it would actually be worse in terms of impact: you'd need to expose the entire Gallium + NIR interfaces into Rust, which was a much larger surface area ...
<daniels>
at least with rusticl, you can turn it off if you want to enjoy the current C++ experience
<karolherbst>
daniels: I think the point was that people never working on gallium APIs say that "uhh I _might_ have to touch Rust code when I might change gallium APIs, but I can't do Rust" as the main issue
<karolherbst>
that argument would be more valid coming from somebody working on the gallium API or with gallium more often :)
<karolherbst>
sure, it's a potential issue, but what matters is, if relevant people think this is a deal breaker and not just people coming up with random reasons to bikeshed
<daniels>
karolherbst: I understand the argument, but you could've been more constructive too tbh
<karolherbst>
yeah.. I know :(
<karolherbst>
sorry for that
<daniels>
(also, even though demolishing the 'DRI' interface is unequivocally a good thing, that does mean that winsys people are now going to be directly touching Gallium in the near future)
<karolherbst>
yeah.. that might actually be true
<daniels>
as someone who's had to explain the code flow to several people now, I can assure you it is very true :P
<daniels>
winsys becomes far more tractable once you take out the middle layers which make it impossible to reason about
<karolherbst>
I think we should turn this into something more constructive and instead of saying "this is stupid, don't do this" rather come up with "what needs to change in order to make it happen without being a pita"
<daniels>
anyway, I think CL is a great place for a Rust proving ground. having something deeply isolated within a backend doesn't prove anything really. CL is no cost, because the current frontend is so useless (for good technical reasons, and bad non-technical reasons) that it doesn't work with any real usecases on any real driver. adding rusticl is a less-disruptive option which lets us gradually figure out the good & bad parts.
dakr has quit [Remote host closed the connection]
<daniels>
if it's a total non-starter: fine, at least we know. if we just need to learn useful adaptation techniques and how to shape APIs better: great, that gives us a future pathway forward. but definitely better starting from an isolated frontend than trying to start by exposing the whole of NIR + Gallium backends, because that's like trying to rebuild an aircraft engine mid-flight
<karolherbst>
yeah
<karolherbst>
well... I do use nir stuff though, but in a total trivial way for most parts...
<Frogging101>
One way to quantify the supposed cost is to estimate what proportion of changes to things other than rusticl is likely to require rust changes
<Kayden>
also, I think the discussion has been: rusticl / rust vs clover / c++
<Frogging101>
Maybe take the last 1000 or whatever Mesa commits, and estimate how many of them would have required Rust changes if rusticl had been merged
<karolherbst>
anyway.. if people don't want to touch Rust code to make changes, then just ping me and I make it work or something.. dunno
<Kayden>
I've heard from -quite- a few people that they loathe working with clover's existing codebase and want something different. starting fresh is a good idea, according to most people I've talked to. curro, as the clover developer, disagrees, obviously
<daniels>
Kayden: you're right that those are largely orthogonal
<karolherbst>
Frogging101: not many
<karolherbst>
Kayden: same here
<Kayden>
I think moving away from clover is a good idea.
<karolherbst>
yep
<karolherbst>
that's my point
<daniels>
Kayden: working on e.g. Chromium is far less painful than Clover
<karolherbst>
I said multiple times that clover is a dead end, and not because it's technical bad
<karolherbst>
if people hate working on it, there is no point keeping it
<Kayden>
I remember talking to jekstrand at one point, who I believe thought, if rust became a problem in rusticl, we could probably port it in short order to a different language, if we decided that was a better plan
<karolherbst>
daniels: oof
<Frogging101>
If people hate working on it then doesn't that mean it is technically bad? I assume there's a reason they don't like working on it. Like architecture or code quality
<karolherbst>
I really can't put my finger on it
<karolherbst>
it's just you start working on it and you just hate it
<Frogging101>
A bunch of unrelated people saying something is hard to work on probably means more than they just don't like the name
<Frogging101>
or some other non technical thing about it
<Kayden>
I haven't looked at the amount of glue & wrapping needed, nor how advantageous rust is to rusticl intrinsically
<daniels>
Kayden: it's useful to recognise that a) C++ within Mesa is basically a dead end (cf. GLSL IR), b) Clover is a dead end independently of that, c) rusticl gives us something very helpful we don't currently have, and d) various Mesa developers (maintainers of 4 drivers I can think of) would like to see a stalking horse for Rust in Mesa to see if it's long-term viable
<Kayden>
yep
<daniels>
and whilst those things _can_ be independent, rusticl neatly ties all four into one
<karolherbst>
also.. we won't know how painful it is to maintain it if we are not doing it
<daniels>
^
<karolherbst>
nothing relies on rusticl, we can always pull it out if it becomes too much of a hazzle
<karolherbst>
anyway.. all of the glue code lives inside "rusticl/mesa"
<karolherbst>
which is like 1k loc
<daniels>
that's point d. clover is pretty useless now, so we lose nothing by diluting the CL frontend developer pool, such as it is. clover is already developer-hostile. rusticl does increase that barrier to entry, but if we have a gullib^Wwilling volunteer to deal with it, and it helps prove the other points, then ... what's to lose?
<karolherbst>
ehh maybe more
<Kayden>
yep. I think we have pretty broad agreement that starting over is good, and rusticl is a better starting point than clover
<daniels>
if Karol (& the others involved) were just dumping & running and leaving others to deal with the API fallout, that would be a non-starter for sure, but given what we've been presented, moving forward seems good
<karolherbst>
yeah.. I'd like if people would more approach it from a "what do we have to win" perspective and not "no this is stupid, please don't bother me with it" attitude :(
<Kayden>
having OpenCL 3 is exciting, and having a codebase that's actually being worked on and improved is great
<karolherbst>
and it actually works
<Kayden>
right.
<daniels>
if in 2024 it's still a one-man band then that will tell us a lot, but if the Mesa developer pool grows at least mild Rust literacy and it seems like Mesa+Rust can outlive Karol, then that's viable
<karolherbst>
done some darktable stuff with it
<karolherbst>
though darktable has OpenCL detection we might fail, because the way I do compilation stalls :)
<Kayden>
and run luxmark within 2% performance of the intel CL driver :)
<daniels>
if not, we just consign rusticl to the same pool of failed experiments as many others
<karolherbst>
yeah
<daniels>
Kayden: which one? :P
<karolherbst>
though I have ideas on how to make the others run
<karolherbst>
but that really digs into the compiler issue
<karolherbst>
though I was "cheating" a bit by starting from a hot cache... I really have to rework on how I do compilations
<Kayden>
point is, there's a lot of interest in trying rust, and if it ends up being horrible (unlikely) and we want to move away from it then porting rusticl to C is probably a better plan than going back to clover.
<Kayden>
which, we can do later, if we have to (but we probably won't at all)
<daniels>
++
digetx has joined #dri-devel
<zmike>
rust 💪
ybogdano has quit [Ping timeout: 480 seconds]
<karolherbst>
guess I just merge it tomorrow morning and let people scream later or something then? 🐧🐧🐧
<zmike>
the screaming has already begun
<zmike>
can't you hear it
<zmike>
looking forward to the now-inevitable glsl compiler rewrite in rust tho
<karolherbst>
:D
<karolherbst>
I don't hear screaming, just noises coming out of the bikeshed
<daniels>
there's clear consensus to merge - certainly far less screaming than there was moving to MRs for reviews or, say, instituting CI - if there's clear consensus to revert then that will surely happen too
<Kayden>
ok, one small objection to merging
<Kayden>
unless everything is fully hidden behind build options that are off by default
<karolherbst>
they are
<Kayden>
ok
<karolherbst>
and CI is testing it
<karolherbst>
I even run piglit testing on llvmpipe with rusticl
<Kayden>
otherwise I was just going to say, if it were to cause build problems for anybody's stuff, monday morning might be preferable to friday night :)
<karolherbst>
(I even wired up rustfmt to be annoying)
Company has quit [Quit: Leaving]
<karolherbst>
maybe I wait until marge isn't doing antyhihg then or so :)
chipxxx has quit [Remote host closed the connection]
kts has joined #dri-devel
arc-arthur_ has joined #dri-devel
pcercuei has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
<airlied>
bnieuwenhuizen: I think I was getting to the realisation of using compute shaders might be workable, but have to look again at it, the llvm abi is a big deterent from using it
<airlied>
once rusticl is merged, I'd like to get the minimum viable patchset for ACO compute shaders in first
<bnieuwenhuizen>
hmm, does the nir path have LLVM ABI problems too?
<airlied>
the nir/llvm path I wrote for kernels definitely hit it
<airlied>
but maybe I just need lowering to compute shaders, I'll play around again once rusticl is in
heat has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
rasterman has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
eukara has quit []
eukara has joined #dri-devel
kalidows_ has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
iive has joined #dri-devel
kalidows_ has quit [Ping timeout: 480 seconds]
sravn has joined #dri-devel
glennk has joined #dri-devel
Daanct12 has quit []
Daanct12 has joined #dri-devel
Daanct12 is now known as Danct12
chipxxx has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.5]
Vanfanel has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
srslypascal is now known as Guest2454
srslypascal has joined #dri-devel
Guest2454 has quit [Ping timeout: 480 seconds]
Vanfanel has joined #dri-devel
Vanfanel has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
kushal__ has joined #dri-devel
camus has quit [Remote host closed the connection]
chipxxx has quit [Read error: No route to host]
camus has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
off^ has joined #dri-devel
kushal__ has quit []
JohnnyonFlame has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
jewins has joined #dri-devel
fab has quit [Quit: fab]
smaeul has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
kts has joined #dri-devel
kalidows_ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
eukara has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
off^ has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
pcercuei has quit [Quit: dodo]
camus has quit [Remote host closed the connection]