00:00fdobridge_: <energetic_parrot_03598> gfxstrand: is this what you mean by someone needs to implement linear render hacks?
00:00fdobridge_: <gfxstrand> Yup
00:01fdobridge_: <redsheep> I assume you will drop that warning appearing everywhere along with dropping -experimental?
00:01fdobridge_: <redsheep> It's already not true that it's not conformant
00:02fdobridge_: <energetic_parrot_03598> i compile with meson setup build/ -Dllvm=true -Dvulkan-drivers=nouveau-experimental -Dgallium-drivers=nouveau,zink,swrast
00:02fdobridge_: <energetic_parrot_03598> so drop the experimental i will try that
00:03fdobridge_: <gfxstrand> Yes, we will
00:19fdobridge_: <energetic_parrot_03598> RedSheep: i tried it it says ERROR: Options "nouveau" are not in allowed choices: "auto, amd, broadcom, freedreno, intel, intel_hasvk, panfrost, swrast, virtio, imagination-experimental, microsoft-experimental, nouveau-experimental, all"
00:24fdobridge_: <redsheep> Right, because it's still marked as experiemental. I wasn't trying to suggest you can build it without -experimental right now.
00:25fdobridge_: <gfxstrand> @airlied Two things I'd like to figure out in the next two weeks before we drop -experimental:
00:25fdobridge_: <gfxstrand> 1. Get kernel and Mesa bits reviewed for VK_EXT_memory_budget and ReBAR
00:25fdobridge_: <gfxstrand> 2. Figure out a modifiers plan that doesn't scare me to death.
00:25fdobridge_: <gfxstrand> @airlied Two things I'd like to figure out in the next two weeks before we drop -experimental:
00:25fdobridge_: <gfxstrand> 1. Get kernel and Mesa bits reviewed for VK_EXT_memory_budget and ReBAR
00:25fdobridge_: <gfxstrand> 2. Figure out a modifiers plan that doesn't scare me to death. (edited)
00:25fdobridge_: <gfxstrand> @airlied @karolherbst Two things I'd like to figure out in the next two weeks before we drop -experimental:
00:25fdobridge_: <gfxstrand> 1. Get kernel and Mesa bits reviewed for VK_EXT_memory_budget and ReBAR
00:25fdobridge_: <gfxstrand> 2. Figure out a modifiers plan that doesn't scare me to death. (edited)
00:26fdobridge_: <energetic_parrot_03598> soundz like a great plan... hw would i start this linear render hack whats the best place to look at?
00:27fdobridge_: <redsheep> What's the big deal with leaving nvc0 having modifiers anyway? If the only allowed combos are nvc0 and nvk+zink then nvc0 doesn't actually need to change, right? Am I missing something?
00:28fdobridge_: <gfxstrand> There's no way to prevent nvc0+NVK
00:31fdobridge_: <gfxstrand> My current plan for linear modifiers is as follows:
00:31fdobridge_: <gfxstrand> 1. When an image is created with `DRM_FORMAT_MOD_LINEAR`, we also create a shadow image that's tiled. We'll also allocate memory for that image which gets attached to the `VkImage` and isn't part of the normal image binding path.
00:31fdobridge_: <gfxstrand> 2. In `nvk_CmdBeginRendering()`, we bind the tiled image and copy the render area from linear to tiled if `loadOp == VK_ATTACHMENT_LOAD_OP_LOAD`
00:31fdobridge_: <gfxstrand> 3. In `nvk_CmdEndRendering()`, we copy the render area from tiled to linear if `storeOp == VK_ATTACHMENT_STORE_OP_STORE`.
00:31fdobridge_: <gfxstrand> My current plan for linear modifiers is as follows:
00:31fdobridge_: <gfxstrand> 1. When an image is created with `DRM_FORMAT_MOD_LINEAR`, we also create a shadow image that's tiled. We'll also allocate memory for that image which gets attached to the `VkImage` and isn't part of the normal image binding path.
00:31fdobridge_: <gfxstrand> 2. In `nvk_CmdBeginRendering()`, we bind the tiled image and copy the render area from linear to tiled if `loadOp == VK_ATTACHMENT_LOAD_OP_LOAD`
00:31fdobridge_: <gfxstrand> 3. In `nvk_CmdEndRendering()`, we copy the render area from tiled to linear if `storeOp == VK_ATTACHMENT_STORE_OP_STORE`.
00:31fdobridge_: <gfxstrand> We can skip (edited)
00:32fdobridge_: <gfxstrand> My current plan for linear modifiers is as follows:
00:32fdobridge_: <gfxstrand> 1. When an image is created with `DRM_FORMAT_MOD_LINEAR`, we also create a shadow image that's tiled. We'll also allocate memory for that image which gets attached to the `VkImage` and isn't part of the normal image binding path.
00:32fdobridge_: <gfxstrand> 2. In `nvk_CmdBeginRendering()`, we bind the tiled image and copy the render area from linear to tiled if `loadOp == VK_ATTACHMENT_LOAD_OP_LOAD`
00:32fdobridge_: <gfxstrand> 3. In `nvk_CmdEndRendering()`, we copy the render area from tiled to linear if `storeOp == VK_ATTACHMENT_STORE_OP_STORE`.
00:32fdobridge_: <gfxstrand> We can skip the copies if all of the images being rendered are linear and there is no depth/stencil target. (edited)
00:33fdobridge_: <airlied> @gfxstrand the quickest modifiers plan is open the kernel API and have nvk shove the metadata into the kernel for wsi images
00:33fdobridge_: <airlied> everything else is a lot of typing
00:34fdobridge_: <gfxstrand> We can also potentially do the copies as part of `nvk_CmdPipelineBarrier2()` when they transition to/from `QUEUE_FAMILY_FOREIGN` or `IMAGE_LAYOUT_WSI`
00:35fdobridge_: <gfxstrand> Yeah, but then we're stuck doing that forever or we wait a hear and break nouveau GL.
00:35fdobridge_: <gfxstrand> Yeah, but then we're stuck doing that forever or we wait a year and break nouveau GL. (edited)
00:36fdobridge_: <gfxstrand> Also, while that plan works for WSI, I'm not convinced it'll work for a more general modifiers implementation.
00:36fdobridge_: <energetic_parrot_03598> seems well thought out i wonder what the overhead would be performance wise from copying between linear and tiled formats would be
00:36fdobridge_: <gfxstrand> And, to be clear, I don't mean I want to fix it in 2 weeks. I just want a plan that we're all happy with.
00:37fdobridge_: <gfxstrand> 🤷🏻♀️ If we do it with a layout transition, it'll be two copies per frame. If we do it in `Begin/EndRendering`, it'll depend on how many times the client restarts rendering.
00:38fdobridge_: <gfxstrand> In either case, we have pretty decent bandwidth on VRAM so it's really going across PCI that's going to bite us.
00:38fdobridge_: <gfxstrand> I think `Begin/EndRendering` is easier but it's probably less efficient.
00:39fdobridge_: <airlied> @gfxstrand the problem is in order to move the zink plan forward we have to land modifiers now, and if you don't want bug reports then it's kinda hard
00:39fdobridge_: <airlied> like the patches to let nvc0 fallback to loading zink are kinda working
00:39fdobridge_: <gfxstrand> Unfortunately, all the options suck. I'm kinda tempted to burn the old modifiers and just make new ones.
00:40fdobridge_: <gfxstrand> Yeah. Maybe a good plan is to leave modifiers off for WSI by default and let Fedora carry a 1-line patch to re-enable them because it knows the system GL is Zink.
00:41fdobridge_: <gfxstrand> Or maybe we should just not care?
00:41fdobridge_: <gfxstrand> Or maybe we should just not care and make it a distro problem? (edited)
00:42fdobridge_: <airlied> well we have to get all the pieces needed for zink in, tested and working
00:42fdobridge_: <airlied> including the nvc0->zink fallback path
00:42fdobridge_: <gfxstrand> This isn't sounding like a bad plan, TBH.
00:42fdobridge_: <gfxstrand> We could also make it a meson option if you don't want to carry the 1-line patch
00:43fdobridge_: <airlied> I was going to conditionalise the nvc0>zink fallback on nvk being built and > kepler
00:43fdobridge_: <airlied> + and envvar for testing
00:46fdobridge_: <redsheep> With those conditions then that would prevent nvk and nvc0 ever being loaded at the same time, right? As long as somebody would have to carry a patch to make them load together it would be weird for there to be a flood of bug reports
00:46fdobridge_: <airlied> yes except for the time period where we are landing all the pieces
00:46fdobridge_: <karolherbst🐧🦀> I think porting to VM_BIND is probably the best approach here
00:46fdobridge_: <gfxstrand> Or just throw it away and use Zink. 😛
00:47fdobridge_: <karolherbst🐧🦀> I don't want to think about zink and tegra
00:47fdobridge_: <energetic_parrot_03598> zink is the best
00:47fdobridge_: <gfxstrand> Yeah.
00:47fdobridge_: <airlied> pretty sure nvk is already broken on tegra
00:47fdobridge_: <gfxstrand> There's still issues to sort out there
00:54fdobridge_: <karolherbst🐧🦀> I reworked that part of the driver once, shouldn't be terrible to do it another time :ferrisUpsideDown:
00:55fdobridge_: <karolherbst🐧🦀> at least I know what I can break (I think)
00:55fdobridge_: <gfxstrand> And I wouldn't plan on Zink+NVK Volta or earlier yet, either. Maxwell+ might be okay but Kepler would seriously regress right now.
00:55fdobridge_: <karolherbst🐧🦀> yeah..
00:55fdobridge_: <airlied> well zink is still broken for most games anyways
00:56fdobridge_: <airlied> due to whatever depth issue
00:56fdobridge_: <redsheep> Oh yeah on that I have done more testing and I am not even sure that is what it is. I think the actual geometry is getting messed up.
00:57fdobridge_: <redsheep> It looked like depth at first but I spent a good 20 minutes or so playing STK blind and the way the geometry flickers and moves... Doesn't look like triangles that are supposed to exist at any depth.
00:58fdobridge_: <karolherbst🐧🦀> I'll give it a shot and see what I can end up with until the end of the week
00:59fdobridge_: <gfxstrand> I should look into that
01:00fdobridge_: <gfxstrand> What's the easiest game to look at?
01:00fdobridge_: <redsheep> supertuxkart
01:01fdobridge_: <gfxstrand> Oh, well that should be easy enough. 😅
01:01fdobridge_: <mhenning> Does it still happen on main? 27559 fixed some geometry stuff but might not be the same issue
01:02fdobridge_: <redsheep> Yes, I was testing late last night on main with only 27668 on top
01:03fdobridge_: <redsheep> Well, and the other two minor patches from dodonvk that don't touch geometry either
01:07fdobridge_: <mhenning> alright, something else then
01:13fdobridge_: <airlied> okay I've hacked up ajax's suggestion for picking drivers, it's a bit less work
02:38fdobridge_: <gfxstrand> Yeah, vertices are definitely messed up
02:40fdobridge_: <redsheep> Yeah it looks really really weird, the more you stare at it the stranger it is.
02:40fdobridge_: <gfxstrand> One look in RenderDoc already shows Zink issues
02:41fdobridge_: <gfxstrand> A 16B UBO with only 12B bound (that might be okay).
02:41fdobridge_: <gfxstrand> Push constants that aren't pushed
02:46fdobridge_: <gfxstrand> Hrm... Actually, that crazy mesh is a tree. It's fine.
03:04fdobridge_: <gfxstrand> RenderDoc is also faulting like mad. 😩
03:21fdobridge_: <phodius_> ive got skia working on gpu in wayfire well with soreau finishing off the code, but there seems to be a driver bug from using nvidia with nouveau https://youtu.be/Os6bL-1-1Bw any suggestions?:evil_gears:
03:51fdobridge_: <orowith2os> Welp
03:51fdobridge_: <orowith2os> I think I'm just about ready to dive into getting a fuck around and find out GPU
03:51fdobridge_: <orowith2os> And tons of other stuff
03:52fdobridge_: <orowith2os> So all it comes down to is effort
03:53fdobridge_: <orowith2os> Is there a weird kernel branch I need to use to get the best results?
03:53fdobridge_: <orowith2os> What GPU should I snag, looking for something simple but well supported, both now and in the future?
03:53fdobridge_: <orowith2os> Is mesa-git fine for NVK testing now?
03:53fdobridge_: <orowith2os> Any problems I should expect?
03:59fdobridge_: <airlied> okay pushed a reworked zink fallback MR
03:59fdobridge_: <airlied> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27628
03:59fdobridge_: <airlied> doesn't do anything except an env var for now, but sample code to bind on turing and newer is in there commented out
04:00fdobridge_: <redsheep> For kernel drm-misc-fixes has been recommended as being best for testing, but 6.7.5 seems to be working about as well as anything right now, afaik. Anything turing, ampere, or ada is working well enough and have good firmware, so 20/30/40 series. If you are referring to the mesa git aur package that doesn't build with nvk included yet, so use vulkan-nouveau-git and lib32-vulkan-nouveau-git.
04:01fdobridge_: <orowith2os> I just mean mesa-git
04:01fdobridge_: <redsheep> And yeah there are problems kind of all over the place but nothing that completely cripples those gpus running a desktop and basic games
04:01fdobridge_: <orowith2os> Literally built from source
04:01fdobridge_: <orowith2os> I usually build my drivers myself a bunch
04:02fdobridge_: <orowith2os> Comes with the territory of liking to fuck around and find out, and being able to do so without issues via flatpak
04:02fdobridge_: <orowith2os> Is 16xx okay?
04:02fdobridge_: <orowith2os> Is turing afaik, and doesn't have all the expensive bits I'll use in 20+ series; but not sure if there's anything actually different to keep in mind
04:03fdobridge_: <orowith2os> I'm clueless on the Nvidia side of things
04:05fdobridge_: <redsheep> There are several people around here using 16xx cards fine, but if there's ever any interesting testing in the future for raytracing extensions or hacking in dlss support those gpus don't do any of that.
04:09fdobridge_: <phodius_> im on nvidia rtx 2070 mobile
04:09fdobridge_: <orowith2os> Kk
04:09fdobridge_: <redsheep> I suppose in the future if and when dlss becomes possible to run mesa wouldn't have to enforce the same limitation to keep dlss locked out on cards without fast matrix multiply, but I'm sure that would be really bad for performance.
04:10fdobridge_: <orowith2os> Id be likely to just use FSR anyways
04:10fdobridge_: <orowith2os> I know it works, it isn't limited by hardware, and it looks fine
04:10fdobridge_: <orowith2os> Ray tracing isn't a major feature for me either
04:10fdobridge_: <orowith2os> I'm a basic bitch, to put it simply
04:10fdobridge_: <orowith2os> Now to see just *how* to get started
04:11fdobridge_: <orowith2os> Obviously, I'd want to install the relevant mesa-git packages for Fedora and build something matching somewhat for Flatpak
04:11fdobridge_: <orowith2os> Is there a copr containing a drm-misc-fixes kernel anybody uses?
04:23fdobridge_: <airlied> just use the default fedora kernel, if you want bleeding edge just build your own Linus kernel
04:30fdobridge_: <orowith2os> kk
04:30fdobridge_: <orowith2os> I run rawhide anyways, so I'm likely to have new fun stuff anyways
04:38fdobridge_: <orowith2os> atp I might as well just get a 3050 anyways
04:38fdobridge_: <orowith2os> it isn't that much more expensive than a 16 series card
04:38fdobridge_: <orowith2os> barely 50 bucks in some cases
04:38fdobridge_: <orowith2os> lets get this going then
04:42fdobridge_: <redsheep> What price are you seeing? That's kind of an awful card
04:43fdobridge_: <orowith2os> I'm just going on amazon, because laziness
04:43fdobridge_: <orowith2os> 170 for a 16xx card on the higher end (6gb), 240 for a 3050
04:47fdobridge_: <redsheep> The 3060 12GB is almost always worth it and is near the same price https://www.newegg.com/asus-geforce-rtx-3060-dual-rtx3060-o12g-white/p/N82E16814126634
04:48fdobridge_: <redsheep> I wouldn't bother with the 3050, the 16xx cards do the basic job and the 3060 12gb is as low as you can go while getting something that's actually good value
04:48fdobridge_: <redsheep> No point going between the two
04:48fdobridge_: <orowith2os> noted
04:49fdobridge_: <orowith2os> 6GB is right on the limit of where I'd want to be on a GPU anyways
04:49fdobridge_: <orowith2os> 4GB is no-bueno
04:49fdobridge_: <redsheep> Even 8 really sucks these days
04:49fdobridge_: <orowith2os> my 5500xt is toughing it out
04:49fdobridge_: <orowith2os> just don't run unoptimized games at max settings
04:49fdobridge_: <orowith2os> mid does the job
04:49fdobridge_: <orowith2os> unless it's doom
04:49fdobridge_: <orowith2os> but doom runs on everything
04:50fdobridge_: <orowith2os> >now has to get a new motherboard and CPU because of planning to do a dual-GPU setup, but not enough PCIe lanes
04:51fdobridge_: <orowith2os> using an NVME, wifi card, GPU, and a shit ton of other additions will do that to a mf
05:36fdobridge_: <gfxstrand> My primary test card is a 3060 fwiw
05:36fdobridge_: <gfxstrand> 12 GB, I think.
05:42fdobridge_: <airlied> @gfxstrand @zmike. not exposing D24 seems to fix supertuxkart for me
05:42fdobridge_: <gfxstrand> Oh...
05:42fdobridge_: <airlied> which makes some sense since radv doesn't expose it
05:42fdobridge_: <gfxstrand> That's plausible
05:47fdobridge_: <airlied> though I assume zmike has had zink working on nvidia/intel so d24 paths are tested
06:09fdobridge_: <airlied> actually ignore me (yet again) looks like I screwed up and used nvc0
06:26fdobridge_: <airlied> comparing to radv renderdoc, the first draw doesn't appear to update the depth surface at all
14:33fdobridge_: <redsheep> So you two are saying it is actually a depth issue? That's really weird, but I guess if the flickering comes from depth checks sometimes working but usually not then that kind of makes sense.
15:07fdobridge_: <gfxstrand> All I know is that the vertices seem okay according to the RenderDoc mesh viewer
15:09fdobridge_: <gfxstrand> But there are a lot of places where it could all be going sideways
16:59fdobridge_: <orowith2os> AAAAAAAAA
16:59fdobridge_: <orowith2os> why do so many sub-250 dollar 3060s have to be out of stock
16:59fdobridge_: <orowith2os> thankfully I found one
17:04fdobridge_: <gfxstrand> Unfortunately, one of those faults happens reliably when I try to use the VS out from the mesh viewer so, maybe something XFB related?
17:07fdobridge_: <gfxstrand> Debugging this without fault information with GSP sucks
17:09fdobridge_: <gfxstrand> I should swap in my Turing and run without GSP for this
17:55fdobridge_: <gfxstrand> Oh, good. This fault goes away without GSP
17:55fdobridge_: <gfxstrand> Maybe I just found a nice reproducer for @airlied and dakr
18:04fdobridge_: <gfxstrand> https://gitlab.freedesktop.org/drm/nouveau/-/issues/327
18:06fdobridge_: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1209561808197914692/image.png?ex=65e75f37&is=65d4ea37&hm=036b4c13914c9a5bd97818db0b6264fded9cdc3f6af8fdb430e13e9c0f4f82c3&
18:07soreau: what does the gsp fw do in practice, make stuff go faster?
18:07fdobridge_: <gfxstrand> It manages the entire GPU from command submission to scheduling to power management and fan control.
18:08fdobridge_: <gfxstrand> What does it do for users? On Ampere+, it's a hard requirement for HW enabling because we don't have anything else and on Turing+ it gives us competent power management so GPU go brrrr
18:08soreau: I see
18:08fdobridge_: <karolherbst🐧🦀> *Ada
18:08fdobridge_: <karolherbst🐧🦀> Ampere also works with the old firmware, but I think it's buggy for some GPUs
18:09soreau: what is the old fw?
18:09soreau: is it extracted from the blob?
18:11fdobridge_: <karolherbst🐧🦀> nvidia gave it to us
18:11fdobridge_: <mohamexiety> yeah, my 3080 still doesn't like it lol
18:13fdobridge_: <karolherbst🐧🦀> yeah, it's probably not getting fixed anyway
18:16fdobridge_: <gfxstrand> But how?!? The shader is literally just `fmul`, `fadd`, and `ffma` with a little `mufu.sin` thrown in
18:31fdobridge_: <Sid> the attached trace is a 404
18:31fdobridge_: <Sid> because there's a stray ] at the end of the url 😅
18:34fdobridge_: <gfxstrand> Fixed
18:34fdobridge_: <gfxstrand> Looks like constant buffers going awry
18:54fdobridge_: <zmike.> you mean like the ubo issues in https://gitlab.freedesktop.org/mesa/mesa/-/issues/10426
19:07fdobridge_: <mhenning> Could you paste the shader assembly code somewhere? I'm curious.
19:15fdobridge_: <gfxstrand> Maybe? 🤷🏻♀️
19:15fdobridge_: <gfxstrand> Something is also screwed up with this vertex buffer.
19:15fdobridge_: <gfxstrand> I mean, maybe TuxKart is generating VBOs from a compute shader but I doubt it.
19:17fdobridge_: <gfxstrand> @zmike. is Zink using `CmdCopyBuffer()` for vertex buffer uploads or anything crazy like that?
19:19fdobridge_: <gfxstrand> Or maybe instanced rendering is busted? All of the messed up vertex buffers are per-instance
19:21fdobridge_: <zmike.> there are probably some cases where it does host write -> cmdcopybuffer to a vram buffer?
19:24fdobridge_: <zmike.> not sure how crazy that is
19:54fdobridge_: <gfxstrand> Yeah, IDK
20:24fdobridge_: <gfxstrand> Okay, so it's definitely the per-instance VBs and it's always those, even though it's a different buffer per draw
20:25fdobridge_: <gfxstrand> And it's garbage in the buffer, it's not getting mangled by NVK
20:26fdobridge_: <gfxstrand> Things seem to maybe render better if I run with `NVK_DEBUG=zero_memory` but not that much better
20:26fdobridge_: <gfxstrand> Nah, it's the same
20:56fdobridge_: <gfxstrand> Curiouser and curiouser... This buffer appears to be created with `MAP_PERSISTENT` in GL but the memory object in Vulkan is unmappable
20:58fdobridge_: <gfxstrand> Yup! If I switch to my branch that provides a mappable VRAM type, everything works.
20:58fdobridge_: <gfxstrand> @zmike. Looks like you have a memory type selection bug ^^
20:59fdobridge_: <zmike.> 🤔
21:00fdobridge_: <zmike.> seems awfully strange that nvk is the only driver that manages to hit this
21:00fdobridge_: <redsheep> So is the difference that games that render right aren't using instanced geometry? It would be weird if entities aren't instanced in Minecraft but I haven't looked
21:02fdobridge_: <gfxstrand> RADV and ANV both expose mappable VRAM (well, ANV doesn't have VRAM)
21:02fdobridge_: <!DodoNVK (she) 🇱🇹> How stable is that to enable? :cursedgears:
21:03fdobridge_: <zmike.> oh you mean you have no BAR at all?
21:03fdobridge_: <redsheep> That was one of the MRs waiting on kernel patches right?
21:04fdobridge_: <gfxstrand> Not on some GPUs
21:04fdobridge_: <gfxstrand> And it's not currently exposed anywhere. I've got patches but they're waiting on acks from @airlied
21:05fdobridge_: <zmike.> yeah, okay, that's...
21:05fdobridge_: <zmike.> special.
21:05fdobridge_: <gfxstrand> Yeah, on Kepler the maps just don't work at all.
21:06fdobridge_: <airlied> we should probably treat that as a bug 🙂
21:06fdobridge_: <gfxstrand> On Maxwell+, they work but we get GSP OOMs if we try too hard to use them without ReBAR
21:06fdobridge_: <gfxstrand> But it should be trivial for Zink to place MAP_PERSISTENT things in system ram
21:07fdobridge_: <zmike.> let me try a thing
21:11fdobridge_: <airlied> @gfxstrand is the BAR mapping tied up in the memory budget MR?
21:12fdobridge_: <airlied> also some way to reproduce broken kepler without me writing test code would be good
21:12fdobridge_: <zmike.> try
21:12fdobridge_: <zmike.> ```diff
21:12fdobridge_: <zmike.> diff --git a/src/gallium/drivers/zink/zink_resource.c b/src/gallium/drivers/zink/zink_resource.c
21:12fdobridge_: <zmike.> index 62445e2a787..e669f0722ce 100644
21:12fdobridge_: <zmike.> --- a/src/gallium/drivers/zink/zink_resource.c
21:12fdobridge_: <zmike.> +++ b/src/gallium/drivers/zink/zink_resource.c
21:12fdobridge_: <zmike.> @@ -949,6 +949,10 @@ allocate_bo(struct zink_screen *screen, const struct pipe_resource *templ,
21:12fdobridge_: <zmike.> mai.pNext = NULL;
21:12fdobridge_: <zmike.> mai.allocationSize = reqs->size;
21:12fdobridge_: <zmike.> enum zink_heap heap = zink_heap_from_domain_flags(alloc_info->flags, alloc_info->aflags);
21:12fdobridge_: <zmike.> + if (templ->flags & PIPE_RESOURCE_FLAG_MAP_COHERENT) {
21:12fdobridge_: <zmike.> + if (!(vk_domain_from_heap(heap) & VK_MEMORY_PROPERTY_HOST_COHERENT_BIT))
21:12fdobridge_: <zmike.> + heap = zink_heap_from_domain_flags(alloc_info->flags & ~VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, alloc_info->aflags);
21:12fdobridge_: <zmike.> + }
21:12fdobridge_: <zmike.>
21:12fdobridge_: <zmike.> VkMemoryDedicatedAllocateInfo ded_alloc_info = {
21:12fdobridge_: <zmike.> .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO,
21:12fdobridge_: <zmike.> ```
21:15fdobridge_: <gfxstrand> Different MR. It's the one about "more memory types"
21:23fdobridge_: <zmike.> yup fixed
21:23fdobridge_: <zmike.> cool cool cool
21:29fdobridge_: <zmike.> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27707
21:29fdobridge_: <zmike.> I'll leave all the gaming that ensues to whoever's testing in here
21:29fdobridge_: <redsheep> I'll give it a shot in a couple hours
21:30fdobridge_: <zmike.> I only tested with STK but it seemed to work
21:30fdobridge_: <zmike.> will test more tomorrow during calls maybe
21:32fdobridge_: <redsheep> Might be good to rerun your tests to see how many more fails NVK has over radv now, right?
21:35fdobridge_: <zmike.> yeah probably a couple piglit tests will be fixed
21:37fdobridge_: <!DodoNVK (she) 🇱🇹> How long will we have to wait until the "no failures, no flakes, it just passe-" part? :triangle_nvk:
21:39fdobridge_: <zmike.> idk, depends how hard everyone tests
22:11fdobridge_: <zmike.> @gfxstrand nice debugging btw 🤝
22:18fdobridge_: <redsheep> It's possible I messed up somewhere, but unfortunately on my ada GPU supertuxkart looks the very same so far.
22:19fdobridge_: <redsheep> I patched in 27707, was there anything else I needed to do for it to work?
22:19fdobridge_: <zmike.> nope
22:22fdobridge_: <redsheep> I'll try to see if I can confirm my patches applied, there might be multiple bugs in play and what I'm seeing is different
22:26fdobridge_: <redsheep> Hmm. My build looks fine, the imadd patch is working as proven by vkpeak, and I'm applying 27707 exactly the same way. Geometry is still looking pretty wild, but it does look different. It's not flickering in and out of existence now,.it's just crazy and all over the place
22:27fdobridge_: <zmike.> I was just running on zmike/test
22:31fdobridge_: <redsheep> This is what I am seeing now, I will try zmike/test
22:31fdobridge_: <redsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1209628443042386070/Screenshot_20240220_152806.png?ex=65e79d46&is=65d52846&hm=4fdd603fb0b76ca6cf1c2610092b4a804bf2350aabbf74f991f46f646cd9c9a1&
23:00fdobridge_: <gfxstrand> We should see if it fixes any CTS tests, too.
23:00fdobridge_: <gfxstrand> I'll pull and play with it after a while
23:00fdobridge_: <gfxstrand> I'm OOO ATM
23:07fdobridge_: <redsheep> Has anybody else been testing suspend/resume? I have to reboot if I let my PC go to sleep on nouveau
23:11fdobridge_: <redsheep> I'd test with gsp off but I'm on ada so it's not an option
23:11fdobridge_: <gfxstrand> It dies on my fairly often, too.
23:12fdobridge_: <gfxstrand> Which is especially annoying because failed suspends cause my keyboard to stop working. 🙄
23:14fdobridge_: <gfxstrand> And the fix is to boot and then go through a successful suspend cycle.
23:15fdobridge_: <gfxstrand> However, I have disk encryption enabled so booting to the point where I can suspend requires a keyboard.
23:15fdobridge_: <gfxstrand> It dies on me fairly often, too. (edited)
23:15fdobridge_: <gfxstrand> It's awesome
23:17fdobridge_: <redsheep> That's... not ideal
23:25fdobridge_: <zmike.> I suspend constantly
23:55fdobridge_: <redsheep> :cursedgears: Unfortunately zmike/test with no extra patches at all still yields the same result as the screenshot above