<fdobridge>
<airlied> @marysaka any ideas on emitting nops after hmma opcodes? nvidia seems to do it, but I'm not seeing anything on why
<fdobridge>
<marysaka> I think @karolherbst mentioned that this is needed for scheduling as it can take more cycles than what we can define with one instruction
<fdobridge>
<marysaka> so might be worth checking what the scheduling of those are
<fdobridge>
<airlied> the docs don't seem to mention it, and I've go the correct scheduling in my branch for everything on Turing, but I did notice in the dumps you did the NOPs were there
<fdobridge>
<airlied> oh wait, is there a limit on delays in one instruction?
<fdobridge>
<airlied> do we handle adding NOPs if we get a larger delay
<fdobridge>
<marysaka> I don't think so because it never really happened so far
<fdobridge>
<marysaka> (also uuum this is the zink channel just noticed)
<fdobridge>
<airlied> oops doh!
<fdobridge>
<zmike.> @gfxstrand I have my post all ready to go, just need a link to your post
<fdobridge>
<gfxstrand> I just assigned Marge and told Kara to go post the blog
<fdobridge>
<zmike.> 🔗 🔗 🔗 🔗 🔗
<fdobridge>
<gfxstrand> The Collabora blogging process requires way more manual effort than you'd like to think. It'll be a few minutes.
<fdobridge>
<gfxstrand> What happens if you put a `return;` at the top of `zink_set_damage_region()`?
<fdobridge>
<gfxstrand> Ugh... Firefox won't even start for me on X11
<fdobridge>
<Sid> let's see..
<fdobridge>
<gfxstrand> I think the device select layer got screwed up for me.
<fdobridge>
<gfxstrand> I had too many Vulkan drivers. I have FF now
<fdobridge>
<Sid> that's a flawless experience
<fdobridge>
<gfxstrand> damn...
<fdobridge>
<gfxstrand> What if you comment out the line right after the "we need to flip it" line?
<fdobridge>
<Sid> compiling
<fdobridge>
<gfxstrand> Okay, that seems worse
<fdobridge>
<Sid> hm?
<fdobridge>
<Sid> I meant that I was compiling w/ the change :P
<fdobridge>
<gfxstrand> Oh, I mean I tested and it seems worse
<fdobridge>
<Sid> ah
<fdobridge>
<gfxstrand> Got rid of damage and it's perfect for me
<fdobridge>
<gfxstrand> Ugh...
<fdobridge>
<Sid> can confirm
<fdobridge>
<Sid> this squished cursor is really funny tbh
<fdobridge>
<mhenning> yeah, it's not a bug, it's a feature 😛
<fdobridge>
<Sid> I can help but giggle every time it turns into the text-input-box cursor
<fdobridge>
<Sid> I-beam pointer, I believe it's called
<fdobridge>
<Owo> @gfxstrand have you considered only enabling the NVK+Zink combo for Wayland, since X11 seems to be a pain?
<fdobridge>
<Owo> Or a case to disable damage on X11 if you want to keep it there.
<fdobridge>
<gfxstrand> Let's see if we can just fix the bug. Choosing which to use based on window system is pain
<fdobridge>
<mhenning> Yeah, we don't really want to support both nouveau gl and zink (on the same hardware) in the long term. Ideally we fix the bugs
<fdobridge>
<Owo> Yeah. Still, if it's the easiest in the short-term, I can try hacking something up just so it works? Try n get a Mesa contribution under my belt, even if it's a hack :akipeek:
<fdobridge>
<Owo> Toss in an env var to make it do damage again so that it can still be tested without patching
<fdobridge>
<gfxstrand> Now we watch as the bug reports roll in...
<fdobridge>
<Sid> they started rolling in even before it got merged
<fdobridge>
<Sid> :3
<fdobridge>
<gfxstrand> 😛
<fdobridge>
<gfxstrand> And we appreciate it! 💜
<fdobridge>
<gfxstrand> Am I really downloading the Firefox source code?
<fdobridge>
<gfxstrand> Yes, yes I am...
<fdobridge>
<Owo> Faith, whyyyy
<fdobridge>
<gfxstrand> Because there's a damage bug and it very much looks like it's not ours
<fdobridge>
<Sid> :saigeheart:
<fdobridge>
<redsheep> I guess the bugs gotta get fixed somehow...
<fdobridge>
<Sid> doing all I can to be helpful with whatever limited energy I have left after existing and adulting all day
<fdobridge>
<gfxstrand> mood
<fdobridge>
<Sid> yeah, especially with things in personal life sapping so much of my energy and me contributing in my own free time, it's.. difficult .-.
<fdobridge>
<gfxstrand> ```
<fdobridge>
<gfxstrand> At all times, any client API rendering which falls outside of the damage
<fdobridge>
<gfxstrand> region results in undefined framebuffer contents for the entire framebuffer.
<fdobridge>
<gfxstrand> It is the client's responsibility to ensure that rendering is confined to
<fdobridge>
<gfxstrand> the current damage area.
<fdobridge>
<gfxstrand> ```
<fdobridge>
<gfxstrand> So if returning early from `set_damage()` fixes something then either we screwed up the damage regions somehow or the client is rendering outside of them which is illegal.
<fdobridge>
<gfxstrand> That or there's a crazy zink bug hiding somewhere
<fdobridge>
<gfxstrand> It did look in some of the flickering that it's literally rendering to the wrong spot
<fdobridge>
<Sid> I even had frames showing from login sessions that I had logged out of
<fdobridge>
<Sid> i.e. I could see parts of the wallpaper I've set in plasma in the flickery regions when I logged into i3 (no wallpaper)
<fdobridge>
<mhenning> that sounds like uninitialized memory. you could try seeing if NVK_DEBUG=zero_vram makes any difference
<fdobridge>
<Sid> :neko_salute:
<fdobridge>
<Owo> Shouldn't the kernel be zeroing it anyways?
<fdobridge>
<Owo> :akipeek:
<fdobridge>
<redsheep> Without nouveau being ready to do crazy async page cleaning allocation magic the performance cost is too high
<fdobridge>
<Owo> Rayon to the rescue? :p
<fdobridge>
<Owo> (if someone wants to either write C bindings for it, or rewrite those parts of nouveau in rust)
<fdobridge>
<Owo> Probably overkill. But a thought.
<fdobridge>
<redsheep> That looks like something that would only have to do with cpu side stuff? From what I understand zeroing pages should be happening pretty nearly all on the gpu side, it's just complicated to make the juggle work right
<fdobridge>
<gfxstrand> Yeah, that's just uninitialized memory
<fdobridge>
<gfxstrand> Which FF should also be rendering over since it's getting a buffer age of 0
<fdobridge>
<redsheep> Is this about the cursor, or firefox, or something else?
<fdobridge>
<gfxstrand> firefox
<fdobridge>
<redsheep> Like... it's not actually a firefox bug after all?
<fdobridge>
<redsheep> :headache:
<fdobridge>
<gfxstrand> The problem is that there's a race inherent in X11 when a window is initially created where they always start off as 1x1 and then someone changes the size to whatever. We, as Mesa, have no idea what the size of the X window is so we have to query the X server for it. If we loose the race, we get 1x1 instead of the actual size. Normally this is kinda okay because we re-query as part of present and, if it's wrong, we adjust so we're only ever wr
<fdobridge>
<karolherbst> maybe just query over and over again if it's 1x1?
<fdobridge>
<karolherbst> like....
<fdobridge>
<karolherbst> not sure how many real world applications would use 1x1 windows in X...... who am I kidding, I'm sure applications are doing it for real for weirdo hacks
<fdobridge>
<redsheep> That sounds like something I would expect that to go away when I resize as well, but I have had it continue after resizing...
<fdobridge>
<gfxstrand> That's because kopper never queries it again
<fdobridge>
<karolherbst> trusting the x server? bold
<fdobridge>
<gfxstrand> Kopper has lots of "We don't actually need this code. We're Kopper." paths.
<fdobridge>
<zmike.> It's supposed to get that info from SUBOPTIMAL acquire/present returns
<fdobridge>
<zmike.> Which trigger surface reinit
<fdobridge>
<zmike.> It's funny because the ticket mentions this error is printed on startup, though typically that only happens from manual resize
<fdobridge>
<gfxstrand> Yes, and we re-init just fine
<fdobridge>
<gfxstrand> We just don't update surf->Width/Height