<airlied>
I just put it on the end of my 1.2 enabling series
<airlied>
kusma: did you ever look at dEQP-VK.rasterization.primitives.dynamic_stipple.line_strip_wide,Fail and related stipples fail on lavapipe?
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
jewins has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<tarceri>
gitlab ci is totally borked
<airlied>
yeah registry needs a kick, already reported, just have to wait for admin
camus1 has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
Duke`` has joined #dri-devel
camus has joined #dri-devel
mattrope has quit [Read error: Connection reset by peer]
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
fxkamd has joined #dri-devel
fxkamd has quit []
sdutt has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
kmn has joined #dri-devel
Hi-Angel has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
<mareko>
it looks like Intel ray tracing might be faster than expected, it seems to have the powerful ability to spawn threads
<mareko>
I wonder if this makes Intel RT > AMD
<HdkR>
Sadly we also need to question if Intel will make an HPG class gpu as large as 6900XT/RTX3090
<DPA>
s/DKIM/DMARC/
<airlied>
mareko: I'm sure AMD will be happy to release the hyperoptimised RT kernels :-)
lemonzest has joined #dri-devel
<kusma>
airlied:: I did. It's a CTS bug, and I submitted a fix, but it's just hanging there...
<tpalli>
anholt_ but we need device matching as the event might be happening to another device .. so if you have some guidance how to do it properly, I'm happy to try fixing my MR. Your comment was to remove the whole matching when running on top of drm and I'm ok with that but won't you then get events for any kind of device, even if it does not match the vk device events are being listened for?
<jadahl>
alyssa: if you don't have EDID, and you don't want gnome to say "Unknown", what are you suggesting? without EDID, what is connected really is unknown
<airlied>
kusma: need to dig into whether those are a cts bug or lvp :-P
unsolo has joined #dri-devel
camus has joined #dri-devel
<airlied>
kusma: I'll push on sroland a bit more to see about making the interp by dfeault thing happen
camus1 has quit [Ping timeout: 480 seconds]
<kusma>
airlied:: Good. That change fixing shadow mapping in traces is a good indicator that we need it for GL also.
<kusma>
What llvmpipe is doing here is really far outside of what GL allows for, even if D3D allows it.
<kusma>
The best solution would probably be to do 16 bit filtering instead of 8 bit. That's much closer to what GL specifies (and probably within spec, given the vague wording)
<kusma>
I gave it a honest attempt, but couldn't get it working. It's hairy code to touch.
<airlied>
I think recent GL CTS changes mean we'd have to fix it for GL4.6
<airlied>
since they pulled in some of the GLES tests into the desktop suites
<pq>
company, seems a bit pointless to reply to you, if you're not online to see it. :-/
rasterman has joined #dri-devel
darkapex has joined #dri-devel
pjakobsson_ is now known as pjakobsson
darkapex4 has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
rbrune has joined #dri-devel
lynxeye has joined #dri-devel
tursulin has joined #dri-devel
<pq>
alyssa, we're going to be needing a lot more from EDID once HDR starts being implemented.
thellstrom has joined #dri-devel
<pq>
alyssa, of course, if the EDID does not say it does HDR, then that stuff won't be needed.
* thellstrom
conflict-resolving drm-tip.
<MrCooper>
thellstrom: nice XDC talk about TTM in i915
camus1 has joined #dri-devel
<thellstrom>
Thanks Michel!
camus has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
Company has joined #dri-devel
JohnnyonFlame has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
thellstrom has joined #dri-devel
<thellstrom>
drm-tip conflict resolved.
X-Scale has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<cwabbott>
mareko: I think nvidia also has the ability to dynamically spawn threads, so your occupancy for the dispatch isn't limited by the shader needing the most registers
thellstrom1 has joined #dri-devel
<cwabbott>
AMD just really messed up there, it's perf is gonna be much worse
adjtm has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
thellstrom1 has quit []
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
<mareko>
the question is whether it can spawn threads only in the same SIMD or anywhere in the chip, and whether the register usage has to be the same or can be different
nirmoy has joined #dri-devel
<gawin>
after dropping pregallium drivers is there also a plan to drop tgsi?
<mareko>
dropping tgsi might happen for st/mesa, not so much for other components
pcercuei has quit [Quit: leaving]
<gawin>
yeah, for less active parts like r300 it'd be tricky
<FLHerne>
r600 and nouveau [nvc0 and iirc nv50] both have nir paths in development that mostly work
<FLHerne>
virgl uses TGSI as its transfer format, so that's not going anywhere soon
thellstrom has joined #dri-devel
thellstrom has quit []
thellstrom has joined #dri-devel
<cwabbott>
mareko: intel doesn't really do dynamic register sharing, but they can switch between wave sizes, and since SIMD16 uses the same physical register file for twice as many threads at once as SIMD8 it's kinda similar, and there is support for spawning programs with a different wave size
<mareko>
is SIMD8 twice as fast as SIMD16 similar to how Wave32 and Wave64 work?
Ahuj has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
<cwabbott>
yes, SIMD16 just repeats each instruction twice
<cwabbott>
but SIMD8 programs have access to twice the registers, because values take up two registers in SIMD16
<alyssa>
jadahl: I was assuming it would use the connector name or some KMS property
<alyssa>
(I do have the name from the firmware's lossy parsed version of the EDID)
<alyssa>
pq: delightful.
<pq>
alyssa, both connector names and monitor names can be meaningful. One tracks the connector, the other tracks (poorly, the serial number is better if it exists) the monitor, obviously.
<pq>
if a DE wants to implement heuristics to aid the end user, the end user decides which one is key on re-cabling things.
<alyssa>
Hum, alright
<pq>
alyssa, the fun part is that KMS never had API to expose monitor make/model/serial, it has always been "parse the EDID"
<alyssa>
without EDID, gnome just says "Unknown" regardless of anything else but i digress
<pq>
probably because EDID parsing existed before KMS
<pq>
and the kernel does nothing with those names
<jadahl>
alyssa: maybe the fallback can be changed to "Unknown (DP-42)"
gawin has quit [Ping timeout: 480 seconds]
* alyssa
nods
* jadahl
adds a todo list element
<jadahl>
is this for panfrost?
<alyssa>
panfrost? that's 3D only
<alyssa>
M1
<jadahl>
ah right, panfrost is the 3d only, not the mode setter
<jadahl>
whats the driver here that doesn't expose any edid?
<alyssa>
the M1 display driver I'm writing
Luc has joined #dri-devel
<alyssa>
the firmware parses the EDID and sends back just the subset of interesting properties macOS actually uses, the CPU doesn't touch the raw EDID afaict
<jadahl>
ok (i'm writing down so I know what to muse about in a future commit message)
<alyssa>
the vendor/product/serial are all interesting properties that I do have. but there's no KMS for that, see pq
<alyssa>
synthesizing a fake EDID is a recipe for breakage
<jadahl>
right, only the fancy edid blob
<alyssa>
there /might/ be a way to get at the raw EDID through a side channel. this remains to be seen
camus has joined #dri-devel
<jadahl>
then I guess, unless kms learns about new connector props, is that "Unknown (Connector-42)" thing
<jadahl>
or that
camus1 has quit [Ping timeout: 480 seconds]
<jadahl>
i'll look into it for gnome 42 (no string breakage in 41)
<alyssa>
alrighty
<alyssa>
ideally marcan can just do some voodoo and tell me there's a way to tunnel i2c over a side channel and get the EDID the normal way and not deal with this :_p
Luc has quit [Quit: Page closed]
Luc has joined #dri-devel
gawin has joined #dri-devel
Luc has quit [Quit: Page closed]
itoral has quit []
<alyssa>
dschuermann: gave your shrink vec MR a read
<alyssa>
you don't have to convince me the opts are useful, I've done them myself in a backend
<alyssa>
but frankly, the code in that MR makes me very nervous. there's a ton of it and there are a *lot* of ways things can go subtly wrong
<alyssa>
I'm not sure where we go from here
gawin has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
Peste_Bubonica has joined #dri-devel
iive has joined #dri-devel
gawin has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
Akari has joined #dri-devel
NiksDev has joined #dri-devel
camus has quit []
zackr has quit [Remote host closed the connection]
<cmarcelo>
venemo: in the mesh patch, I need to guard the helper function with a macro since it is only used in assert (that's why the CI was failing). will update that soon.
darkapex1 has joined #dri-devel
darkapex2 has joined #dri-devel
darkapex has quit [Ping timeout: 480 seconds]
<Venemo>
Caio Oliveira: okay
darkapex1 has quit [Ping timeout: 480 seconds]
unsolo has quit [Ping timeout: 480 seconds]
RauLi has joined #dri-devel
camus has joined #dri-devel
zackr has joined #dri-devel
fxkamd has joined #dri-devel
alanc has quit [Remote host closed the connection]
jewins has joined #dri-devel
alanc has joined #dri-devel
sdutt has joined #dri-devel
camus has quit []
camus has joined #dri-devel
RauLi has quit [Ping timeout: 480 seconds]
<dschuermann>
alyssa: that solution is definitely using the hammer
mattrope has joined #dri-devel
RauLi has joined #dri-devel
nirmoy has quit []
Peste_Bubonica has quit [Remote host closed the connection]
RauLi has quit [Ping timeout: 480 seconds]
slattann has quit []
hansg has joined #dri-devel
gouchi has joined #dri-devel
slattann has joined #dri-devel
<alyssa>
dschuermann: nod.
<alyssa>
wait which hammer
kmn has quit [Quit: Leaving.]
<dschuermann>
a full liveness analysis just to remove some components :|
<alyssa>
oh, right
<alyssa>
dschuermann: I mean 100% agreed on not extending the core NIR liveness analysis code, that's just asking for trouble
<alyssa>
It's just..
<alyssa>
I want to see this MR land, I really do, I am just /extremely/ uncomfortable giving it an R-b because I don't see how this doesn't result in subtle breakage down the line
<dschuermann>
subtle like "oh this shader is 90% smaller - neat improvement or just broken"?
<alyssa>
subtle like "we improved nir_validate to catch more bugs and now CI is failing on ACO+Panfrost"
<alyssa>
the MR does a lot of tricky manipulations, some of which (write mask) violate NIR invariants, and it is very hard as a reviewer to reason about that.
<alyssa>
obviously "it passes CI for ACO" is Good but not really enough for something this delicate
<alyssa>
+ if (!((mask >> i) & 0x1))
<alyssa>
...wait, this is just supposed to be `!(mask & BITFIELD_BIT(i))` right?
<alyssa>
er, guess that idiom is already used in this pass
<alyssa>
still super opaque
<alyssa>
(also petition to rename BITFIELD_BIT to BIT like the kernel intensifiess)
<dschuermann>
o_O I never saw this macro before
<dschuermann>
ACO doesn't really hit any of the code. only when I don't lower vec2fp16, and then we only have a couple of shaders
<dschuermann>
but I had some regressions with this approach without the per-component DCE
<alyssa>
few shaders hitting it gives me even less confidence..
<dschuermann>
which NIR invariant is violated in your opinion?
<dschuermann>
I *think* that invariant is broken in more places
<alyssa>
this is not inspiring confidence
sdutt has quit []
sdutt has joined #dri-devel
<cwabbott>
uhh, we definitely shouldn't be breaking that
<alyssa>
dschuermann: well if I got cwabbott interested in this problem I think my job was done, *passes the nerd-baton*
<cwabbott>
it does say "Ignored if dest.is_ssa is true" though
<cwabbott>
what's clear is that it's useless except for registers... so backends must ignore it or nir_validate should check it equals the only sensible thing
<cwabbott>
apparently I assumed the first thing way back when, but then we do initialize it
<alyssa>
nir_validate checking it's 0 would also be sensible, but probably would break some (already broken) backends.
<alyssa>
I think I got this right in my backends but 🤷
<dschuermann>
well, whatever solution. I can make the pass repair the writemask afterwards
Duke`` has joined #dri-devel
<alyssa>
danvet: airlied: Re cursor cropping mess, are The DRM Maintainers™ inherently opposed to the apple KMS driver allocating a shadow framebuffer for cursors and doing a software blit in kernel space to crop planes smaller than 32x32?
<danvet>
alyssa, why not reject cursors smaller than 32x32?
<alyssa>
The benefit of this is that cursor planes will Just Work and I don't need to go fix 5 different compositors and possibly extend the UABI to do the crop in userspace
<alyssa>
The drawback is that, this is ugly as hell.
<danvet>
also cursor faking is pretty standard, but maybe not for real hw :-)
<sven>
sounds par for the course when dealing with M1 drivers :(
<alyssa>
danvet: Right, I already reject cursors smaller than 32x32 but the actual requirement is more sinister: the cropped size has to be min 32x32
<emersion>
compositors in general just allocate with the size you give in the caps
<alyssa>
emersion: ^
<danvet>
alyssa, aw
<danvet>
so at the edges it'll fail?
<alyssa>
right
<alyssa>
If you have a 64x64 cursor, but then have it 3/4 off-screen, to the DCP that's a 16x64 cursor
<alyssa>
and then that'll get clamped up to 32x64 and the cursor will be squashed 2x and not cropped.
<alyssa>
emersion: Same side of the same coin -- width/height for the plane are min 32x32
<emersion>
ah, hm
<alyssa>
AFAIU macOS creates "cursor partially offscreen" framebuffers to make it fit properly.
<alyssa>
I do not know if it does so in user or kernel code.
<jekstrand>
jenatali: Can we assume c11 on Windows?
<jenatali>
jekstrand: I think so
<jekstrand>
jenatali: Trying to decide if I have _Generic()
<alyssa>
Anyway, it's reasonable to enforce LINEAR cursors, and doing the fixup for LINEAR surfaces should be trivial enough. And fast enough since it only happens in edge cases (literally) and only for smallish regions-of-interest.
<alyssa>
But it's still ugly as hell and I don't want to write the code if it's going to be NAK'd on sight.
<jenatali>
I think we need to update the docs for min-spec compilers, but the default in meson.build is already C11
<danvet>
alyssa, so we already have various drivers where cursor just randomly fails
<danvet>
edge is kinda popular
<alyssa>
delightful.
<alyssa>
when I tried rejecting partial-offscreen cursors in atomic_check, Weston hung (IIRC) which seemed like a big "do not do this"
<danvet>
so "fixing compositors to fall back to sw and then retry on next cursor pos" doesn't sound like the dumbest
<emersion>
compositors aren't really prepared for this sadly
<alyssa>
nod. but teaching weston/wlroots/kwin/mutter/Xorg about a strictly inferior solution .... doesn't seem appealing when I can bandaid over in kernel space and get hw accel
mbrost has joined #dri-devel
<alyssa>
(If this is nak'd, the initial merge will be primary planes only. Which isn't a huge deal, I guess.)
slattann has quit [Ping timeout: 480 seconds]
<emersion>
btw, are there any overlay planes on M1?
<alyssa>
emersion: yes, one. but it competes with the cursor plane
<emersion>
competes?
<alyssa>
in effect, there are 2 overlay planes and 0 primary/cursor
<emersion>
ah
<alyssa>
probably will expose as 1 primary/cursor/overlay and reject having more than 2 active at once
<alyssa>
(actually, the DCP advertises 3 or 4 planes but rejects have more than 2 active. It's real fun.)
<alyssa>
(It's an open question whether the cropping issues also apply to overlays. They do with the hw of course, but probably compositors are more prepared for overlays to be randomly rejected.)
<emersion>
yeah you should be able to do pretty much any rstriction with overlays
<alyssa>
(But this hack wouldn't translate so well, because enforcing LINEAR overlay planes would suck!)
<alyssa>
emersion: 👍
dreda has quit []
Ahuj has quit [Ping timeout: 480 seconds]
<vsyrjala>
i know hw people like to take some shortcuts, but that sounds absolutely disgusting
<alyssa>
surprised_pikachu.jpg
dreda has joined #dri-devel
<emersion>
yeah i'm pretty surprised
<emersion>
why can't we have nice things
<alyssa>
emersion: fastest CPU i've ever touched, that's nice.
nctcf^ has joined #dri-devel
<alyssa>
more than willing to put up with KMS nonsense to use a machine that - in powersave, not performance mode - can do llvmpipe at 4K@60 without so much as getting warm.
<alyssa>
(and while simultaneously compiling mesa)
<vsyrjala>
sounds like they should just nuke all the unnecessary extra hw blocks and just add a few more cpu cores
<ajax>
i am extremely ready to not be using an x86 anymore
<alyssa>
vsyrjala: srsly
<alyssa>
there are hw jpeg decoders in this
<alyssa>
butwhy
<bl4ckb0ne>
so apple can see if you're naughty
nchery has joined #dri-devel
<HdkR>
ajax: Good news, you can get yourself an overkill ARM workstation today :P
<alyssa>
HdkR: instructions unclear bought another mac mini
moa is now known as bluebugs
<HdkR>
Mac Mini will definitely be the better choice once Linux is fully fleshed out on it
<alyssa>
excuse me are you suggesting there is something unfleshed about mainline linux + 10kloc of unmerged code to get a subset of peripherals working
gawin has quit [Quit: Konversation terminated!]
<ajax>
i am amused to be reading this on a macbook air from 2010
<alyssa>
for a bunch of years I used linux on a 2013 macbook air. funny to go full circle
<ajax>
which is still a surprisingly nice machine to run fedora on
<ajax>
given that i'm doing all my builds elsewhere anyway...
ngcortes has joined #dri-devel
sukbeom has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
iive has quit []
<cwabbott>
oh lovely, we have two lowerings for pack_32_2x16 into the split version... one in lower_alu_to_scalar and one in nir_lower_packing
<cwabbott>
and somehow freedreno isn't enabling either one
ngcortes has quit [Remote host closed the connection]
<alyssa>
sounds about right
<cwabbott>
ok nvm, i just wasn't handling progress correctly
<cwabbott>
still not great that it's duplicated though
<pq>
alyssa, you said weston hung when you reject part-off-screen cursor. How did you reject it? In atomic test-only or commit-for-real path?
<pq>
alyssa, and weston was saying it uses atomic modesetting, right?
hansg has quit [Quit: Leaving]
<pq>
alyssa, if you do the rejecting in the right place, I think weston should fall back to sw cursor with not even a hickup, IIRC.
<MrCooper>
FWIW, rejecting an attempt to move the cursor partially offscreen probably won't work out well for the legacy cursor ioctls; e.g. older versions of mutter completely stopped using the HW cursor if the legacy ioctl ever returns EINVAL
<pq>
of course, that may not be any consolation with legacy cursor UAPI.
<alyssa>
pq: I think atomic test-only path, but it was a few weeks ago
<cwabbott>
alyssa: i was working on "shader preambles" aka pilot shaders btw
<cwabbott>
hopefully you'll be able to use my thing
<cwabbott>
that is, if it turns out any good on freedreno anyway
<daniels>
MrCooper: yeah, if MoveCursor/SetCursor ever fails, weston will set backend->cursors_are_broken = true, and never use it again
<alyssa>
cwabbott: Ooh, nice nice
<alyssa>
and yes would like to use that on both Mali and AGX
<alyssa>
[Admittedly using it on Mali is... very awkward.]
<alyssa>
this /might/ be fixed in Valhall but I'm not counting on it
<alyssa>
daniels: TBF that's not wrong on M1 😜
idr has quit [Ping timeout: 480 seconds]
<cwabbott>
what's the problem on mali? i thought it was just a straightforward compute shader that writes to the FAURAM buffer
<airlied>
alyssa: the DCP has hw jpeg decoder in it?
<alyssa>
cwabbott: just having to dispatch a dedicated compute job for it
<alyssa>
it's not a problem, it's just annoying
<alyssa>
(C.f. AGX where there's a dedicated slot in the shader record for a pilot shader address, so the cmdstream is ~identical)
<alyssa>
(Consequently, Apple is much more aggressive than Arm about using pilot shaders. As in, Apple will do a pilot shader to save a single ALU instruction iirc.)
<cwabbott>
yeah, on qcom it's just a few magic instructions
<cwabbott>
just emit the sequence, inline the call to the preamble function and you're off to the races
<alyssa>
yeah
<alyssa>
then again if Mali can't bother with indirect draws, why should this be different 🙄
<alyssa>
airlied: no, the M1 does which I just find hilariously vestigial given the workloads M1 is actually built for
<airlied>
alyssa: probably from the iphone side
<alyssa>
yep
<alyssa>
compatible = [jpeg,t8101, jpeg,s5l8920x]
<alyssa>
(from the M1's apple device tree)
<alyssa>
s5l8920x is, like, the 2009 iPhone or something
<alyssa>
Yeah. The processor in the iPhone 3GS, released June 2009. That's how far back that JPEG decoder goes.
<robclark>
iirc there was some work so CrOS would use hw jpg decode (ie for browser).. and that turned out to be useful
<jenatali>
We came very close to adding hardware jpeg decode to D3D a few years back
<HdkR>
How useful is hardware jpeg decode for mjpeg?
<anarsoul>
HdkR: mjpeg is 1 jpeg image per frame
<HdkR>
So 100% useful right? :D
<anarsoul>
yes
<daniels>
needs more J2K
<HdkR>
Perfect, nobody needs these fancy H.265, H.264, HEVC, VP9. mjpeg video is the pinnacle
<ccr>
motion vectors? macroblocks? what are those? we just need RLE and frame delta.
<HdkR>
Can't have macroblocking artifacts without macroblocks :thonk:
<ccr>
:D
<alyssa>
HdkR: we need that new compression from Arm
<alyssa>
it's
<alyssa>
"visually lossless"
<HdkR>
Is that AFBC, DSC, or AFRC? :P
<bnieuwenhuizen>
"new"
<alyssa>
AFRC
<alyssa>
fixed-rate compression, with fixed rate less than 1
<alyssa>
but it's still lossless because you can't tell the difference right?
<HdkR>
Oh, afbc is lossless, I misremembered
<bnieuwenhuizen>
sounds like fun to get passing with CTS
<HdkR>
alyssa: Is their marketing material still jpeg files so you can't see the difference through the jpeg artifacts?
<alyssa>
bnieuwenhuizen: it's for winsys I guess
jkrzyszt_ has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
nsneck has joined #dri-devel
iive has joined #dri-devel
<daniels>
danvet: omg
<daniels>
that is actually really good
<daniels>
jekstrand: and you too
<daniels>
why did we not do this months ago ...
<daniels>
it's all so simple!
<daniels>
it's a suggestion so good it literally broke my watch as well - right as you were saying it, part of it went flying off somehow
ppascher has quit [Ping timeout: 480 seconds]
<danvet>
daniels, I definitely need to convert this into a good meme
<daniels>
for those not at XDC, jekstrand suggested solving GPUs needing userspace synchronisation by using xshmfence (!) to make it work for X11, and danvet suggested solving Vulkan stacks running on dma-fence winsys (which it can't know until well after device initialisation) by sending device_lost, shooting the context, and stashing somewhere persistent that the next context should come up in dma-fence mode ...
<danvet>
well for that binary probably
<danvet>
maybe binary+ mesa version, so they get a chance
<jekstrand>
These are all terrible ideas
<danvet>
perhaps combined with some vk_MESA extension so apps can tell right away what they want at startup
* lynxeye
still not convinced
<jekstrand>
I started my presentation with blame. I probably should have ended with an apology.
<lynxeye>
but maybe drinking helps to make it sound like a good idea
<danvet>
jekstrand, tbh I don't aim for pretty or nice here
<ajax>
trying to decide where exactly "what if x11 but autotools" lies on that loop
<daniels>
ajax: what does that actually ... mean?
<ajax>
i feel like replacing imake with autotools sounds like a shitposty idea at first and then you follow through with it and then decide what if this sucks and we should do something entirely other both for build and for thing-being-built
<ajax>
which is back around to the shitpost you started with
RauLi has joined #dri-devel
<ajax>
this joke sucks, i think
<ajax>
i take it back
<danvet>
there's another one here with the git migration, except we also adopted patches on mailing lists together with git
<daniels>
haha
<daniels>
one massive repo -> 237 individual repos -> one massive repo
<daniels>
je regrette
<danvet>
but yeah the autotools one was also a bit "this great new hell looks lovely"
<danvet>
daniels, almost as good as the js world
<danvet>
except they insist it's better
<daniels>
eh, I still stand behind autotools
<daniels>
nothing's more Here's One Weird Trick Which All Users Absolutely Hate than writing your own build system
<daniels>
the number of times I've nearly smashed my laptop to bits after discovering that a project uses something which sort of looks like ./configure, but does not in fact work like ./configure ...
<danvet>
yeah I guess autotools only looks bad looking at it through meson
<daniels>
time to close my laptop and walk away before I start getting all anti-nostalgic for SSHing into fd.o (the one fd.o machine) to do yet more hand-hacking on RCS files to fix the CVS megarepo
<daniels>
(strange that all the CVS->anything-else conversion tools out there completely choked when trying to import whatever the hell it was we'd ended up with ...)
lynxeye has quit [Quit: Leaving.]
JohnnyonFlame has joined #dri-devel
RauLi has quit []
mlankhorst has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
daniels: what is the problem we're solving with xshmemfence?
<alyssa>
daniels: do you include waf on your One Weird Trick list?
<danvet>
waf?
<daniels>
danvet: 'what if a build system, but not actually a build system'
<alyssa>
daniels: the 'build system' that is copied, not linked/packagaed/invoked/etc, into every user project
<alyssa>
er danvet
<daniels>
alyssa: I do not, but I do include it in my 'it's 7:34pm and I am absolutely taking the hint and going home' list
<bnieuwenhuizen>
that doesn't sound entirely unlike autotools
<alyssa>
daniels: Fair.
<daniels>
bnieuwenhuizen: it's worse in all axes other than being Python rather than a mashup of shell/m4/Make
<bnieuwenhuizen>
daniels: hey I assigned no value judgment, just put out there the fact that most of my configure scripts come with the source
tzimmermann has quit [Quit: Leaving]
ngcortes has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
idr has joined #dri-devel
<ajax>
anyone mind if i fix the namespacing hell around the word "dri2"?
<ajax>
and "dri" generally?
<ajax>
the entire egl swrast path has the word "dri2" all over it and never touches the DRI2 X extension
<zmike>
👍
<anholt_>
making any sense of egl and loader baklava would be welcome.
mlankhorst has joined #dri-devel
<jenatali>
ajax: If/once classic is gone, does that also mean removing arbitrary indirections from frontends to Gallium through DRI methods?
<ajax>
jenatali: i do want to fold a lot of that away, but the blocker is more xserver than classic
<jenatali>
Ah fair
<ajax>
there's code in Xwayland to do almost the right thing there instead, i just need to finish a) making it actually right b) generalizing it to xfree86 so mesa can legitimately say move on
<jenatali>
For my new EGL backend, a bunch of it could be common with DRI if it wasn't for that indirection - probably also plenty of opportunity for re-use with the frontends/wgl code too
<ajax>
i say "i" but if someone wanted to fix that for me i'd not complain
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
gouchi has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
NiksDev_ has quit []
ppascher has joined #dri-devel
<jekstrand>
Woo! More common Vulkan infra
<jekstrand>
Next task: vk_device_report_lost()
<airlied>
time for that list of apps that handle device lost :P
<jekstrand>
Does "#define ASSERT_ALIVE(thing) if ((thing) == VK_ERROR_DEVICE_LOST) abort()" count as handling it?
<jekstrand>
airlied: At least, with ANV's tracking, you can figure out which queue died in your debug_report logs. That's something, I guess.
<airlied>
maybe we should just queue a device lost first up always :-P
sylware has joined #dri-devel
<airlied>
if anyone starts a new spec, the first thing is that on the first draw after open will trigger the equiv of a full reset :-P
<danvet>
seanpaul, for @chromium patches, I'm assuming you'll take care until they got commit rights?
<jekstrand>
airlied: We talked about doing just that during the LPC fence talk today. :)
<danvet>
or anholt_ depending which group it's from I guess
<anholt_>
huh?
sylware has left #dri-devel [#dri-devel]
Net147 has quit [Ping timeout: 480 seconds]
<alyssa>
kernel commit rights sound like a liability
<robclark>
danvet: or dianders (assuming you are talking about pushing to drm-misc?)
<danvet>
robclark, yeah
jkrzyszt_ has joined #dri-devel
Net147 has joined #dri-devel
<dianders>
I can help with some stuff if I was CCed on it. ;-) I've been trying to make sure that I'm giving stuff enough time on the lists before landing it though, unless someone else has also reviewed it or it's urgent.
<alyssa>
dianders: are there rules written down for that stuff?
<danvet>
dianders, it's more stuff that's all reviewed and submitted by @chromium, but submitter doesn't have commit rights
<alyssa>
kernel commit rights sound like a liability >_<
<danvet>
alyssa, well I started this all to get out of it
<danvet>
so yes :-P
<alyssa>
🙈
Net147 has quit [Remote host closed the connection]
<danvet>
git apply-mbox gets really boring after the first 10k merged patches
<danvet>
I should get a prize for stupid for doing it that long
<alyssa>
I guess if DCP driver gets merged I'm liable to get drm-misc commit rights.
<alyssa>
Maybe I shouldn't upstream this thing after all....
<dianders>
danvet: sure, makes sense. ...ones that are all "within chromium" are ones that definitely need sufficient time on the list though. :-) In general I've been trying to telegraph my plans as much as possible by saying that I will plan to commit things after X number of days. ;-)
Net147 has joined #dri-devel
<danvet>
alyssa, you don't have them yet with panfrost?
<danvet>
whomisc says no
<danvet>
daniels, ^^ fix this?
<danvet>
dianders, it's a bit up to judgement, anything between a day or weeks might be right :-)
<danvet>
if you push and there's agony on irc it was too quick
<danvet>
but also if you don't push and peopel are frustrated about how it all drags, it was too slow
<dianders>
danvet: OK, fair enough. If you seem me making the right judgement calls please let me know.
<dianders>
...err, the "wrong" ones. I guess silence = right. :-)
<danvet>
yeah
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
<alyssa>
danvet: I maintain the whole panfrost userspace, but not kernel space
<alyssa>
(kernel, I'm a designated reviewer but historically that's more wearing the hat of "make sure kernel doesn't screw up my userspace" and not because I am inherently concerned about the kernel code)
<alyssa>
that admittedly is changing now that I'm doing more kernel stuff with M1 and getting a lot less scared of Mali kernel as a result