ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
YuGiOhJCJ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
gio has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
gio has joined #dri-devel
pcercuei has quit [Quit: dodo]
yuq825 has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
I wish we had a way to filter for "MRs blocked on review" versus "MRs open for literally any other reason"
<alyssa>
It's not my job to shepherd other people's MRs to merge, but maybe it is??
<alyssa>
I'm not sure if GitLab has the right affordances for this
<alyssa>
of the 133 open NIR MRs
<alyssa>
I would be happy to review what it takes to get them merged or closed or whatever
<alyssa>
But I can't even tell what's pending review, versus "the original author doesn't care anymore" or "the original author is going to get back to this, there's active review"
gio has quit [Ping timeout: 480 seconds]
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
<HdkR>
alyssa: Additional tags? :)
elongbug has quit [Remote host closed the connection]
gio has joined #dri-devel
<alyssa>
HdkR: Hmm, yeah, that could maybe work
<alyssa>
It wouldn't help with triage of the 1000 already-open MRs
<alyssa>
but maybe for going forward
djbw has joined #dri-devel
<HdkR>
MR not tagged with new labels, I guess people don't care enough to not be ignored ;)
<alyssa>
heh
<alyssa>
"so unfourtunately I confirm that we can't support shaderStorageImageWriteWithoutFormat"
frankbinns has quit [Remote host closed the connection]
<jenatali>
Nah, just shader variants
<alyssa>
jenatali: shader variants in your vulkan driver? likelier than I thought
<jenatali>
Oh, Vulkan. Uh... nevermind, good luck
<alyssa>
i'm shitposting about v3dv
<jenatali>
Ah I see
<jenatali>
We're running into format support issues with the 4444 formats, one of them is required but it's a different one than D3D has. We can get so close, but border color is wrong... unless we add shader code to fix it up D:
<alyssa>
oof.
<alyssa>
is this for glon12 or dozen?
<alyssa>
for glon12, the border colour quirk CAP will give you the format and then you can swizzle the format when packing the sampler
<jenatali>
Dozen
<jenatali>
For GL we'd just shader variant and not care
<alyssa>
for dozen, just don't set customBorderColorWithoutFormat and then you have the format at sampler create time and can swizzle in the sampler
<alyssa>
(does dozen need customBorderColor support at all?)
<jenatali>
It's not about custom, it's a problem with the builtin ones too
<jenatali>
The location of alpha changes
<alyssa>
ufffff
<alyssa>
right...
<alyssa>
(customBorderColor is mostly good for Zink, DXVK, and vkd3d and for some reason I don't think dozen cares about those 3 :-p)
<jenatali>
Yeah custom isn't a problem, well except for this format...
<jenatali>
Anyway, we'll probably just add it to D3D, as stupid a format as it is, was just commiserating about things that would require shader variants in a Vulkan driver and how they're impossible
<alyssa>
ah, yeah
<alyssa>
I mean
<alyssa>
some variants are possible
<alyssa>
if you're masochistic enoug
lemonzest has joined #dri-devel
cef has quit [Quit: Zoom!]
heat has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
bgs has quit [Remote host closed the connection]
Dr_Who has quit []
Dr_Who has joined #dri-devel
Company has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Dr_Who has quit []
Leopold_ has joined #dri-devel
agd5f has joined #dri-devel
kts has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
kzd has quit [Quit: kzd]
<ishitatsuyuki>
dumb question, what are the wider bool types in NIR (bool8, bool32) for?
<airlied>
some hw only has 32-bit booleans
bgs has quit [Remote host closed the connection]
itoral has joined #dri-devel
tzimmermann has joined #dri-devel
fab has joined #dri-devel
nchery has joined #dri-devel
alanc has quit [Remote host closed the connection]
sgruszka has joined #dri-devel
alanc has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
fab has quit [Quit: fab]
jkrzyszt has quit [Remote host closed the connection]
rasterman has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
frieder has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
thellstrom has joined #dri-devel
danvet has joined #dri-devel
tursulin has joined #dri-devel
fab has joined #dri-devel
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
<dj-death>
there is no way in NIR to tell whether a sampler variable points to a combined image/sampler binding or just a sampler binding right?
vliaskov has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
frankbinns2 has joined #dri-devel
lynxeye has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
frankbinns1 has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
Adrinael_ has joined #dri-devel
Adrinael_ has quit []
vliaskov has joined #dri-devel
paulk-ter has joined #dri-devel
vliaskov_ has joined #dri-devel
paulk-bis has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
frankbinns2 has quit []
frankbinns has joined #dri-devel
pcercuei has joined #dri-devel
freemin has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
kts has joined #dri-devel
freemin has joined #dri-devel
heat has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
JohnnyonFlame has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
mvlad has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
DottorLeo has joined #dri-devel
ice9 has joined #dri-devel
<DottorLeo>
@karolherbst, i've seen your brach about SPIRV on rusticl, i'm intrigued on the HIP support...could it work also on Blender, now that HIP is the only supported platform for it?
<karolherbst>
DottorLeo: potentially. It's just that HIP also relies on SVM being there
<DottorLeo>
but it will only support what is supported from HIP itself? I mean GFX6,7,8 are not supported by HIP so the shouldn't work on blender even if they are supported by Rusticl+Radeonsi branch
<DottorLeo>
?
<karolherbst>
uhhh... dunno? I mean, why would rusticl be limited by what HIP supports?
<DottorLeo>
Uhm...interesting so "technically" Rusticl+radeonsi should help running HIP applications also on not officially supported cards...if i understand correctly your work on Radeonsi+Rusticl ^^"
<karolherbst>
yeah
<karolherbst>
but HIP is a bit of a mess
<karolherbst>
it kind of depends on how it all works out and what hipsycl is doing under the hood
<karolherbst>
_but_ in theory it just maps on top of CL
<karolherbst>
ehh wait
<karolherbst>
it was "chip-spv"
<DottorLeo>
you know that the entire old radeons (GFX < 9) community will test it in everything hasn't work in the past on official AMD drivers and you will unleash something unexpected? :D
<karolherbst>
probably
<karolherbst>
I mean, there are already people testing it
<karolherbst>
I just have to finally get it all merged
<DottorLeo>
i have a gfx 6,7,8 ready for testing ;D
<karolherbst>
that's all using radeonsi, right?
<DottorLeo>
yeah, but 6 and 7 have experimental support on radeonsi
<DottorLeo>
i have to force it
<karolherbst>
I see
<karolherbst>
one thing I'm not sure of is how it well it would work on GPUs which need relocations
<DottorLeo>
also Gerdie with r600 for computing :D
<karolherbst>
and I don't know which gens those are
<DottorLeo>
last thing...different subject. What will be the minimum GPU needed for using NVK when it will be ready?
<DottorLeo>
Fermi too old?
<karolherbst>
kepler+
<karolherbst>
Fermi might potentially work if somebody puts the effort into it, but quite a lot of stuff would need fermi specific paths
<karolherbst>
where atm a lot of things are just common code across all gens
<karolherbst>
with just a few arch specific paths
<DottorLeo>
nm, it's too old :D i have an old laptop with nvidia 610M that is Fermi 2.0, it might be fun to test it :D
<karolherbst>
uhhh
<karolherbst>
also very slow
<DottorLeo>
yeah ^^" the HD3000 paired with the Sandybridge i think might surpass it
<karolherbst>
yeah.. especially on nouveau without support for reclocking
thellstrom has quit [Quit: thellstrom]
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
thellstrom has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
Terman has joined #dri-devel
DottorLeo has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
andrey-konovalov is now known as Guest1582
Guest1582 is now known as andrey-konovalov
iive has joined #dri-devel
aissen_ has joined #dri-devel
aissen has quit [Ping timeout: 480 seconds]
<jenatali>
dj-death: The "sampler" types in NIR are generally combined image+sampler. The sampler types with no dimension info (called bare sampler) are just a sampler, while "texture" types are sampled images, with separate samplers
<jenatali>
I'm not sure how internally consistent all that is, but we have a lowering pass we use that generates that consistency for GL/VK/CL
aissen_ has quit []
aissen has joined #dri-devel
<dj-death>
jenatali:
<dj-death>
jenatali: thanks, I was pointed out that mutable descriptors don't have to support combined image/sampler
<dj-death>
jenatali: that kind of solved my problem :)
Daanct12 has quit [Remote host closed the connection]
Dr_Who has joined #dri-devel
<jenatali>
Oh ok
itoral has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
nchery is now known as Guest1645
nchery has joined #dri-devel
nchery is now known as Guest1646
nchery has joined #dri-devel
Guest1645 has quit [Ping timeout: 480 seconds]
Guest1646 has quit [Ping timeout: 480 seconds]
nchery is now known as Guest1653
nchery has joined #dri-devel
Guest1653 has quit [Ping timeout: 480 seconds]
nchery is now known as Guest1655
nchery has joined #dri-devel
Guest1655 has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
gouchi has joined #dri-devel
nchery has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
unerlige has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
gekret005 has joined #dri-devel
ngcortes has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
nchery has joined #dri-devel
nchery has quit []
nchery has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
cef has joined #dri-devel
ybogdano has joined #dri-devel
<jekstrand>
dcbaker: So, rust proc macros....
<jekstrand>
dcbaker: I see you added support to meson which is great.
<jekstrand>
dcbaker: There's a bit of a problem, though. IDK how to write them without the syn crate from crates.io. :sob:
<dcbaker>
jekstrand: I know. I'm *trying* to get to the point of having crate support
<dcbaker>
I've just ended up rewriting half of the guts of the meson IR because the layering violations make the code awful, and that rewrites are of course, extremely complicated and hard to review :(
<jekstrand>
:-(
<dcbaker>
then we went and had a 1.0 release, so now I can't regress anything with proper deprecation, which makes the review even more difficult
<jekstrand>
Yeah
<dcbaker>
I think I can land the very first bit of those changes today
<jekstrand>
dcbaker: Do we at least have what we think is a viable path forward?
<dcbaker>
yes
<jekstrand>
\o/
<dcbaker>
I think I have buy in from everyone on what I want to do
<jekstrand>
dcbaker: Do you have a branch with crates working?
<dcbaker>
I have a branch with some very basic stuff working
<jekstrand>
dcbaker: I don't care if the syntax changes out from under me in the next couple months.
<jekstrand>
dcbaker: proc macros is listed as a to-do. Is this proc macros from crates or crates so I can get syn?
<dcbaker>
proc-macros from crates
<jekstrand>
Ok, that's fine
<dcbaker>
basically that's my checklist of "when all of this is done we can take this off drafts"
<jekstrand>
sure
<dcbaker>
oh, I should really send that first patch separately... that's a bug fix. lol
<jekstrand>
Pulled. Time to see if I can make this work. :D
<jekstrand>
dcbaker: Thanks for working on this! You may single-handedly become one of the most important contributors to the rust ecosystem as far as I'm concerned. :D
<jekstrand>
By contributing to meson....
<dcbaker>
lol
<jekstrand>
dcbaker: Ok, so here's the concerning thing.... That was published almost a year ago. :-/
<jekstrand>
Am I going to have crates in 6 months?
<dcbaker>
I hope so. the real blocker is getting the reworks for the core targets in...
<jekstrand>
kk
<dcbaker>
some of the gstreamer folks are interested in this as well
<jekstrand>
Worst case, I guess I can replace my proc macro with some horrible python.
<dcbaker>
maybe I can con one of them into speeding up the reviews...
<dcbaker>
worse case we could hand port the syn crate to meson...
<jekstrand>
I'm hoping to merge NVK and NAK into mesa/main in 6 months or so.
<jekstrand>
Of course, that assumes I get NAK written
<jekstrand>
Anyway, I'm going to see if I can get this up and going
<dcbaker>
\o/
<jekstrand>
dcbaker: Do you have an example .wrap file?
<dcbaker>
for a Rust project? no. It really won't be that much different than the wrap files that are already in the subprojects directory
<FLHerne>
what's NAK?
<dcbaker>
just that the meson overlays would live inthe mesa tree
<dj-death>
Not Another Kompiler?
<jekstrand>
Nvidia Awesome Kompiler
<jekstrand>
dcbaker: Ok, so maybe this works differently than I think.
<dcbaker>
Nir Assembly Kludge?
<jekstrand>
dcbaker: How do I pull in an external crate is the question, I guess.
<jekstrand>
I'm looking through your test cases and it's not jumping out at me as obvious.
<ccr>
will there be ACK too, to complement NAK? :P
<kisak>
Nvidia Awesome Community Kompiler ... all contributions are NACK:
<FLHerne>
ah, to replace the current nvc0 backend?
<ccr>
Advanced Compiler Kit?
<FLHerne>
and in Rust, I see having found the branch
<FLHerne>
very nice
<jekstrand>
dcbaker: I'm seeing a bunch or Cargo.toml files which I guess makes sense if you're invoking cargo.
<dcbaker>
my branch?
<jekstrand>
dcbaker: Your PR
<jekstrand>
Looking at the unit tests
<dcbaker>
Okay, it reads the Cargo.toml files, then converts that into Meson IR and generates a single unified ninja compile
<dcbaker>
to get the files you need you'd run cargo vendor syn, which will fetch the stuff the branch wants
<dcbaker>
eventually I'd liket o get rid of the cargo vendor step
<dcbaker>
but one thing at a time
<dcbaker>
syn has two dependencies, so we could probably just hand wrap that
<airlied>
if you ever feel like vulkan video then someone can debug it :-P
<DavidHeidelberg[m]>
I just rerun the "magic LTO pipeline" today... yields so much nicer runtimes. around ~ 1 minute saving on llvmpipe & lavapipe; virgl-iris-traces ~ 5 minutes; venus-lavapipe ~2 minutes; panfrost t860 x/3 jobs: 10 10 7 -> 7 7 8 min; For CI, could we set some treshold how many times has to "full LTO" pipeline pass to switch it for real testing?
<anholt>
airlied: done
<airlied>
thx!
<jekstrand>
\o/
<dj-death>
jekstrand: do you remember if bounds checking works with nir_address_format_64bit_bounded_global and negative offsets?
<jekstrand>
dj-death: The offset is unsigned currently.
<jekstrand>
dj-death: why?
<dj-death>
because it doesn´t apparently
<jekstrand>
dj-death: I don't see how we could support negative offsets
<jekstrand>
dj-death: Uh, what?!?
<dj-death>
dEQP-VK.robustness.robustness2.bind.notemplate.r32i.unroll.volatile.storage_buffer_dynamic.readwrite.no_fmt_qual.len_256.samples_1.1d.comp I think is an example of that
<jekstrand>
dj-death: It should be doing an unsigned compare which, for negative offsets, should be treated as a very high offset which is OOB.
<jekstrand>
We don't need two comparisons if we treat the offset as unsigned.
<dj-death>
yeah true
<dj-death>
not quite sure how I end up with an address below the base address then :/
<jekstrand>
¯\_(ツ)_/¯
thellstrom1 has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
ybogdano has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
bgs has joined #dri-devel
mbrost has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
ybogdano has joined #dri-devel
<dj-death>
jekstrand: shouldn't we use nir_uge instead of nir_ige ?
<jekstrand>
dj-death: We should. Are we using ige?
<dj-death>
yep
<dj-death>
that's not the only problem it seems
<dj-death>
if you do a -4 offset access with a size of 4, the current comparison also doesn't work
<jekstrand>
right
<jekstrand>
We probably want `assert(size > 0)` and `nir_ult(nir_iadd_imm(addr.z, size - 1), addr.y)`
<jekstrand>
(where nir_channel is used to get .y and .z, of course)
<jekstrand>
dj-death: Hrm... We may want to take alignment into account somehow.
<jekstrand>
dj-death: You could have an offset of -2 and a size of 4
<jekstrand>
That's really annoying!
<dj-death>
yey passing
danvet has quit [Ping timeout: 480 seconds]
<dj-death>
trying to implement a different binding model, I keep finding all kind of corner cases in the anv_apply_pipeline_layout that don't really work
Duke`` has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
<jekstrand>
Yeah...
<jekstrand>
But, hey, we need all those things fixed for NVK anyway. :D
<DavidHeidelberg[m]>
How does changing a number of parallel jobs introduce new failure? :D What is that witchcraft?
psykose has joined #dri-devel
<jekstrand>
It shards different which means different tests run back-to-back. If there are bugs where old data can end up in new contexts, that can mess with results.
<jekstrand>
DavidHeidelberg[m]: ^^
gouchi has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
jekstrand: right, so it's the test or driver issue
<jekstrand>
Likely, yeah.
<jekstrand>
And an annoying one at that
<jekstrand>
DavidHeidelberg[m]: It could also cuase a different set of tests to end up in parallel with each other which, if there are OOM issues can blow things up too.
<jekstrand>
Also, increasing parallel jobs increases liklihood of OOM
<DavidHeidelberg[m]>
jekstrand: we have ZRAM these days
<DavidHeidelberg[m]>
so that would lead more or less to the extreme slowdown of the job
<jekstrand>
dcbaker: Ok, so if I want to pull in syn and its deps, how do I go about that? Some Cargo.toml in mesa/subprojects/syn?
<dcbaker>
with my branch? yeah, you need to put the directories in mesa/subprojects
<jekstrand>
dcbaker: What would that look like?
<jekstrand>
Do I need a wrap to pull it?
<jekstrand>
All the examples I see in your PR are unit tests and they have the .rs files right there (which makes sense for unit tests)
<dcbaker>
with my branch you'd run cargo vendor --no-delete to pull in all of the dependencies initially, and then then you'd use sub = rust.cargo(...), and get a subproject() object. I just tried this out and cargo now does a much better job validating the Cargo.toml than it used to... which is annoying
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
Sure, those commands are great but what do I check into mesa to make it work?
<jekstrand>
dcbaker: A little git repo (or even tarfile) with an example meson project that pulls something from crates.io would be really helpful.
<jekstrand>
dcbaker: I see stuff that lets you define a project with a Cargo.toml in subprojects/ and use it but I don't know how to get from there to crates.io.
<jekstrand>
I'm also a bit nervous about the "let's re-invent cargo" plan but as long as it works for the one dependency I need to pull in, I don't really care too much about the details.
<jekstrand>
Nor do I have a better plan. ¯\_(ツ)_/¯
<jekstrand>
But, yeah, an example of how to pull something from crates.io would be super useful.
jkrzyszt has quit [Ping timeout: 480 seconds]
<dcbaker>
jekstrand: okay. Here's a snipppet https://gitlab.freedesktop.org/-/snippets/7354, that has a fake Cargo.toml for syn, plus the necessary shell commands to run to put the necessary stuff in subprojects/
<dcbaker>
then you can run the normal rust = import('rust'); sub = rust.cargo('syn'); target = library(..., dependencies : sub.get_variable('sub') dance that the cargo subproject thing does
<jekstrand>
dcbaker: So the Cargo.toml goes in the main Mesa folder?
<dcbaker>
yes
<jekstrand>
It's complaining about the [[bin]] section
<dcbaker>
sigh, of course it is :/
<dcbaker>
let me see how hard it would be to just hand wrap these for the moment, and come back to the automatic wrapping...
<jekstrand>
I don't care about having to check in a file or two.
<jekstrand>
Uh oh... I just came up with an evil plan...
<jekstrand>
If I have to, I can do this without a proc macro. I can make a normal macro for declaring my structs. 🤔
<Sachiel>
rewrite meson in rust?
<jekstrand>
That's horrible
<jekstrand>
I'd much rather just have a proc macro. :)
<dcbaker>
Sachiel: why not? What's a 4th implementation of meson?
<jekstrand>
I think. Those are honestly pretty horrible so maybe not....
<karolherbst>
jekstrand: what do you want to pull in?
<jekstrand>
syn, for writing proc macros
<jekstrand>
Because I don't feel like parsing token streams myself
<karolherbst>
fair
<karolherbst>
but yeah.. meson needs to support this sooner or later
<jekstrand>
I think dcbaker probably has it mostly working if he can tell me how to use it. 😅
<karolherbst>
heh
<dcbaker>
jekstrand: It's been a year, I can't really remember what is and isn't working anymore...
<dcbaker>
As an interesting exercise I'll port syn over to meson by hand, which has already turned over some interesting bugs... sigh
vliaskov_ has quit [Remote host closed the connection]
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
heh
jdavies has joined #dri-devel
jdavies is now known as Guest1674
ybogdano has joined #dri-devel
Guest1674 has quit [Remote host closed the connection]
<jekstrand>
dcbaker: Also, that branch is pretty old. Any way you could update on 1.0? I need the dependencies field in rust.bindgen
<jekstrand>
s/field/argument
freemin has quit [Remote host closed the connection]