ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Bennett has quit [Remote host closed the connection]
fxkamd has quit []
Haaninjo has quit [Quit: Ex-Chat]
tursulin has quit [Read error: Connection reset by peer]
mlankhorst has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
dllud has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
iive has quit []
cworth has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
<graphitemaster>
Going to give everyone a heart attack here. Imagine using machine learning based image upsamplers to upsample a smaller die GPU litograph to fill in the missing transistors.
<ajax>
anholt: no. but xcompmgr -a is still a thing.
YuGiOhJCJ has joined #dri-devel
ybogdano has joined #dri-devel
pnowack has quit [Quit: pnowack]
maxzor has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
nchery has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
linearcannon has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
aravind has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
<karolherbst>
jekstrand: cool, thanks
<jekstrand>
karolherbst: I started playing with trying to detangle things a bit today. Still don't have my hackery building yet. Getting lost in the mess of references, Arcs, etc.
<jekstrand>
I'm sure I'll get my barings eventually. :)
<jekstrand>
*bearings
<jekstrand>
karolherbst: Feel free to change stuff out from under me, though.
<karolherbst>
yeah.. not quite sure what I am planning to work on today then though. If you want to work on the dep situation and try to move the CL bindgen stuff into its own crate I probably look into getting spir-v kernels to compile
<karolherbst>
so I can ignore llvm for now
aravind has joined #dri-devel
<jekstrand>
:)
<karolherbst>
btw... do you think we should link kernels on a spir-v or nir level?
<jekstrand>
karolherbst: Just bindgen src/compiler/clc/clc.h and don't do LLVM yourself.
<karolherbst>
mhhh
<jekstrand>
Yeah, I know, there are LLVM bindings for rust but I think having all our LLVM to SPIR-V stuff in one place is more important than taking advantage of those bindings.
<karolherbst>
true
<jekstrand>
The only reason I haven't converted clover is because it looked like a giant pain.
<karolherbst>
yes
<karolherbst>
the "native" path is annoying
<jekstrand>
But if we're doing something new, I think clc.h should cover it and we should keep it centralized and expand clc.h if we need something more.
<karolherbst>
but where does the clc stuff live?
<jekstrand>
src/compiler/clc
<karolherbst>
uhm.. mhh, weird, don't see it..
<karolherbst>
ehh wait
<airlied>
I had some porting of clover to use clc
<karolherbst>
I rebased on master...
<jekstrand>
karolherbst: You'll want the two meson fixes in my branch, FYI
<jekstrand>
karolherbst: src/compiler/clc is what I built the intel_clc thing for ray-tracing on.
<jekstrand>
And it's also used by the CLOn12 code from Microsoft
<jekstrand>
IIRC, there was some discussion that we might want to be able to customize the list of supported SPIR-V extensions some day but we've not done that and I'm not even convinced it's needed.
<jekstrand>
Maybe we'll want that for rusticl but let's start with it as-is and see where we end up
<karolherbst>
yeah.. I doubt we need it
<jekstrand>
In any case, if you want to get actual kernels compiling, that'd be swell
<karolherbst>
most clc extensions are... things you always can or want to implement anyway
<karolherbst>
yep
<karolherbst>
that was my goal :D
<jekstrand>
:D
<karolherbst>
shouldn't be a huge issue to bindgen clc
<jekstrand>
No, it'll be trivial
<karolherbst>
I am just wondering if we want a mesa mega crate or if we want to split it up...
<jekstrand>
idk
<jekstrand>
Ideally, I think we'd want crates::mesa::nir, crates::mesa::gallium, etc.
<karolherbst>
yeah... maybe
<karolherbst>
jekstrand: the thing is just, that usually we end up pulling in a lot of stuff because of header deps
<karolherbst>
like most gallium headers also kind of include mesa core stuff
<jekstrand>
Yeah...
<karolherbst>
but maybe we can have clc and nir seperated...
<jekstrand>
And there's no good way to trim it down
<karolherbst>
or maybe we just have one big one and some small ones where we think it makes sense
<jekstrand>
Yeah
<karolherbst>
one mesa crate with nir, mesa, gallium, etc.. and clc be another one
<jekstrand>
One big one is probably fine
<karolherbst>
it's not like any driver won't use nir or mesa or gallium
<jekstrand>
I hadn't thought about the way headers pollute everywhere
Company has quit [Quit: Leaving]
<jekstrand>
nope
<karolherbst>
well.. I just put it in one mega crate and if we think it makes sense to split we can always do that later
<karolherbst>
jekstrand: did you already rebase? maybe I can just use your branch then
<karolherbst>
ah no, doesn't seem like it
camus has quit [Read error: Connection reset by peer]
aravind has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
<jekstrand>
karolherbst: Yeah, I reabased on a couple days ago
<jekstrand>
karolherbst: Feel free to rebase again
<jekstrand>
Benefits of writing something new: Very few rebase conflicts
<karolherbst>
already did so
<karolherbst>
yeah :D
<jekstrand>
:D
<karolherbst>
so let's see if stuff still works :D
<jekstrand>
:)
<jekstrand>
Should
<jekstrand>
test_basic works for me prior to me hacking it all to death
<karolherbst>
nice
<jekstrand>
I'm running on iris
<karolherbst>
I'll probably juse use llvmpipe
<jekstrand>
Sounds fine. Both should be similarly good at this point and using different things is probably good anyway from a coverage POV
* jekstrand
-> bed
<karolherbst>
mhh, the last thing I was working in was on the command queue thing and getting some warnings, not sure if I just stopped and wanted to finish something or not...
<karolherbst>
ohh an assert.. let's dig into that then
<DrNick>
everybody doing some intense Elden Ring profiling sessions tonight?
<DrNick>
just collecting all that data
<DrNick>
for research
<karolherbst>
airlied: llvmpipes handling of PIPE_COMPUTE_CAP_GRID_DIMENSION is wrong
<karolherbst>
it has to be a 64 bit value
<karolherbst>
no idea why, but that's how it should be :D
<airlied>
does anything use that?
* airlied
can't see clover using it
<karolherbst>
well.. rusticl does
<karolherbst>
but maybe we can hardcode to 3?
<karolherbst>
_but_
<karolherbst>
we do have hardware only doing 2 I think
jewins has quit [Ping timeout: 480 seconds]
<airlied>
feel free to fix it of you need it :-)
<karolherbst>
yeah already did, but maybe we should drop it and just hardcode 3? dunno :D
<karolherbst>
anyway... moving on
<karolherbst>
I am confused though, does iris and llvmpipe turn on CL by default now? or maybe I missed some change
<airlied>
llvmpipe still has LP_CL=1
<karolherbst>
I know, but I don't set it
<karolherbst>
probably something I am doing wrong in rusticl
<karolherbst>
ahh.. I check for PIPE_SHADER_IR_NIR not PIPE_SHADER_IR_NIR_SERIALIZED
Duke`` has joined #dri-devel
<karolherbst>
jekstrand: force pushed my branch as I had to fix the queue thread. But at least there are no regressions from the last time I checked things :)
<karolherbst>
I really can't stress enough how much I like how threading is implemented in rust
maxzor has joined #dri-devel
<karolherbst>
sooo.. now clc :)
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<cmarcelo>
linkmauve: thanks for the "compile the whole bindings as a static library" idea, it works OK here. I do miss ability to impl stuff into the C types, but can probably live as free functions.
itoral has joined #dri-devel
danvet has joined #dri-devel
mattrope has quit [Ping timeout: 480 seconds]
Akari has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
Net147 has quit [Quit: Quit]
mlankhorst has joined #dri-devel
Net147 has joined #dri-devel
kts has joined #dri-devel
<Venemo>
graphitemaster: sounds good, where can I download this upsampler? :P
Net147 has quit [Read error: No route to host]
Net147 has joined #dri-devel
mszyprow has joined #dri-devel
Net147_ has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
Net147_ has quit [Read error: No route to host]
Duke`` has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
thellstrom has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Akari has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Strit[m] has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
egalli has quit []
Mershl[m] has quit []
Tooniis[m] has quit []
neobrain[m] has quit []
shadeslayer has quit [Quit: Bridge terminating on SIGTERM]
apinheiro[m] has quit []
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
nielsdg has quit []
moben[m] has quit []
martijnbraam has quit [Quit: Bridge terminating on SIGTERM]
gnustomp[m] has quit []
Vin[m] has quit []
Wallbraker[m] has quit []
YaLTeR[m] has quit []
halfline[m] has quit []
doras has quit []
zzoon_holidays_till_2nd_Feb[m] has quit [Quit: Bridge terminating on SIGTERM]
tomba has quit [Quit: Bridge terminating on SIGTERM]
heftig has quit [Quit: Bridge terminating on SIGTERM]
Newbyte has quit [Quit: Bridge terminating on SIGTERM]
ella-0[m] has quit []
kallisti5[m] has quit []
unrelentingtech has quit []
danylo has quit [Quit: Bridge terminating on SIGTERM]
robertmader[m] has quit []
Anson[m] has quit []
Dylanger has quit [Quit: Bridge terminating on SIGTERM]
chivay has quit []
MrR[m] has quit []
blue_penquin has quit []
kalli0815[m] has quit []
tintou has quit [Quit: Bridge terminating on SIGTERM]
reactormonk[m] has quit []
yshui` has quit []
bylaws has quit [Quit: Bridge terminating on SIGTERM]
LaughingMan[m] has quit []
_alice has quit [Quit: Bridge terminating on SIGTERM]
xerpi[m] has quit []
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
MatrixTravelerbot[m] has quit [Max SendQ exceeded]
Eighth_Doctor has quit []
undvasistas[m] has quit []
Sumera[m] has quit []
JohnStultz[m] has quit []
sigmoidfunc[m] has quit []
Mis012[m] has quit []
pushqrdx[m] has quit []
exit70[m] has quit []
x512[m] has quit []
gagallo7[m] has quit []
zamundaaa[m] has quit []
JosExpsito[m] has quit []
ambasta[m] has quit []
anparra[m] has quit []
chema has quit []
cleverca22[m] has quit []
DrNick has quit []
jasuarez has quit [Quit: Bridge terminating on SIGTERM]
dafna2[m] has quit []
PiGLDN[m] has quit []
aura[m] has quit []
gdevi has quit []
T_UNIX has quit []
enick_111 has quit []
naheemsays[m] has quit []
hasebastian[m] has quit []
mairacanal[m] has quit [Quit: Bridge terminating on SIGTERM]
cwfitzgerald has quit [Quit: Bridge terminating on SIGTERM]
enick_722 has quit []
kusma has quit [Quit: Bridge terminating on SIGTERM]
HayashiEsme[m] has quit []
onox[m] has quit []
RAOF has quit []
JohnnyonF has quit [Ping timeout: 480 seconds]
Wallbraker[m] has joined #dri-devel
Wallbraker[m] has quit [Remote host closed the connection]
camus1 has joined #dri-devel
Wallbraker[m] has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<linkmauve>
cmarcelo, have a look at the way I did the wrappers in !14862, in src/gallium/frontends/glide/gallium.rs
<linkmauve>
karolherbst, did you do anything nir yet? Its static inline headers have been annoying to use so far, because those don’t get translated by bindgen.
<karolherbst>
linkmauve: no, but I have a workaround for that
<linkmauve>
I’ve been looking into making a different nir_builder, but that kind of duplication is meh.
<karolherbst>
I think atm it makes more sense to write nir passes in C code
<karolherbst>
and try to not have to use the nir API too much
<cmarcelo>
linkmauve: no gallium.rs do you mean glide.rs?
<linkmauve>
For me it’s for the shader generation, I’m doing TGSI for now because it was easy to start with, but I need something more composable than just concatenating text together.
<linkmauve>
cmarcelo, ah no, I meant pipe.rs
<karolherbst>
linkmauve: you can use static inline stuff, you just need to generate wrappers for those
<linkmauve>
In pipe.rs, as mentioned in the module docstring, I tried to do safe wrappers around the pipe_* structs and functions I needed.
<linkmauve>
It’s nowhere close to the complete Gallium API, but it’s good enough for my driver.
<karolherbst>
linkmauve: mhhh... maybe we shouldn't duplicate efforts here as I already did wrap gallium
<karolherbst>
but...
<linkmauve>
I hadn’t seen your effort when I started. :x
<karolherbst>
yeah... I didn't work on it for over a year though :D
<linkmauve>
Probably the reason why. :D
<karolherbst>
I think it makes sense to have a shared module for mesa.rs but...
<karolherbst>
I have no idea if my code is nice or not
<linkmauve>
That’s pretty much exactly the parts I did. ^^
<karolherbst>
nice
<karolherbst>
linkmauve: we could try to have shared code there, I am atm just merely toying around and see what actually works well from a development pov
<linkmauve>
I like my PipeTransfer (called TextureMap IIRC) better, as it exposes iterators taking into account the format and stride and such, not just a raw pointer.
<linkmauve>
Yup, but that was exactly my reasoning as well.
<linkmauve>
Experiment, and see what is sticking.
<karolherbst>
yeah.. atm I didn't had to write many helpers yet
<karolherbst>
but I also don't see my stuff paning out this year unless there is a mayor push
<karolherbst>
linkmauve: the only reason I have PipeTransfer is because of the implicit drop
<karolherbst>
I literally do nothing else with it
<karolherbst>
I think...
<karolherbst>
ehh
<karolherbst>
maybe I use the ptr for copies...
<karolherbst>
linkmauve: the thing is.... CL is quite explicit with strides
<karolherbst>
you can pass in explicit strides via the API
<karolherbst>
so...
<linkmauve>
Ah, that’s nice.
<karolherbst>
hiding the strides behind magic doesn't work for me :/
ppascher has quit [Read error: Connection reset by peer]
<karolherbst>
I already did some image allocation but...
<karolherbst>
CL is so stupid
<karolherbst>
so you can back an image with a random cl_mem object because for fun
<karolherbst>
linkmauve: it gets even funnier
<karolherbst>
even if you use images in CL you can use your own pitches/strides :)
<linkmauve>
:o
<karolherbst>
because... I don't know why
<linkmauve>
Sounds like a recipe for suboptimal results.
<karolherbst>
it's a mess
<linkmauve>
Like I don’t know why AMD was allocating 4× the memory needed, but I trust the backend to understand the hardware requirements correctly. :)
<karolherbst>
"Unlike *mut T, NonNull<T> was chosen to be covariant over T. This makes it possible to use NonNull<T> when building covariant types, but introduces the risk of unsoundness if used in a type that shouldn’t actually be covariant. (The opposite choice was made for *mut T even though technically the unsoundness could only be caused by calling unsafe functions.)"
MajorBiscuit has joined #dri-devel
<karolherbst>
I think it's fine if we use it inside mesa especially if the ptr is not shared and managed by us
<karolherbst>
maybe there is no benefit.. dunno
<karolherbst>
linkmauve: I think in the end it allows for more optimizations on the compiler end
<karolherbst>
ohh
<karolherbst>
Option<NonNull<T>> is smaller than Option<*mut T>
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
samuelig__ has joined #dri-devel
rasterman has joined #dri-devel
tursulin has joined #dri-devel
pnowack has joined #dri-devel
kts has joined #dri-devel
kchibisov has quit [Server closed connection]
kchibisov has joined #dri-devel
karolherbst_ has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
karolherbst_ is now known as karolherbst
pcercuei has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonFlame has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
_alice has joined #dri-devel
ambasta[m] has joined #dri-devel
Andy[m] has joined #dri-devel
aura[m] has joined #dri-devel
apinheiro[m] has joined #dri-devel
blue_penquin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
chivay has joined #dri-devel
RAOFhehis[m] has joined #dri-devel
cleverca22[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna2[m] has joined #dri-devel
dcbaker has joined #dri-devel
Anson[m] has joined #dri-devel
Guest452 has joined #dri-devel
doras[m] has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
exit70[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
frytaped1 has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
HayashiEsme[m] has joined #dri-devel
Guest453 has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JohnStultz[m] has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kalli0815[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kusma has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
Mershl[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
nielsdg has joined #dri-devel
onox[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
MrRoffline[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
shadeslayer has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
unrelentingtech has joined #dri-devel
MatrixTravelerbot[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
pmoreau is now known as Guest472
Venemo has quit [Server closed connection]
Venemo has joined #dri-devel
<karolherbst>
sometimes rust is weird
pH5 has quit [Server closed connection]
pH5 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<pcercuei>
karolherbst: example?
<pcercuei>
don't leave us hanging ;)
<karolherbst>
ehhh.. I forget a Vec<...>
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
frytaped1 is now known as go4godvin
mlankhorst has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
mclasen has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
MTCoster__ has left #dri-devel [#dri-devel]
MTCoster has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
<karolherbst>
linkmauve: btw, do you know a good way to convert a char* with a length to String?
<karolherbst>
although.. I might not as the same thing will be used over ffi anyway...
<karolherbst>
but I still like to have something with an explicit size
thellstrom1 has quit [Read error: No route to host]
devilhorns has joined #dri-devel
rgallaispou has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
DPA has quit [Read error: Connection reset by peer]
DPA has joined #dri-devel
mlankhorst has joined #dri-devel
<karolherbst>
jekstrand, jenatali: for CLC the source has to be null terminated, no?
Guest453 is now known as heftig
<karolherbst>
uhhhh
<karolherbst>
Rusts String handling might actually be too smart :(
<karolherbst>
'An instance of this type is a static guarantee that the underlying bytes contain no interior 0 bytes (“nul characters”) and that the final byte is 0 (“nul terminator”).' yeah well.. that can actually happen with source code
<karolherbst>
although it shouldn't...
<karolherbst>
maybe I ignore those potential issues and assume evertying will feed in sane code
heftig is now known as heftig2
heftig2 has quit []
heftig2 has joined #dri-devel
heftig2 is now known as heftig
ella-0_ has joined #dri-devel
jannau has quit [Server closed connection]
jannau has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
<pq>
karolherbst, trying really too hard to not make a copy of the string? :-)
<karolherbst>
pq: I have to make a copy, but...
<karolherbst>
I am not sure if I can just reject strings with \0 chars in the middle...
<karolherbst>
maybe I just store them as Vec<c_char> and be done with it...
<karolherbst>
and I probably have to copy anyway
<pq>
would such strings have any use?
<karolherbst>
pq: source code
<pq>
IOW, no.
<karolherbst>
yeah...
<karolherbst>
I am sure it would be fine..
<pq>
you could always just take the string up to the first \0 rather than fail
<karolherbst>
pq: thing is.. they are optionally null terminated
<pq>
sure
<karolherbst>
in case they are not, we get an explicit size
<pq>
is that a problem?
<karolherbst>
I... don't know
<pq>
btw. there are things like CStr and CString IIRC
<karolherbst>
right, but they check for null chars and throw errors
<pq>
stop at the first \0 or the given length, whichever comes first - is there a reason to make things harder than that? :-)
<pq>
surely it's not like X11 where a "string" can contains two things, the second starting after the first \0...
<karolherbst>
it makes the code ulgy
<karolherbst>
*ugly
<pq>
only the internals of the wrapper object around C ABI is ugly - it always is ugly
<karolherbst>
CString in itself is already a super annoying class
<karolherbst>
as it can only be created from Vecs
<pq>
and CStr?
<karolherbst>
doesn't copy
<karolherbst>
and I'd rather not want to depend on clients to not free strings..
<karolherbst>
I am sure I am required to copy
<pq>
ok
<karolherbst>
that the size of the sources is optional is just making it all annoying
<karolherbst>
mhh
<karolherbst>
I have an idea
<pq>
sure, but there is no way to avoid that. Just make the Rust API you expose to Rust code nice and clean, and tuck the ugliness in the wrappers.
<karolherbst>
well.. I am not exposing anything
<pq>
what are you doing?
<karolherbst>
implementing CL in rust
<pq>
then you are exposing your C ABI wrapper to your Rust CL implementation.
<karolherbst>
yeah sure, but I don't have to do anything with the sources :)
kts has quit [Quit: Konversation terminated!]
<karolherbst>
so it's a bit pointless to wrap it up nicely
<karolherbst>
the only thing I need to do with it is to hand in a pointer to a rust wrapper around clc :D
<pq>
if you say so ;-)
<karolherbst>
so sure, I could wrapp it like hundreds of times or I just pass in a c ptr
<karolherbst>
I think CString is probably a good type for that already.. just have to make the code creating it not annoying
<karolherbst>
wait...
<karolherbst>
I have to merge all those given strings to one big one?
itoral has joined #dri-devel
<karolherbst>
uhudhasudhsdjasdhasjdhsd
<karolherbst>
well if I have to create Strings anyway...
<pq>
:-)
<karolherbst>
ahhhhhhhhhhhhhh
<karolherbst>
the trait `From<Vec<i8>>` is not implemented for `Vec<u8>`
<karolherbst>
....
<karolherbst>
yeah.. why require creating CString from u8 if c_char is i8...
rgallaispou has joined #dri-devel
kts has joined #dri-devel
APic has quit [Server closed connection]
APic has joined #dri-devel
pcercuei has quit [Quit: Lost terminal]
<linkmauve>
karolherbst, C char’s signedness depends on the platform.
<linkmauve>
Most notably, it differs on x86 vs. ARM.
<karolherbst>
yeah....
<linkmauve>
You might want to cast them as *mut _ before using them.
<karolherbst>
I can't
<karolherbst>
well.. ehh
<karolherbst>
they are already *mut, but it's client memory
<karolherbst>
ehh wait
<karolherbst>
it's *mut *const
<linkmauve>
karolherbst, reinterpreting client pointers as a different (un)signedness of char is safe.
<linkmauve>
The size and alignment requirement is the same.
<karolherbst>
ehh yeah
<karolherbst>
but why would that be related to *mut casting
<linkmauve>
The relevant part was to cast to a pointer to _, so that it would be the correct i8 or u8 depending on the platform.
<karolherbst>
ohhh
<karolherbst>
I missed the underscore
itoral has quit [Ping timeout: 480 seconds]
degasus has quit [Server closed connection]
degasus has joined #dri-devel
degasus is now known as Guest499
<pq>
are you guys using Ferrous systems' rust-analyzer with editor integration btw.?
<pq>
oh, maybe that won't work too well with things like Mesa
<linkmauve>
I don’t, so far I still use a plain vim with just syntax highlighting.
<linkmauve>
Or is it nvim? One of those.
<linkmauve>
I’ve heard good things about LSP, but haven’t tried it so far.
<karolherbst>
I've tried using visual studio once but it's a pain with meson
<pq>
Good LSP integration in the editor is important, which is why I learnt Rust with vscode & rust-analyzer.
<pq>
yeah, I can imagine meson instead of cargo can be a lot of pain
<karolherbst>
meson generally is pain in vscode
<karolherbst>
no idea what jenatali is doing, probably just vim or something :D
<pq>
that's a second level then, I guess
iive has joined #dri-devel
pcercuei has joined #dri-devel
tarceri_ has joined #dri-devel
tarceri has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
maxzor_ has joined #dri-devel
sdutt has joined #dri-devel
<danvet>
mripard, looks reasonable as an idea, and maybe in some dream world we eventually get to some real default/reset value handling
<danvet>
mripard, I'm not sure this will scale all that well, but for now it should be good enough I think
<danvet>
the i915 approach of having a hw state readout function for this is probably going to work out better
<danvet>
if/when we have a ton of these
mattrope has joined #dri-devel
nchery has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
milek7_ has quit [Server closed connection]
milek7 has joined #dri-devel
<mripard>
part of the issue is also to have an initial value argument in those properties creation functions
<mripard>
if we want to go the full-reset route, then we wouldn't need these
<mripard>
but at the same time, hw readout seems to be a fairly big effort to get right
<mripard>
so, is that an acked-by?
mwalle has quit [Server closed connection]
mwalle has joined #dri-devel
fxkamd has joined #dri-devel
vup has quit [Server closed connection]
vup has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
<danvet>
mripard, yeah sure
<danvet>
mripard, wrt hw state readout is a big thing: for simple stuff like this all you really need is to subclass your reset hook and just set the right value there
mszyprow has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
enunes has quit [Server closed connection]
enunes has joined #dri-devel
<jekstrand>
karolherbst: crazy
<jekstrand>
karolherbst: We may need to ues a char array for sources
<karolherbst>
jekstrand: yeah well... at least I got my first spirv to compile
<jekstrand>
Yeah, we'll see if a PR actually happens. But it seems like an obvious enough feature. There's a lot you can work around with a --env flag and the power of rust macros.
<jekstrand>
And they clearly need it for y.py so...
rasterman has joined #dri-devel
kts has quit [Remote host closed the connection]
pq has quit [Quit: bbl]
<anholt>
airlied: is there any plausible way to do a shader-db for llvmpipe? would love to know at a glance if !14999 helps the resulting code, too.
<anholt>
(and then, also, if followups to !14994 would help)
MajorBiscuit has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
dottedmag has quit [Quit: QUIT]
MajorBiscuit has joined #dri-devel
mbrost has joined #dri-devel
dottedmag has joined #dri-devel
ced117 has quit [Server closed connection]
ybogdano has joined #dri-devel
ced117 has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
hakzsam has quit [Server closed connection]
hakzsam has joined #dri-devel
pjakobsson_ has quit [Server closed connection]
pjakobsson has joined #dri-devel
Duke`` has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
jekstrand: Do we have write masks for texture instructions in NIR?
<anholt>
nope, texture instructions are not alu dests
<anholt>
but checking nir ssa components used can often get you the win.
<alyssa>
right, ok
<alyssa>
bifrost/valhall has write masks for texture instructions (4-bits)
<jekstrand>
crazy
<alyssa>
the semantic is a bit subtle though: it returns popcount(MASK) consecutive registers
<jekstrand>
Intel has something similar
<anholt>
v3d's pretty similar
<alyssa>
(unlike vec4 hardware, where it would return 4 consecutive registers and not touch some)
kem has joined #dri-devel
<alyssa>
(so code like `float a = texture(foo).a` doesn't have to waste 3 registers... sure, they'd be freed right after but it makes RA's job a lot harder than it has to be)
<alyssa>
Anyway, wasn't sure if other hardware had this ... figuring out if it should be optimized in NIR proper, backend-specific NIR analysis, or backend IR opt pass
<pendingchaos>
though for 16-bit, each bit in the mask corresponds to 2 16-bit values and the mask means something completely different for texture gathers
<pendingchaos>
amd has the same: writemask with popcount(MASK) registers
MajorBiscuit has quit [Ping timeout: 480 seconds]
<alyssa>
delightful
<jekstrand>
alyssa: I think Intel has some restrictions which make it weird, though. I don't remember the details off-hand, though.
<alyssa>
pendingchaos: where does ACO optimize this? (does it?)
<pendingchaos>
in aco_instruction_selection.cpp, while converting NIR to ACO IR
<jekstrand>
Actually... It's not that restricted. Pretty much just SKL+
<jekstrand>
alyssa: There's a nir_ssa_def_components_read() helper I added for exactly this.
<anholt>
jekstrand: yep, v3d40_tex.c uses it for this and it works great.
<alyssa>
jekstrand: So there is, TIL! thank you :-)
<jekstrand>
Oh, looks like we don't do real write masks in the Intel back-end today. We just delete unused trailing components.
<jekstrand>
I had a branch somewhere. I know I did.
* jekstrand
looks
<jekstrand>
Oh, that's right! It doesn't play nicely with EOT texture sends but we deleted those because they don't actually help anything.
<airlied>
you'd need some sort of x86 asm analyzer, also what metrics to use would be difficult, you'd at least want instruction count, but also how many vector instrs are used I suppose
<anholt>
I'd settle for code size, in this case :)
<airlied>
could just dump out the binary size then, that should be available
LexSfX has joined #dri-devel
<gawin>
probably forceful inlining is gonna make results more accurate
<gawin>
btw I remember reading somewhere that measuring llvm's intermediate code is good way to measure performance
CATS has quit [Server closed connection]
CATS has joined #dri-devel
<Kayden>
I very much doubt that
<Kayden>
it certainly gives you an idea of the complexity
<Kayden>
but there's a lot that goes on in the backend which matters. register usage that may determine how many threads you can spawn concurrently. wave size / number of simd lanes and access patterns of threads hitting memory which can make your caches signifcantly more or less efficient. register pressure and spilling.
<Kayden>
we have typically found that even collecting statistics about the final assembly isn't good enough of a proxy for actual performance
<Kayden>
it is certainly better than nothing, and can be used to argue that a compiler change has improved the code
<Kayden>
but fewer instructions may not matter at all
<Kayden>
moving discards up or down in the shader may be fantastic, or terrible, based on the probability of your condition early-exiting the shader
<Kayden>
(we've seen 10% speedups on a benchmark by moving discards early, and several % regressions in Skyrim from doing so, because we just stalled waiting for results and didn't get an early-exit)
<Kayden>
memory access pipelining matters, and is pretty arch specific
cworth has quit [Ping timeout: 480 seconds]
nsneck has quit [Server closed connection]
nsneck has joined #dri-devel
<alyssa>
Xwayland works but Xorg won't start
* alyssa
grabs her popcorn
<alyssa>
"Cannot run in framebuffer mode"
<alyssa>
I don't think I've gotten this failure mode yet
<alyssa>
(Weston/sway+Xwayland are fine)
cworth has joined #dri-devel
* alyssa
assumes it's not loading panfrost for... some reason
tobiasjakobi has joined #dri-devel
<airlied>
Kayden: yeah like with x86 branches aren't as bad as they are on gpus, so adding more jump to returns instead of exec mask hacks is important
tobiasjakobi has quit []
mszyprow has joined #dri-devel
<alyssa>
oh I think I know the issue this is awful
moony has quit [Server closed connection]
moony has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
lkw has quit [Remote host closed the connection]
<alyssa>
or not
ngcortes has quit [Ping timeout: 480 seconds]
dviola has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Server closed connection]
co1umbarius has joined #dri-devel
rasterman has quit [Remote host closed the connection]
* jekstrand
is done fighting Arc for the day
ngcortes has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.4]
mvlad has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
<karolherbst>
jekstrand: :d
<karolherbst>
:D
<karolherbst>
what did you try?
<karolherbst>
ohh, that stuff we talked about yesterday?
<karolherbst>
mhh
<karolherbst>
I need to rework that bit anyway, as I have to make some of those thread safe
<karolherbst>
so if you didn't come up with anything I just might try out rewriting it
gouchi has joined #dri-devel
gouchi has quit []
_alice has quit [Server closed connection]
_alice has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
cleverca22[m] has quit [Server closed connection]
cleverca22[m] has joined #dri-devel
<karolherbst>
jekstrand: I think I figured something out which should work out for getting rid of this silly include!
<karolherbst>
question is if I find a way without stupid casting or not