ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pnowack has quit [Quit: pnowack]
<idr>
Holy smokes.
<idr>
Unless I derped the patch, there are 1,600+ shaders in shader-db that have that pattern.
<imirkin>
probably worth doing a spot-check, in case you didn't do like textureBias(any-immediate) -> texture()...
<imirkin>
[yeah, bias is an implicit arg, but that's harder to show as syntax]
alatiera has quit [Remote host closed the connection]
alatiera has joined #dri-devel
gawin has joined #dri-devel
alatiera is now known as Guest5465
loki_val has joined #dri-devel
<jekstrand>
idr: srsly? *sigh* Writing nir_opt_tex, are we?
crabbedhaloablut has quit [Ping timeout: 480 seconds]
<idr>
Well... I just added a few lines to nir_opt_lower_tex.
<idr>
But, yeah.
<jekstrand>
That probably works. Seems a bit odd, but whatever
<jekstrand>
It could also go in constant folding, TBH
<jekstrand>
There's a few other whacky cases like that in there
<jekstrand>
Like lowering discard_if with an immediate to discard or nothing
<jekstrand>
Seems like an ever so slightly better place to put it, maybe.
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Bennett has quit [Remote host closed the connection]
gawin has quit [Read error: No route to host]
tursulin has quit [Read error: Connection reset by peer]
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<ybogdano>
Ci will be down until tomorrow morning
<daniels>
ybogdano: thanks for the announcement, but please disambiguate it so people know that you're referring to the internal Intel CI and not the upstream Mesa CI
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
pnowack has joined #dri-devel
<alatiera>
looking at the CI
rgallaispou has joined #dri-devel
itoral has joined #dri-devel
rasterman has joined #dri-devel
demarchi has quit [Remote host closed the connection]
tolszak has quit [Ping timeout: 480 seconds]
<MrCooper>
hakzsam: from #freedesktop: alatiera> runner should be back up
<hakzsam>
thanks!
TD-Linux has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
pcercuei has quit [Quit: brb]
rando25892 has quit [Quit: No windows for this server]
pcercuei has joined #dri-devel
demarchi has joined #dri-devel
TD-Linux has joined #dri-devel
rando25892 has joined #dri-devel
gawin has joined #dri-devel
<jani>
I'm looking at the mode_flags member of struct mipi_dsi_device , and wondering about MIPI_DSI_MODE_LPM flag specifically. is the idea that whoever's doing mipi_dsi_dcs_write() for instance would first set or clear that bit in dsi device? no interface for that, just direct bit set or clear?
<jani>
Andrzej Hajda here? or maybe tagr has some idea?`^
<danvet>
tzimmermann, sry missed that you added that doc patch without my ack
<danvet>
I thought I checked
<danvet>
will reply on-list
<tzimmermann>
thanks
mclasen has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<dj-death>
is there a NIR pass out there that combines temporary variables when for instance var_A is used in the first part of the shader and var_B in another part of the shader
<dj-death>
and we could actually just use the same variable all along
<dj-death>
I'm asking in the context of ray queries because they need a bunch of storage associated with them
jkrzyszt has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
<karolherbst>
so, maybe some of you have opinions on this. Using gitlab always comes with the annoying part, that some prefer getting notifications as emails for changes on MRs, but gitlabs notifications are _sooooo_ verbose, I was thinking about, maybe we can make use of CI for that here. So why not having a CI job which diffs the MR changes compared to their base (so rebases won't trigger huge diffs) and just sends out an email if there is such a
<karolherbst>
change inside the commits itself?
<karolherbst>
is there some bot/whatever doing this already?
<pq>
that and diffstat sound nice, but relying on CI to send those out? uh
<karolherbst>
yeah...
<karolherbst>
better ideas?
<pq>
um...
<pq>
I guess sending Gitlab patches to Gitlab upstream is out of the question :-p
<karolherbst>
we could also have a bot polling.... or maybe a bot polling to check if CI actually sent those out or something.....
<karolherbst>
yeah well...
<pq>
wonder if Gitlab API would allow an "external" service to implement that
<karolherbst>
sure
<karolherbst>
mhhh
<gawin>
git hooks could be usable, for example if there's ab/rb in commit
<karolherbst>
there is also a feed, so if the bot subscribes to the relevant projects... it might work
<pq>
gawin, does Gitlab even have git hooks?
<karolherbst>
gawin: it's more about catching changes in force pushes to MRs
<karolherbst>
so I think I'd prefer using webhooks here
<karolherbst>
mhh.. we could even use webhooks for updating patchwork
<karolherbst>
so we don't have to put this into CI either
<karolherbst>
maybe I could even port my MR pipeline commenting stuff into a webhook
camus has quit [Ping timeout: 480 seconds]
<gawin>
not sure how mesa's CI works, but if there was one worker which is building all stuff (and sends binaries to others), then it could be good spot
<gawin>
and dead CI kinda equals "there's nothing new worth checking"
<karolherbst>
gawin: we don't trigger the CI stuff automatically anymore
<karolherbst>
just when assigning to marge
f11f12 has quit [Quit: Leaving]
<gawin>
not even building jobs?
<karolherbst>
just some really simple checks
aissen has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
aissen has joined #dri-devel
vivijim has joined #dri-devel
itoral has quit [Remote host closed the connection]
<danvet>
karolherbst, I have a forever feature request to add git range-diff to gitlab everywhere
<karolherbst>
ahh, cool
<danvet>
with a rebasing feature branch dev approach it's really the thing you want
<danvet>
karolherbst, well emphasis on forever request, no sign of it happening :-(
gawin has quit [Ping timeout: 480 seconds]
<karolherbst>
danvet: :/
nchery has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
pcercuei has joined #dri-devel
Company has joined #dri-devel
macromorgan has joined #dri-devel
jewins has joined #dri-devel
iive has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
<zmike>
ccr: any chance you've been able to get back to the trace enum thing?
kem has joined #dri-devel
<daniels>
karolherbst, gawin: so we do have custom git hooks, and we use those to push to the mirrors, but they need to be fast and reliable since they block pushes
mattrope has joined #dri-devel
Bennett has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<jekstrand>
dj-death: Thanks for looking at sync code!
<dj-death>
no worries
<dj-death>
looks nice
<jekstrand>
:D
<jekstrand>
I'm really pleased with how it turned out in the end.
<dj-death>
I'll do another pass
<jekstrand>
I'd like to eventually make the feature detection more automagic but I'm not sure how to do that yet.
<jekstrand>
Like just give everyone timeline semaphores and automatically expose VK_EXT_external_fence and friends.
fxkamd has joined #dri-devel
<jekstrand>
But, again, not sure how to do that yet.
shashanks has joined #dri-devel
shashank_sharma has joined #dri-devel
shashank_sharma has quit [Remote host closed the connection]
gawin has joined #dri-devel
<ajax>
jekstrand: where do we think we are on crocus/amber/!10557/etc
<jekstrand>
Fedora 35's been out for a few weeks now. Have you gotten any crocus bugs?
sdutt has quit []
sdutt has joined #dri-devel
<ajax>
a few, yes.
<ajax>
the word "crocus" apparently appears in exactly four red hat bugs
<jekstrand>
I think airlied is planning to fix that by implementing vappi. 😂
<jekstrand>
But, also, sounds like some table somewhere that needs updating. Shouldn't be hard.
<jekstrand>
If that's the worst bug you've gotten, that's pretty fantastic, TBH.
<ajax>
well. the combination of fedora 35 and 8+ year old laptop is maybe not all that common yet.
* jekstrand
pulls out an 11-year-old laptop and updates it.
jkrzyszt has quit [Ping timeout: 480 seconds]
<jekstrand>
I guess my feeling says wait until shortly before the 22.0 branch-point and rip i965 out if there's no significant Fedora complaints.
<jekstrand>
But maybe I'm being silly and over-cautious
<gawin>
gallium nine is huge win for these gpus
<jekstrand>
gawin: No one's saying you shouldn't use crocus. :) Just deciding when to burn the bridge behind us.
<gawin>
I kinda think maybe it'd best to have one release with crocus as default (most people don't test crocus with software like kwin)
<gawin>
though it's too late for 21.3
* ajax
wonders how many releases it's been since we started trying to delete classic...
f11f12 has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
<jekstrand>
If ajax's amber project works, the distro can still ship i965 if the want.
gawin has quit [Ping timeout: 480 seconds]
<ajax>
i should probably run through the exercise of packaging amber for fedora to see where the speed bumps are
pnowack has quit [Quit: pnowack]
pnowack has joined #dri-devel
<ajax>
jekstrand: personally i'd say now's as good a time as any, 21.3 is branched and we're probably not getting 21.4
<ajax>
which makes 22.0 a nice bright line for when we dropped classic
<jekstrand>
I think we agree on which release to plan to drop. It's just a question of if we drop now or give ourselves another month or two to collect potential bug reports.
<jekstrand>
Not that I expect that to matter
<jekstrand>
Maybe I'm just too chicken to pull the trigger
<karolherbst>
could that also cause issues or shouldn't I worry about those kind of mistakes?
<zmike>
jenatali: I suspect it would help you too if only you could use it :D
<jenatali>
zmike: Hm? Was there a reason I couldn't use it?
<zmike>
jenatali: yes, #5277
<jenatali>
Oh right :P
<airlied>
karolherbst: so in the drm-fixes-2021-10-15 case I decided the vc4 fixes were too much for Linus at that stage
<jenatali>
I can hook up the caps trivially, I just can't remove the fallback to handle unsupported prims getting into the driver yet until all trifans/quads go through vbuf/cso
<airlied>
so unpulled the misc fixes branch and cherry-pick over the ones I wanted
<karolherbst>
ahhh
<zmike>
hooking up the caps will break your edge flag handling though
<jenatali>
Oh right :(
<zmike>
like I said
<jenatali>
Not sure how much I care, that might be worth taking the regression for now
<zmike>
it's going into mesa/st at some point :)
<zmike>
as for the other state trackers I suppose it's up to you to decide how much you're interested in them
<jenatali>
I think I'm close to actually having time to look at some more of this stuff soon - I'm looking at Minecraft perf and these index buffer readbacks for primconvert are killing us
camus has joined #dri-devel
<zmike>
I had a minecraft ticket I was looking at once upon a time
* zmike
tries to remember what happened to it
<jenatali>
Dunno if they're using dlists, so I dunno if your change specifically would help, but if they are it'd be nice
<zmike>
the dlist change there doesn't hit all old-style vertex cases
<zmike>
I only did it because I'm implementing vertex state draws
<zmike>
which use this
<jenatali>
I see
<zmike>
probably for actual index buffers we'd want something else
<zmike>
not sure what though
<jenatali>
Yeah I need some kind of primconvert cache I think
<zmike>
not sure how that'd work?
<zmike>
it'd still have to read the index buffer back to know what to look up
<zmike>
and that's the slow part
<jenatali>
Not sure either. But I'm seeing index buffer uploads that we then have to read back and that is super slow. If we could just remember what we uploaded it'd save us a ton of work
<jenatali>
All because they're 1-byte indices that we don't support :(
<airlied>
is the readback once per index buffer or repeated?
camus1 has quit [Ping timeout: 480 seconds]
<jenatali>
Pretty sure it's repeated...
<jenatali>
I got far enough to see that's a problem but haven't gotten back to it to figure out how to fix it yet
<zmike>
is it being uploaded from explicit vertex calls or from a vertex buffer?
<zmike>
if it's the former then there's more places in mesa/main where vertex data is handled that can do pre-conversions like my MR
<zmike>
if it's the latter.... 🤔
<airlied>
ajax, jekstrand : oh that va name bug, have to track that down, might be in the X server
<jenatali>
anholt_: Was reported in #freedesktop and I think it's already fixed
<anholt_>
do we know what's been up with it?
<jenatali>
I don't, at least
<HdkR>
Wait, something actually is using 1-byte indices?
<jenatali>
HdkR: I've seen at least 2 apps so far. One of them reached out to me directly and I told them to stop. The other is Minecraft :P
<HdkR>
Wow.
<airlied>
Kayden: you remember how iris dealt with the va library name?
pnowack has quit [Quit: pnowack]
nchery is now known as Guest5538
nchery has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
Guest5538 has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
pnowack has joined #dri-devel
<Kayden>
airlied: nope, not really
<Kayden>
I remember some conversations about iris totally breaking libva and other people not believing that
Bennett has quit [Remote host closed the connection]
<airlied>
ah libva has a driver_name_map
<mareko>
zmike: FYI, you can bind vertex buffers as the vulkan equivalent of TBOs or image buffers, and do additional format conversion in the shader after loads
<mareko>
also 1byte indices could be emulated in the same way and just modify VertexID
<zmike>
this is true, but tbos are kind of a pain to work with given the validity requirements
<mareko>
TBOs have an implicit stride, you'd need something where you can set your own stride
<zmike>
true
<zmike>
still not something I'm urgently looking into until I have a real case that's hitting it
<zmike>
otherwise I'll probably just wait until I can use task+mesh shaders or something
gawin has joined #dri-devel
<mareko>
mesh shaders will raise the hw requirements to RDNA2, which is not great, while vertex shaders could do the same thing
<zmike>
sure, but I'm also just one person, and there's more urgent things I need to do for now :)
<airlied>
zmike: sounds like you need to be running minecraft :-P
<zmike>
I did a few months ago
<zmike>
no problems here
<Sachiel>
time to implement task/mesh shaders with redstone
* zmike
checks stackoverflow
jewins1 has joined #dri-devel
<jenatali>
It works, it's just slower than necessary because of primconvert, at least for me
<jenatali>
Maybe some other features will fix it, I dunno
<karolherbst>
ohhh, Gsoc was opened up to all adults :O
jewins has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<Kayden>
airlied: hmm...yeah...we might need to update that. cue decisions about what order to probe things in, too...
<Kayden>
for the X server I made it use EGL_MESA_query_driver instead of having its own map, but I doubt libva can do that as it probably doesn't egl at all
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<airlied>
Kayden: once we have iris/crocus vaapi it'll all be fine :-P
<mareko>
jenatali: converting ubyte indices to ushort doesn't need primconvert, see how we use util_shorten_ubyte_elts_to_userptr
<jenatali>
mareko: Still requires a pipe_buffer_map though. Same problem regardless which code does it
<mareko>
ideally you would know that the index buffer is idle or used for read only, so that you don't have synchronize with the GPU
<jenatali>
Yeah I think the problem we're seeing is that there's a non-directly-mappable index buffer, so we have a GPU write to it for the indices, and then we need to read it back which requires re-syncing with the GPU to wait for the write to be done
<mareko>
how about primconvert as a compute shader
<jenatali>
I'm onboard :)
<jenatali>
Except I haven't written the compute stack yet for our gallium driver yet
<mareko>
we also don't have the compute shader
<jenatali>
Psh details :P
<jekstrand>
A compute shader for converting ubyte to ushort? I can type the nir_builder for you in 20 minutes.
<jekstrand>
I won't do anything but compile-test it of course, and only if you're lucky. :-P
<jenatali>
Yeah that one would be trivial, the rest of primconvert would be harder, but also immensely useful
<mareko>
some GPUs have ubyte indices like AMD since Volcanic Islands
<jenatali>
Yeah. We'd talked about adding it (back?) to D3D when we looked at adding our gallium backend, but it seemed simple enough to emulate. And it is, it's just these perf gotchas
sdutt has quit []
sdutt has joined #dri-devel
<zmike>
jekstrand: I'm gonna take you up on that next year after my vacation :P
JohnnyonFlame has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<jekstrand>
zmike: :P
<jekstrand>
We've always had UBYTE
ceyusa has quit [Remote host closed the connection]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
<robclark>
jenatali: it would be nice if, once we start detecting primconvert re-writing index buffers, we passed some flag to the driver on resource allocation for index buffers that CPU readback is likely.. minecraft (quad emulation with readback from writecombine bo's isn't great.. a hint that we should switch to cached coherent buffers instead would fix that)
ceyusa has joined #dri-devel
<anholt_>
I think the compute shader solution is the real right way to go, though
<jenatali>
robclark: Yeah. Not sure we can know at allocation time that it's going to be an index buffer that's used with an unsupported index format / prim type though
<jenatali>
Agreed compute is probably the right long-term solution
<jekstrand>
The tricky thing with a CS solution is that you need to be careful that switching between 3D and compute doesn't cause silly stalls.
<bnieuwenhuizen>
DispatchMultiIndirect at the start of your renderpass :)
<jenatali>
Those stalls would still be way better than going all the way back to the CPU
<jekstrand>
If you can batch a bunch of rewrites up into back-to-back compute calls with no barriers between them or, better yet, one compute call, and then do a bunch of drawing, that's best.
<jekstrand>
jenatali: Oh, for sure.
<HdkR>
Big brain move, expose byte indices in D3D
<jekstrand>
All the D3D HW can do them....
<jekstrand>
Or most, anyway
<jenatali>
Yeah...
<jekstrand>
Intel can since about forever
<bnieuwenhuizen>
AMD only since 2016 or so
pcercuei has quit [Quit: dodo]
<bnieuwenhuizen>
er, 2014*
<jekstrand>
bnieuwenhuizen: And since those are the only GPUs people can actually afford these days...
<bnieuwenhuizen>
jekstrand: you'd be surprised. Even your run of the mill Polaris based card from 2016 is marked up 100% or so these days
<jekstrand>
I was looking at CPUs this week, thinking of building a new desktop (mine's a HSW) and dang....
<jekstrand>
If I want something competent, it's looking like a $5k project.
<airlied>
just reuse your old gpu :-P
<bnieuwenhuizen>
how competent? I hear Intel released some pretty cheap CPUs with lots of cores last week
<jekstrand>
bnieuwenhuizen: Yeah, but half those cores are rubbish. :P
<bnieuwenhuizen>
IIRc they were decent at compilation, but would need to find the benchmarkj
<robclark>
jenatali: if game was using quads on frame N, it is probably going to use them on frame N+1.. although I guess maybe you want to consider what percentage of draws are getting re-written
<jekstrand>
I can get a 18-core i9 through the employee purchase program for reasonable.
<bnieuwenhuizen>
oh well, not much sense harping CPUs then
<jenatali>
robclark: Yeah. Or maybe just once it has to be primconverted once, always cache new uploads for that buffer so they can be converted without having to do readback
<jenatali>
Assuming the index buffer's not being generated via compute or something like that
<bnieuwenhuizen>
can you get a GPU for a reasonable price with the same price (maybe an Arc GPU even)
<bnieuwenhuizen>
with the same program*
<jekstrand>
bnieuwenhuizen: Yeah, no. They're not shipping publicly.
<jekstrand>
bnieuwenhuizen: Yes, I can get an 18-core i9 but if you are willing to spend stupid money, threadrippers go up to a lot of cores. :)
<bnieuwenhuizen>
jekstrand: if you're dealing haswell I assume you can wait those few more months
<jekstrand>
heh
<bnieuwenhuizen>
yeah but you'd be paying through the nose for those cores
<jekstrand>
It's true
<jekstrand>
Best bang/$ is probably employee purchase program.
<jekstrand>
I should figure out what they want for a motherboard to go with it.
<bnieuwenhuizen>
also threadripper is getting old :( Zen2 still, no zen3 a year after release and no sight of any zen3 threadrippers anytime soon
<jekstrand>
:-/
<jekstrand>
The i9s aren't exactly new tech either.
<bnieuwenhuizen>
before you know it you can't get GPU limited anymore because the singlethread perf sucks
<bnieuwenhuizen>
though I guess I just need to finish raytracing to deal with that :P