<daniels>
mareko, idr: everything is back to normal as of about 40min ago btw
<airlied>
daniels: my https fetch seem to be stalling out
<marex>
seems to work here again, indeed
<airlied>
oh just starting going again now
<marex>
hmmm, can there be stuck fence objects in the kernel after the application finishes ?
<marex>
e.g. cat /sys/kernel/debug/dri/128/gem is growing entries too
FireBurn has joined #dri-devel
<airlied>
daniels: https still seems a bit flaky
Thymo has joined #dri-devel
FireBurnUK has joined #dri-devel
FireBurn has quit []
sdutt has quit [Ping timeout: 480 seconds]
<jenatali>
Yep
fxkamd has quit []
sdutt has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
sdutt has quit []
sdutt has joined #dri-devel
<idr>
daniels: Thanks.
nchery has joined #dri-devel
pnowack has quit [Quit: pnowack]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
LexSfX has quit []
gpuman_ has quit [Remote host closed the connection]
gpuman has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
kevinx has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
ngcortes has quit [Ping timeout: 480 seconds]
nashpa has joined #dri-devel
dliviu has quit [Read error: Connection reset by peer]
<alyssa>
jenatali: !14140 is wrong .. don't know if I should unassign marge
<jenatali>
alyssa: huh. Good catch. Go ahead, I'm not in front of a PC atm
<alyssa>
("Why do you even care about DXIL?" "I was nerdsniped from such an obviously wrong title.")
<jenatali>
I was definitely seeing an inot... I wonder if something is bringing it back
<alyssa>
personally my vote is !14140 and then rip out the algebraic lowering so you don't have to worry about the remat
<jenatali>
Yeah maybe. But I need to debug it either way to see what's up, I'll do that tomorrow
<jenatali>
Thanks for the catch
<alyssa>
mostly because using opt_algebraic for such trivial lowerings feels like using a jackhammer to open a can of soup
<jenatali>
Yeah. Huh was that me? I wonder...
<jenatali>
Vindication, it wasn't me lol
Company has quit [Quit: Leaving]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
shashanks has quit [Remote host closed the connection]
boistordu_old has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
cphealy has quit [Remote host closed the connection]
cphealy has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
cphealy has quit [Remote host closed the connection]
cphealy has joined #dri-devel
camus has joined #dri-devel
kevinx has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
kevinx has joined #dri-devel
<jenatali>
alyssa: Looks like a late optimization is re-materializing it
<jenatali>
Introduced in cb2836164251c9813469345c79a71c222a54f233
i-garrison has quit []
i-garrison has joined #dri-devel
Duke`` has joined #dri-devel
mattrope has quit [Remote host closed the connection]
mbrost_ has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
itoral_ has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
pomwv has joined #dri-devel
pomwv has quit []
itoral has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
shankaru has left #dri-devel [#dri-devel]
gpuman has quit []
alanc has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
alanc has joined #dri-devel
jkrzyszt has joined #dri-devel
milkylainen has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
LexSfX has joined #dri-devel
<MrCooper>
remexre: if the hotplugged display differs only in vertical resolution, you can reserve additional space for fbcon with drm_kms_helper.drm_fbdev_overalloc=<some value over 100> on the kernel command line, then change the fbcon resolution with "fbset -xres <width> -yres <height>" after hotplug
<MrCooper>
marex robclark: FWIW, radeonsi/libdrm_amdgpu have no explicit valgrind instrumentation, but it's still possible for valgrind to catch BO leaks, because the corresponding user space data structures are leaked as well
tzimmermann has joined #dri-devel
tursulin has joined #dri-devel
pnowack has joined #dri-devel
rgallaispou has joined #dri-devel
<marex>
MrCooper: I feel I am still struggling with finding out what exactly is leaking
rgallaispou has quit [Read error: Connection reset by peer]
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
eukara has quit []
JohnnyonFlame has quit [Ping timeout: 480 seconds]
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
<zamundaaa[m]>
On the topic of dmabuf-feedback: how do things look for a Vulkan implementation?
oneforall2 has quit [Quit: Leaving]
pcercuei has quit [Quit: brb]
<kevinx>
mripard:Patch v8 change is little, please help to reivew when you are free, thank you.
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
<mripard>
kevinx: I don't have the time at the moment and am not sure I will have before the end of the year
oneforall2 has joined #dri-devel
<kevinx>
mripard:After mid-January it will be Chinese New Year, maybe i also outoff office. I am worried that upstreaming will be delayed for 1 or 2 mounths again. If all the patches are reviewed ok, what needs to done later?
<marex>
kevinx: that's no problem, I have patches which are trivial and were posted over a year ago and still didn't get applied
<marex>
people seem to be busy
<marex>
sravn: hey, do you happen to be around for lvds bridge topic ? :)
<zamundaaa[m]>
doras: how are amend or async cursors supposed to help with VRR? It's an inherent thing to VRR that you either let the cursor be slowed down by the content, or have the output speed up for the cursor
ppascher has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
mszyprow has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
<zamundaaa[m]>
That's not how amend is supposed to work
mclasen has joined #dri-devel
<zamundaaa[m]>
Amend is "I sent a commit, it's not been presented yet. Before it is presented, change that and that thing"
<zamundaaa[m]>
But yeah, async cursors would help for the LFC case
<zamundaaa[m]>
Or expose the LFC information to the compositor and have it (optionally) do the trick
<mripard>
kevinx: I mean, I'm sorry for that situation but being sorry won't help me have more free time to review your patches
Danct12 has quit [Quit: Quitting]
<zamundaaa[m]>
That is true, sort of
Danct12 has joined #dri-devel
<zamundaaa[m]>
You don't want amend to possibly ruin your display timing
<zamundaaa[m]>
We "just" need async pageflips for AMS
flacks has quit [Quit: Quitter]
<emersion>
i think we're missing half the conversation here
<kevinx>
marex:thanks.
mclasen has quit [Read error: No route to host]
<emersion>
doras, your messages don't show up, if any
mclasen has joined #dri-devel
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
<doras>
emersion: I think I wasn't identified and my messages only showed up in Matrix. Do you see this one?
flacks has joined #dri-devel
<emersion>
doras: yup!
<doras>
Great :)
<kevinx>
mripard:Got it, thanks!
itoral_ has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
Company has joined #dri-devel
<doras>
So I'll quickly fill the gaps: I was asking whether there are any plans to introduce the ability to amend atomic commits for specific planes, so that we could have a better (sane?) VRR experience with cursors. Specifically, I wrote that if we could always amend the cursor's location without affecting VRR timing, we would allow the kernel driver to present an updated cursor location when it hits the minimum VRR refresh rate.
<doras>
Without this ability we have three bad options for cases where we have low FPS situations: either slow down the cursor and create stutter, speed up the display and create jitter or guess when a vblank is going to occur anyway and push an atomic commit that only updates the cursor's location.
gpuman has joined #dri-devel
<doras>
The third option would likely create jitter as well, as we can't reliably guess when the next vblank is going to inevitably occur. So we'd either submit too early or too late for the frame.
<pq>
doras, some kind of flag for "this atomic commit should not trigger a refresh nor be waited on to complete" in KMS might make sense.
<doras>
And then zamundaaa mentioned that 'We "just" need async pageflips for AMS', and I didn't understand what it means. zamundaaa, do you mind elaborating?
<doras>
pq: that was my thought, yes.
<pq>
right, I agree, assuming that the premise holds, which I'm not quite sure of, but maybe makes sense in very low refresh rate situations.
<pq>
the premise being that you do need to update some things like cursor position tentatively ahead of time
<pq>
or just in time
<doras>
Exactly.
<doras>
This is my guess of why async cursor updates in VRR scenarios work well in the legacy modesetting API with low-FPS scenarios. If not that, something similar to it.
<daniels>
is Sascha Hauer on IRC?
<doras>
However, I'm really not familiar with the implementation details so it's just a wild guess.
<doras>
It's unfortunate, but because of this limitation, VRR can only be implemented well with the legacy modesetting API at the moment.
<pq>
doras, I think sending an email to dri-devel@ maling list would be a good action if you don't know of anyone to write a tentative patch.
<mripard>
mlankhorst: thanks
<marex>
daniels: try sha on libera
<doras>
pq: so you're basically suggesting that a complete amend implementation with plane granularity is not necessary for achieving the desired behavior. A simpler "fallback commit" can be used and re-submitted multiple times to be used in case no "normal commit" is submitted in time for the next vblank.
<zamundaaa[m]>
doras: I think your approach is from the wrong side
Danct12 has quit [Quit: Quitting]
<zamundaaa[m]>
We don't need any sort of amend semantics for this
<zamundaaa[m]>
With async the kernel is free to update with LFC, and the latency is lower without VRR, too
<marex>
reliably triggers addition of sync object which is never released, so eventually the kernel runs out of CMA
<doras>
zamundaaa: we have async commits, but we're not allowed to submit more than one commit in a given vblank period, and that commit always affects display timing for VRR purposes.
<zamundaaa[m]>
No, we don't have async with AMS
Danct12 has joined #dri-devel
<zamundaaa[m]>
But I see where the confusion comes from
<zamundaaa[m]>
I'm talking about DRM_MODE_PAGE_FLIP_ASYNC
<daniels>
marex: thanks
<pq>
doras, I have no idea of the kernel internals, I can only think this from userspace point of view, and what userspace does is atomic commits.
<pq>
what's LFC?
<zamundaaa[m]>
Low framerate compensation
<pq>
that's something very specific to AMD, is it not?
<zamundaaa[m]>
No
<zamundaaa[m]>
Displays have a lower limit to their VRR range
<pq>
I know, so the display block must start a refresh cycle on timeout.
<pq>
I didn't know *that* is low framerate *compensation*.
itoral_ has quit [Remote host closed the connection]
<zamundaaa[m]>
It's not
<zamundaaa[m]>
To counter stutter the driver does 2x the userspace refresh rate
<pq>
now that sounds much more familiar
rgallaispou has quit [Remote host closed the connection]
Danct12 has quit [Quit: Quitting]
<pq>
why is it necessary to do LFC to have this async tentative update of cursor planes?
Danct12 has joined #dri-devel
<zamundaaa[m]>
The problem is that with LFC + AMS, cursor updates are unnecessarily slowed down
<zamundaaa[m]>
The desired state is that the cursor position is updated on every one of those multiplied frames
<pq>
ah, so LFC needs this, not this needs LFC, ok.
<zamundaaa[m]>
Yeah
<zamundaaa[m]>
I think that async just solves the problem a lot better than some other new semantics extra for LFC
<vsyrjala>
on intel hw cursors can't do async. only mailbox is possible
<pq>
vsyrjala, mailbox is what we need, async is a misnomer in this discussion.
<zamundaaa[m]>
From the perspective of the compositor it's async
<zamundaaa[m]>
What the hw then does can be different
<pq>
it's hard to pick the right words
<vsyrjala>
fence signalling is totally different between async and mailbox
<pq>
zamundaaa[m], no, async means allow tearing, and compositors still don't want to allow that.
<zamundaaa[m]>
Only for the cursor plane, not for everything
<pq>
yes, for the cursor plane
<zamundaaa[m]>
Legacy does async updates for the cursor plane
<pq>
legacy indeed :-)
<zamundaaa[m]>
Atomic should allow it, too
<pq>
that's why you don't use it
<zamundaaa[m]>
KWin still uses it (or used, until a few days ago)
<zamundaaa[m]>
But you don't see any tearing with legacy
<pq>
because the hardware works as mailbox and not really async?
<zamundaaa[m]>
No, it's definitely async
<zamundaaa[m]>
Or so I've been told
<vsyrjala>
not on intel hw
<emersion>
if you blink at the correct interval you will never see tearing ;)
<pq>
then you must be able to see tearing with luck
<zamundaaa[m]>
Some people asked me why cursor latency is worse with Sway and GNOME than with KWin... It definitely makes a difference.
<pq>
use maximum cursor size, put some vertical stripes on it, and wiggle :-)
<zamundaaa[m]>
I'll try, brb
<vsyrjala>
it's a bit worse than just tearing becuase it's mailbox w/o any fences. so you can even end up presenting your cursor frames in the wrong order
<emersion>
zamundaaa[m]: if the compositor does atomic commits right before vblank, latency should be minimal
<zamundaaa[m]>
I don't notice it in normal use either
<zamundaaa[m]>
But obviously others do. It's not placebo either, they had no clue of the difference in the backend
<zamundaaa[m]>
doras: Amend is not what the async flag does
<emersion>
sway doesn't do atomic as close as possible to vblank by default, you need to configure it
<zamundaaa[m]>
But yeah there needs to be a distinction. In an ideal world I'd want both
<emersion>
GNOME only has it since recently
<zamundaaa[m]>
That could be part of the difference
<emersion>
the only way to know is to do measurements
<doras>
zamundaaa: maybe you're right and I got it the opposite way.
<pq>
zamundaaa[m], amend and async indeed are different. You want amend for cursor updates, but why would you want async when the definition of async is that it is allowed to tear?
<pq>
why is amend not enough?
<zamundaaa[m]>
It depends entirely on how amend is defined
<doras>
Actually, I originally meant what pq just said. So maybe I did get it right :)
<pq>
zamundaaa[m], amend is defined in that link from doras.
<zamundaaa[m]>
Amend could mean that you want to change properties of the last commit, which has not been presented yet. Or it could mean "take over these changes ASAP", which can include more fancy sort-of-async latency reduction measures.
<zamundaaa[m]>
The difference is timing
<zamundaaa[m]>
But I don't know if the more fancy latency reduction measures that I'm thinking of are doable on a lot of, or any hardware
<pq>
It's the first one. And it's not enough to fix the VRR case, where you also want the "do not trigger a refresh from this commit" flag.
<zamundaaa[m]>
Yes, the first one is what I always assume people are talking about
<pq>
Using async instead of amend allows the driver to latch the update in during the active period of scanout, which means it may tear. That's the UAPI definition, which is why a compositor would not want to use async.
<pq>
You might be using async and not see tearing, but async makes no promise of that.
<pq>
The lack of that promise is why I wouldn't use async.
<zamundaaa[m]>
I don't think it would be a problem with cursors. That said, if it's big enough (or has surfaces attached) that's indeed a blocker for async cursors
<pq>
right
<zamundaaa[m]>
So we need something like AMEND, ASAP and ASYNC, all for different use cases. Fun...
kmn has quit [Quit: Leaving.]
<zamundaaa[m]>
ASAP to satisfy the VRR use case without requiring extra flags just for VRR, and allowing drivers to optimize overlay/cursor latency where possible, like if they can update the plane in scanout without tearing. That's only purely hypothetical though, no idea what or if any hw can do that
<zamundaaa[m]>
Or is there a different use case for updating a frame without causing a change in refresh rate with VRR?
mszyprow has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
<doras>
zamundaaa: is ASAP also a flag? If so, I didn't understand the following: "ASAP to satisfy the VRR use case without requiring extra flags just for VRR". It sounds like a VRR-specific flag.
<alyssa>
jenatali: not sure if you have shader-db for dxil, but I'd be curious to see if !14140 makes things better/worse
<jenatali>
We do not
* alyssa
nerdsnipes jenatali
<jenatali>
Also I'm not convinced it entirely matters since DXIL is still an IL that's going to get further optimized
<alyssa>
Yeah, that's fair
<jenatali>
It really just needs to be correct, any optimization beyond that is just gravy
pcercuei has joined #dri-devel
pcercuei has quit []
<zamundaaa[m]>
doras: hw could update a plane when the scanline is not currently crossing the content of that plane. This flag would be a way to expose such capabilities... Though, like I said, It's pretty much hypothetical right now
<zamundaaa[m]>
For cursor updates you'd always use that flag and automatically get the VRR benefit as well.
vivijim has joined #dri-devel
agd5f has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
CME has joined #dri-devel
Haaninjo has joined #dri-devel
CME_ has quit [Ping timeout: 480 seconds]
<MrCooper>
is there any HW / KMS driver where a HW cursor update alone triggers a new scanout cycle with VRR? (genuinely have no idea)
<MrCooper>
if the answer is now, amend alone (with mailbox semantics) seems sufficient
<MrCooper>
*no
<pq>
Isn't hardware going for generic planes? Userspace too? So any plane might be used as a cursor, and the kernel wouldn't know.
<MrCooper>
right; then I guess a separate flag or something is needed to disambiguate whether or not the commit should trigger a new scanout cycle with VRR
<MrCooper>
or could a single "amend, don't trigger scanout cycle" flag suffice?
kevinx has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
That's basically what my ASAP flag would do, but with potential for more
<zamundaaa[m]>
Because I can't think of a reason why you'd want to update the actual non-cursor content but not cause a refresh
sdutt has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
pH5 has quit [Read error: Connection reset by peer]
mattrope has joined #dri-devel
ppascher has joined #dri-devel
JohnnyonFlame has joined #dri-devel
pcercuei has joined #dri-devel
pH5 has joined #dri-devel
<MrCooper>
zamundaaa[m]: pq correctly pointed out that there's fundamentally nothing special about cursor updates in the atomic KMS API, so there needs to be something explicit to disambiguate whether user space wants to trigger a cycle or not
<MrCooper>
(there might be cases where user space wants to trigger a cycle even for "pure cursor updates")
tzimmermann has quit [Quit: Leaving]
<MrCooper>
zamundaaa[m]: one consequence of this is that right now, "pure cursor updates" might trigger a new cycle with some KMS driver / HW setups, but do not with others (e.g. with amdgpu)
Duke`` has joined #dri-devel
mszyprow has joined #dri-devel
<zamundaaa[m]>
MrCooper: I'm aware that the cursor plane isn't really something special, and that it does require new uapi.
<MrCooper>
k good, maybe I misinterpreted something you wrote before
<zamundaaa[m]>
What I'm saying is that the VRR thing could just be a special case of a more generic flag, which has the driver do a pageflip once possible, without interrupting to or adhering to timing of vblanks.
<zamundaaa[m]>
But maybe amend could work for that, too
<zamundaaa[m]>
If the driver can update the content in between of userspace-visible page flips, does that require a new page flip callback? One that is per plane instead of per crtc
<MrCooper>
"do a pageflip once possible" would need to be the default, otherwise all current user space will result in the minimum refresh rate with VRR?
jkrzyszt has quit [Ping timeout: 480 seconds]
<MrCooper>
couldn't "update the content in between of userspace-visible page flips" generate a normal CRTC event?
mbrost has joined #dri-devel
<zamundaaa[m]>
Yes, the new behavior needs to be opt in
<jenatali>
jekstrand: I can't really tell if you're advocating for me to keep a NIR pass or drop the NIR pass. I assume advocating to keep it?
<alyssa>
jenatali: are we still bikeshedding inot
<jenatali>
alyssa: Yep :)
<alyssa>
I'm advocating drop the NIR pass
<alyssa>
For... at least 3 reasons
<jenatali>
I think I'm in the same camp, but I've got at least one pushback from kusma and I can't quite tell jekstrand's position :P
<alyssa>
I believe jekstrand is advocating drop
<alyssa>
but I'm biased
<zamundaaa[m]>
MrCooper: I'm more thinking about the latency reduction idea, where different planes could have their pageflip at different times (in between two vblanks).
<zamundaaa[m]>
But for the VRR case there probably wouldn't be an issue, if userspace opts in then I think it's safe to assume that it'll handle that correctly
<Lynne>
airlied: could you rebase all your vulkan video decode patches somewhere?
<alyssa>
jenatali: 1. more robust, NIR assumes you can do inot so doing the lowering out of NIR prevents this regression from coming back ( jekstrand's argument)
<alyssa>
2. ought to be better code gen, or at least no worse -- there is no optimization you can do with xor -1 that you can't do with inot, and because everyone else does inot, all the nir opts are expressed in terms of inot instead of xor -1 ... if there happens to be an optimization that only works with xor -1, please port it to be inot so every other driver benefits :)
<alyssa>
3. faster, doing an opt_algebraic pass over the IR is expensive, doing that pass in your opt loop means it happens multiple times .. doing it at code gen time is for free
<alyssa>
4. less code, just look at the diff stat for your series
<jenatali>
Yep, those are pretty much the same reasons I had
<jekstrand>
jenatali: I think I'm advocating drop and put it in NIR -> DXIL
<alyssa>
5. more obvious code -- want to know what dxil we generate for inot? look at the ALU emit switch like every other ALU op supported, instead of a random algebraic pass (which jenatali even forgot about!)
<jekstrand>
jenatali: My point was that NIR assumes basically everywhere that it can nir_inot().
<jenatali>
Ok, I thought that's what you were saying but wasn't quite sure
iive has joined #dri-devel
<jekstrand>
Sorry for the confusion
<jenatali>
Thanks. I'll give Erik a bit of time to rebut, but then (assuming I get an ack/r-b for the second patch) I'll go ahead and merge. That Blender crash is pretty unfortunate
<alyssa>
jenatali: Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com> for the series ;-p
<jenatali>
jekstrand: If I have SPIR-V that decorates a struct's members as built-in, but the struct isn't decorated as block... is that valid SPIR-V?
gpuman_ has joined #dri-devel
gpuman has quit [Ping timeout: 480 seconds]
cedric has joined #dri-devel
<jenatali>
vtn generates some unexpected nir for it
<jekstrand>
jenatali: No, it's not valid
<jekstrand>
Pretty sure, anyway
<jekstrand>
Well... not valid in GL/Vulkan
cedric is now known as bluebugs
<jenatali>
I couldn't quite find a validation rule that outlined that, and vtn doesn't output an explicit fail on it, it just... gives you some really weird nir
<jenatali>
I want to at least remove the asserts with line numbers from the spirv2dxil test suite, and it looks like this is the cause for most/all of them
pcercuei has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: Search for "Built-in interface block"
ella-0_ has joined #dri-devel
<jenatali>
jekstrand: In which spec? Not seeing that string in either SPIR-V spec or Vulkan SPIR-V section
gouchi has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
<jekstrand>
It's not in the Vulkan SPIR-V section. It's in the main Vulkan spec
<jekstrand>
And there's not an incredibly good VU for it. :-/
<cmarcelo>
jekstrand: jekstrand: some of those samples will fail for our spirv parser, this is something I'm working to fix.
mszyprow has quit [Ping timeout: 480 seconds]
<alyssa>
Relevantly, the fact that "rasterizer_discard && !xfb" is defined is ridiculous
<alyssa>
Those draws can just be skipped, right..?
<alyssa>
No, the shader might write memory
<alyssa>
Relevantly, the fact that "rasterizer_discard && !writes_memory" is defined is ridiculous
<alyssa>
Those draws can just be skipped, right..?
<jenatali>
cmarcelo: Would you agree that the built-in decoration on members without them being in a block is invalid?
<idr>
jenatali: Did you try running that SPIR-V through the validator?
<jenatali>
Hm...
<jenatali>
No, lemme do that
<idr>
If the validator accepts it, you should probably submit a bug there.
<idr>
You might get some feedback about why they think it's legal.
<jenatali>
idr: Validator does accept it
rcf has quit [Ping timeout: 480 seconds]
<jekstrand>
hrm...
<jekstrand>
We very much agreed that all builtins go together in a block
<jekstrand>
jenatali: What sample is failing?
<jenatali>
I filled an issue on that repo with the name
<jenatali>
Just stepped away from my computer for a bit
rcf has joined #dri-devel
<HdkR>
gitlab repo having some problems being fetched today?
<idr>
Hopefully not still. :(
<idr>
There were problems yesterday, but ssh fetch worked the majority of the time.
<idr>
https was more problematic.
<HdkR>
fetch for me just hanging out with https
<jekstrand>
Yeah, it's been having problems today too
<idr>
Which means the Intel CI will likely be out to lunch. Boo.
<anholt>
it's still out today, there's been activity in #freedesktop debugging it
<idr>
anholt: Happy holidays! #amirite
<HdkR>
Happy Crimbus, take all the servers down :)
* jekstrand
is creating a dozen new MRs since he can't merge the old ones
xantoz has quit [Ping timeout: 481 seconds]
nsneck has joined #dri-devel
<alyssa>
jekstrand: 🤔
pcercuei has joined #dri-devel
i-garrison has quit []
* vsyrjala
feels part of a "you can't see memes on irc" sketch
<airlied>
Lynne: I've rebase my radv-vulkan-video-prelim-decode branch, it's not on main, but it's newer
<airlied>
I'll rebase on main when gitlab gets happy
nsneck has quit []
<airlied>
Lynne: rebasing onto main is a bit of work, will do it next week
mlankhorst has quit [Remote host closed the connection]
<Lynne>
yeah, I know, I tried :)
<Lynne>
was able to keep up for a while with the uvd branch, since it was newer
<Lynne>
incidently, does anyone know how to debug VK_ERROR_DEVICE_LOST issues with RADV, assuming that validation layers are all green?
<Lynne>
unrelated to video decoding, having issues with mapping from DRM images to vulkan
nsneck has joined #dri-devel
<daniels>
HdkR, idr: ssh fetch works, and for the true professionals, you can pull every file via the web UI
<HdkR>
Ouch
<emersion>
i can mail you a paper copy of my source code if you prefer
<dcbaker>
USB-stick by messenger pidgen
<HdkR>
Looks like https eventually went through at this point. Just walked away for an hour :P
<daniels>
if it doesn't start in under 10sec, then kill and retry it. it sometimes works.
<daniels>
(also you can use git://anongit.fd.o/$path, that still works ...)
<daniels>
debugging is assuredly ongoing
* emersion
goes add a `while ! git clone https://…; done` to his READMEs
<daniels>
for FUCK'S sake
<daniels>
it now appears to be working 100% of the time
<daniels>
things which were done to break it: none
<daniels>
things which were done to fix it: spending hours trying to root-cause it, then spending a surprisingly long time installing a painfully complex error-logging stack to aggregate errors and tracing
<daniels>
after enabling that, it ... just works?!
<jenatali>
Gotta love it when simply trying to observe the problem more closely makes it go away
<dcbaker>
race condition
* daniels
smashes his laptop to bits, orders dinner
<emersion>
heinsenbug
<emersion>
gitlab just wanted more attention from his caring sysadmins <3
<cmarcelo>
jenatali: seems invalid to me. strange that spirv-validation doesn't catch it...
<jenatali>
cmarcelo: Yeah, seems there's not an explicit spec line item, and it seems that spirv-val just tries to validate those explicit validation rules
<jenatali>
jekstrand: Should I file an issue on the VK spec registry or do you want to follow up on that?
<jekstrand>
Feel free
* jekstrand
doesn't have to always be the one to file spec bugs
<jenatali>
Okie dokie
<jenatali>
My team has a very interesting relationship with Khronos though, so if someone else is willing, I'm usually happy to not have to engage
<pcercuei>
< daniels> it now appears to be working 100% of the time
<pcercuei>
So it works 100% of the time, most of the times ;)
<jekstrand>
jenatali: I can file it if you don't want to engage