00:17fdobridge: <airlied> so I think HOST reads the pushbufs from the BAR mapping so we can't just go around evicting stuff like nouveau does
00:29fdobridge: <airlied> which seems strange, so must be something else like a dma or somethign
07:06fdobridge: <airlied> @gfxstrand care to give https://paste.centos.org/view/c261b46e
07:07fdobridge: <airlied> it's the first interesting thing I've found that might be an actual cause
07:22airlied: dakr: https://lore.kernel.org/dri-devel/20240311072037.287905-1-airlied@gmail.com/T/#u can we get that into drm-misc-next-fixes asap (and once you review it)
08:50fdobridge: <redsheep> Hmm. So I switched to the open nvidia driver for a bit for testing and when I switched back I have some bizarre results. My 4k120 DP monitor now loaded up at 120 hz. Maybe that's just due to updating to 6.8 proper if you guys have touched that, but it's weird
08:52fdobridge: <redsheep> What's much much weirder though is that my HDMI 4k120 TV *also* now shows a 120hz mode. I can confirm in the OSD that it's getting a 4k120 signal, and I can see from the cursor on that display that it's just as smooth as I would expect, however aside from the cursor that screen is completely black
08:53fdobridge: <redsheep> I am not sure how even that much is possible unless y'all secretly implemented support for HDMI FRL, or maybe my GSP firmware didn't completely reset and has it stuck toggled on? Makes no sense.
08:55fdobridge: <redsheep> @karolherbst I know you mentioned that implementing FRL might be on your list, and I think the weirdness above probably confirms that it's very very close to working.
08:56fdobridge: <karolherbst🐧🦀> nah... I'm sure it's still doing 2.0 but like... weird
08:56fdobridge: <karolherbst🐧🦀> maybe
08:56fdobridge: <karolherbst🐧🦀> though dunno
08:56fdobridge: <karolherbst🐧🦀> I'm kinda planning to take a look later
08:56fdobridge: <redsheep> I don't see how that would be possible, the OSD confirms the bit depth and framerate, and I can see the cursor is nice and sharp
08:58fdobridge: <redsheep> And I don't think you can even do DSC with TDMS, even aside from whether that is possible with this display which from what I understand, it isn't.
08:58fdobridge: <karolherbst🐧🦀> you can always drop the bpc
08:58fdobridge: <redsheep> Right but the display tells it is 8bit as expected
08:58fdobridge: <karolherbst🐧🦀> though I don't know if we do that for HDMI...
08:58fdobridge: <redsheep> I have confirmed that field is accurate when using 10 bit on windows
08:59fdobridge: <karolherbst🐧🦀> mhh
08:59fdobridge: <redsheep> Let me see if I can get the debug info to show me more
08:59fdobridge: <karolherbst🐧🦀> yeah...
08:59fdobridge: <karolherbst🐧🦀> you should boot with drm.debug=.. uhhh...
08:59fdobridge: <karolherbst🐧🦀> 0x4? 0x6? I have no idea 🙂
09:00fdobridge: <karolherbst🐧🦀> actually you can change it at runtime
09:00fdobridge: <redsheep> I mean that LG tvs can tell you debug info from their side, I am trying to find how
09:08fdobridge: <redsheep> They moved it in recent firmware so I had to explore a little, if your TV is LG it is General > Channels > hover Channel Tuning and spam 1 on the remote. I am seeing it confirms I have 3840x2160P @ 120Hz RGB 8bit
09:08fdobridge: <redsheep> It also shows me I have an FRL link where including the vsync and hsync I am at 4400x2250
09:08fdobridge: <karolherbst🐧🦀> mhhhh
09:08fdobridge: <karolherbst🐧🦀> interesting
09:08fdobridge: <karolherbst🐧🦀> and that's on nouveua?
09:08fdobridge: <karolherbst🐧🦀> *nouveau
09:09fdobridge: <redsheep> Yep
09:09fdobridge: <karolherbst🐧🦀> but only the cursor shows?
09:09fdobridge: <karolherbst🐧🦀> but yeah.. this might be a trivial fix
09:10fdobridge: <redsheep> Just confirmed in lspci, loaded module is nouveau
09:10fdobridge: <redsheep> Yeah, just cursor
09:10fdobridge: <karolherbst🐧🦀> I can imagine that we get bandwidth limits from GSP and just ack the modelines, but then don't actually handle allocating buffers correctly or put the GPU into the correct mode? I don't know 🙂
09:10fdobridge: <karolherbst🐧🦀> @redsheep does this happen on a fresh boot?
09:11fdobridge: <karolherbst🐧🦀> but maybe 6.8 landed some 2.1 stuff? I have no idea 🙂 but intel does support 2.1
09:11fdobridge: <karolherbst🐧🦀> it just doesn't really appear on the kernel level
09:11fdobridge: <redsheep> I will try shutting down cold so there's no chance the gsp lives, one sec
09:15fdobridge: <redsheep> Oh weird, I didn't actually expect cold boot to work. Yeah I still have an FRL connection.
09:16fdobridge: <redsheep> Aside from just being a cursor it just works
09:17fdobridge: <redsheep> Maybe the Nvidia drivers left some config on my system that gets me further here but still this should mean this is really close to functional
09:19fdobridge: <redsheep> Would any of the debug info from there still be helpful?
09:22fdobridge: <redsheep> It even successfully switches modes down to 100 hz and the display picks it up. This is crazy close to working.
09:23fdobridge: <karolherbst🐧🦀> so 100 hz works?
09:23fdobridge: <karolherbst🐧🦀> or just it gets listed
09:23fdobridge: <redsheep> Still black. Switching down to 60 doesn't get it to start rendering but does down to tdms
09:24fdobridge: <karolherbst🐧🦀> so with 60 it's still broken? 😄
09:24fdobridge: <karolherbst🐧🦀> mhhh
09:24fdobridge: <karolherbst🐧🦀> I wonder if you just run into weirdo kernel bugs
09:25fdobridge: <karolherbst🐧🦀> any errors in `dmesg` or so?
09:25fdobridge: <redsheep> Oh. Yeah 60 works on the login screen but goes to black as soon as I'm in my session... Wtf?
09:25fdobridge: <karolherbst🐧🦀> maybe you are running into a different bug? 😄
09:25fdobridge: <karolherbst🐧🦀> and it already works
09:30fdobridge: <karolherbst🐧🦀> I guess your gl driver is screwed up or something
09:31fdobridge: <redsheep> I have no idea what's happening to my system now lol... I had been trying x11 and I thought I'd switch to see if it was just cursed x things but the Wayland session locked up my machine
09:31fdobridge: <karolherbst🐧🦀> you might have to purge nvidia for real
09:31fdobridge: <karolherbst🐧🦀> or check the kernel logs
09:32fdobridge: <redsheep> I'll double check it's gone, and yeah I'll go back through logs and see if it mentions anything
09:36fdobridge: <redsheep> ... I have no Nvidia packages, and yet on closer inspection lspci says kmd in use Nvidia but module nouveau 🤦
09:36fdobridge: <redsheep> My package manager should have fixed this for me
09:38fdobridge: <airlied> @gfxstrand seems to make it through a cts run here, so hopefully works for you
09:38fdobridge: <redsheep> How did I even get this far on Nvidia's kernel but otherwise nouveau?
09:43fdobridge: <redsheep> Ah, alright I fixed that loading and the faster modes are all gone again 😞
10:01fdobridge: <karolherbst🐧🦀> @airlied have you seen GSP errors like those? https://gitlab.freedesktop.org/drm/nouveau/-/issues/321
10:02fdobridge: <airlied> Ah yeah need to comment that our
10:02fdobridge: <karolherbst🐧🦀> appears something to be wonky on AMD+Nvidia ssytems
10:02fdobridge: <airlied> It's just display port auxch timeouts
10:02fdobridge: <karolherbst🐧🦀> ohh.. it's just an error in the console and everything works?
10:02fdobridge: <airlied> Should do with 0xffff ones
10:03fdobridge: <karolherbst🐧🦀> okay
10:03fdobridge: <karolherbst🐧🦀> yeah, then we should remove that message so users won't keep filing bugs for this 😄
10:20fdobridge: <airlied> Yeah I'm pretty sure it's just pointless reporting, but I should play around a bit and maybe Lyude will have some ideas later, I should probably dump the auxch transactions
10:43Sid127: god it's so weird
10:43Sid127: physics counts from 1
10:43Sid127: computers count from 0
10:43Sid127: my head hurts
10:45Sid127: doesn't help that I'm sick
10:46fdobridge: <redsheep> Speaking of heads hurting, I decided to skim all of the code in nvidia's open driver for implementing FRL and uh... Yeah I hadn't quite seen some of the places that was being mentioned. There are actually 1330 references to it, and a few hundred lines of code it touches.
10:48fdobridge: <redsheep> Though, their version is mostly so complicated because it's all wrapped up with supporting 10 and 12 bpc, DSC, gpu virtualization, and DP to HDMI FRL adapters that are both extremely rare and borderline useless given NVIDIA hasn't implemented DP 2.1 to offer high enough speed for those adapters to do much.
10:50fdobridge: <redsheep> In reality there's only a few dozen bits being set on the hardware across all of that. Still, it would probably wouldn't make sense to bother without doing DSC and higher bpc modes at the same time.
10:53fdobridge: <redsheep> You could probably do a really hacky implementation with only a few new lines in nouveau but doing it right involves probably about half the work involved in implementing an entirely new connector...
10:56transmittingsense: https://github.com/lszeremeta/mizgra/tree/main?tab=MIT-1-ov-file#readme there are many others but this suites , license mentions nothing about derived works, and output of the generator may or may not be derived work, but it's not the software that generates it in any way, so they do not specify this, public domain oportunity in other words.
10:57transmittingsense: opportunity, so we have the needed sw
11:11transmittingsense: but i left the compressor and have another link translating to scala from rdf too, last not sure how they get from llvm in other means from javascript and rdf html, so scala is not that needed either. I have done little typescript and javascript before on electron engine, they have aot or jit and asar archives, java has similar archives, prolly scala too.
11:12transmittingsense: so i actually expect that i already have every needed solution.
11:18transmittingsense: even though those software could exist for passive incomes, i do not think anyone operates this way as giving others money, so i had done it before as well tbh. it was not serving me well , outcomes were not good , it's better when people get paid if they earned it by their genius activity instead.
11:29transmittingsense: i also tried my luck on scam looking business that offered compute technology with bread price, and they delivered socks expectedly enough, but i got medium good hardware in my box in stacks that are very good, and in general technology is manufactured with very good prices even if not so low as at facebook scams they work at very high manufacturing throughputs and there is nothing wrong, i still get slightly older hw with very good
11:29transmittingsense: prices and can collect some to buy more modern ones, which normally i am not interested in though.
11:30transmittingsense: so me i have not seen problems for long as to why they terror me alike all should be very well done in world.
11:30fdobridge:<Sid> is confused...
11:47transmittingsense: having not graduated from local universities which are not at the highest ranks not even among 500first universities in the world in technical era is not anyways stopping me, since anyways all top ranked ones worth of something are located in america or central europe, Berkley Stanford and Massachusetts are first three incorrect order but it's because they maintained and started all the world wide web. It does not bother me they do so
11:47transmittingsense: good work too tbh.
11:49transmittingsense: they are not so arrogant at all, it's just they do not acredit such papers cause they do more.
12:01transmittingsense: chicago and illinois are high ranks, there were criminal gangs fighting with legal forces too, so FBI and just beat those gangs, and they have lots of skills to tap people hence in addition to very high standards at their university camps.
12:03fdobridge: <Sid> right....
12:08juri_: this is just going to continue to be a problem.
12:09karolherbst: yeah.. and I have no idea what to actually do about it.. maybe somebody has contact to the family? airlied?
12:09karolherbst: I know that somebody did in the past
12:12Sid127: the family?
12:12karolherbst: yeah well.. they have relatives
12:12karolherbst: I think somebody spoke with the sister once
12:12Sid127: huh
12:13karolherbst: I mean.. what do you think where they came from? out of thin air? :P
12:13Sid127: ...I still think we should preemptively ban connections from TOR and VPNs, but I dunno the full story
12:13karolherbst: person with a damaged brain
12:13karolherbst: would be the tldr
12:13Sid127: just G line and ask to reconnect without vpn
12:13karolherbst: if we ban TOR and VPN they just create accounts and reconnect
12:13Sid127: I see...
12:13karolherbst: it's really pointless to block anything there unless we block like.. a lot
12:14karolherbst: like.. VPN/TOR and entire countries
12:14Sid127: abandon #nouveau, move to #nvk? :D
12:14karolherbst: and then there might be VPNs we haven't blocked
12:14karolherbst: they hop into other channels as well
12:14karolherbst: like any drm/mesa related ones
12:15Sid127: what about making a LiberaChat#nouveau
12:16karolherbst: I mean.. they managed to move from freenode to oftc
12:16Sid127: hmmm :\
12:17Sid127: so it's just one person?
12:17karolherbst: yeah
12:18Sid127: ...impressive
12:18karolherbst: well.. persons like that exists everywhere
12:19Sid127: I guess
13:06fdobridge: <karolherbst🐧🦀> @redsheep yeah.. I don't suspect I'll need more than a day to support FLR... ohh wait uhhh...
13:06fdobridge: <karolherbst🐧🦀> uhhh...
13:06fdobridge: <karolherbst🐧🦀> I don't have an nvidia GPU with HDMI 2.1...
13:06fdobridge: <redsheep> You don't have an ampere or ada?
13:06fdobridge: <karolherbst🐧🦀> I do have an ampere and an ada
13:07fdobridge: <karolherbst🐧🦀> they are just DP only
13:07fdobridge: <karolherbst🐧🦀> mhh actually...
13:07fdobridge: <karolherbst🐧🦀> I might have to check the laptops I have here
13:07fdobridge: <karolherbst🐧🦀> maybe one of them has HDMI on ampere+
13:11fdobridge: <redsheep> Better hope the HDMI is wired to the nvidia gpu if so...
13:12fdobridge: <karolherbst🐧🦀> yeah...
13:13fdobridge: <redsheep> I would be happy to help test anything you have in progress if you don't have hardware. I have the next couple days off work so I could put some good time into it
13:13prophetalike: karolherbst: you are not among the real individuals i mentioned, you have a talent of being rot in the brain and being always wrong. Not to mention that all the code you made was researched by me anyways, you are empty spot entirely in competitive sports too. Keep on eating your steroids .
13:15fdobridge: <Sid> doesn't HDMI foundation disallow open source impls of HDMI 2.1
13:16fdobridge: <redsheep> They don't want public disclosure of the spec, but all of that is stuffed in the GSP, else the open nvidia kernel driver wouldn't be possible.
13:16fdobridge: <Sid> foundation/forum/whatever
13:16fdobridge: <Sid> oh
13:16fdobridge: <Sid> neat
13:16fdobridge: <Sid> rare nouveau W over amdgpu?
13:16fdobridge: <redsheep> Yeah
13:17fdobridge: <karolherbst🐧🦀> Intel already supports it
13:17fdobridge: <Sid> ~~though I know I'm not getting any more hdmi products~~
13:17fdobridge: <karolherbst🐧🦀> but like...
13:17fdobridge: <karolherbst🐧🦀> in the most cheating way
13:17fdobridge: <Sid> how
13:17fdobridge: <karolherbst🐧🦀> they have a physical converter
13:17fdobridge: <karolherbst🐧🦀> to DisplayPort
13:19fdobridge: <Sid> oh, right, that
13:29fdobridge:<zmike.> runs glcts with sparse changes and gets failures from literally every sparse test
13:30fdobridge: <zmike.> https://cdn.discordapp.com/attachments/1034184951790305330/1216739915711385722/image.png?ex=66017c59&is=65ef0759&hm=292949e8100e99ec6b517a5e3bc903d8a5d0ef7a89d0fdb19e7596c628c293e2&
13:34fdobridge: <gfxstrand> WTF? *sigh*
13:34fdobridge: <gfxstrand> Okay, I'll take a look.
13:36fdobridge: <zmike.> I'll leave it in your capable hands
13:42fdobridge: <zmike.> on the plus side you're down to only one hang
13:42fdobridge: <zmike.> nice work on the tess exception thing
13:42fdobridge: <gfxstrand> Thanks. Is it the piglit image tests that are still blowing up?
13:43fdobridge: <gfxstrand> Those tests are cruel
13:43fdobridge: <zmike.> I haven't tested piglit yet
13:43fdobridge: <zmike.> which ones are you referring to
13:43fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10759
13:43fdobridge: <gfxstrand> You filed the issue
13:43fdobridge: <zmike.> I file lots of issues
13:43fdobridge: <zmike.> let's see if it's fixed
13:44fdobridge: <zmike.> it is not fixed
13:44fdobridge: <gfxstrand> I didn't figure
13:45fdobridge: <zmike.> `KHR-GL46.direct_state_access.framebuffers_texture_layer_attachment` is the glcts hang I was referring to
13:45fdobridge: <zmike.> but yes, the piglit shader image tests are pretty miserable
13:45fdobridge: <gfxstrand> kk
13:46fdobridge: <zmike.> I think you are now (once all my pending MRs land) 2 non-sparse bugs away from glcts conformance
13:46fdobridge: <zmike.> fixing e.g., `dEQP-GLES31.functional.shaders.sample_variables.sample_mask_in.bit_count_per_two_samples.multisample_rbo_4` should get the other one
13:47fdobridge: <zmike.> (this is for all versions of glcts)
13:47fdobridge: <zmike.> though it's possible `dEQP-GLES31.functional.shaders.multisample_interpolation.interpolate_at_sample.non_multisample_buffer.sample_n_default_framebuffer` is a separate issue, I just guessed they'd be the same since they're both ms
13:48fdobridge: <gfxstrand> Getting 4.6 conformance sounds like a good project for this week.
13:48fdobridge: <zmike.> then you only have to fix the one hang
13:48fdobridge: <zmike.> though I guess since you have sparse advertised they need to be fixed too...
13:49fdobridge: <gfxstrand> I expect that's like one bug
13:49fdobridge: <zmike.> could be
13:49fdobridge: <zmike.> nvidia doesn't successfully pass a couple of those either; they've got one format where they fail to return data
13:54fdobridge: <gfxstrand> Ugh... I hate not having debug information without GSP...
13:55fdobridge: <gfxstrand> Ugh... I hate not having debug information with GSP... (edited)
13:55fdobridge: <mohamexiety> should I look into it as well, or continue with the modifiers stuff?
13:55fdobridge: <gfxstrand> continue with modifiers
13:55fdobridge: <mohamexiety> got it
13:59fdobridge: <gfxstrand> Oh, good. This test report contains... nothing.
14:01fdobridge: <gfxstrand> debug.push got to 203M before I killed the test. Maybe this just does too many draws
14:03fdobridge: <gfxstrand> Yeah, it's rendering to a max-size 3D image.
14:04fdobridge: <gfxstrand> Which on NVIDIA is 8192
14:04fdobridge: <gfxstrand> It's literally just timing out
14:05fdobridge: <gfxstrand> Excuse me 16384, rather.
14:06fdobridge: <gfxstrand> @zmike. IDK how you want to handle that. I think if we just artificially reduce a limit it should pass
14:06fdobridge: <gfxstrand> Let me try quick
14:06fdobridge: <zmike.> not sure what you mean "how I want to handle it"
14:06fdobridge: <zmike.> if you're exposing a limit it should be usable
14:06fdobridge: <zmike.> so if it isn't [going to be] usable then you need to reduce the limit
14:07fdobridge: <gfxstrand> Oh, it's usable
14:07fdobridge: <gfxstrand> But I can't control apps (the CTS via Zink in this case) that submit 3h of rendering work to the GPU.
14:08fdobridge: <gfxstrand> It's not my fault that they decide to create a max-size 3D surface and bind every single layer as a separate render pass and render to it.
14:08fdobridge: <zmike.> no, but the test passes without issue on every other driver
14:08fdobridge: <zmike.> including nvidia proprietary
14:09fdobridge: <gfxstrand> If it passes on NVIDIA that's because they don't have a GPU timeout
14:09fdobridge: <zmike.> `KHR-GL46.direct_state_access.framebuffers_texture_layer_attachment,Pass,7.014799`
14:09fdobridge: <zmike.> from my last run there
14:09fdobridge: <zmike.> if nvk is taking 3 hours for the same test then probably that's an issue
14:09fdobridge: <gfxstrand> 3h is an exageration
14:10fdobridge: <zmike.> 7 seconds is a lot shorter
14:11fdobridge: <gfxstrand> Hrm... 4096 fails but 4095 passes...
14:43fdobridge: <gfxstrand> @zmike. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28103
14:50fdobridge: <karolherbst🐧🦀> oh wow... what kind of code works once the driver is all sane
14:50fdobridge: <karolherbst🐧🦀> tried to do similar things in the GL driver, but this entire part is just entirely cursed
14:55fdobridge: <gfxstrand> Yeah, this kind of shit is why I wrote NIL the way I did
14:57fdobridge: <zmike.> @gfxstrand 💪💪💪
15:36fdobridge: <gfxstrand> I'm going to use this as an excuse to try out my new insane testing strategy
15:37fdobridge: <gfxstrand> Also, we're gonna murder @airlied's kernel patch
15:37fdobridge: <gfxstrand> It's gonna be fun.
15:41fdobridge: <karolherbst🐧🦀> though I'm curious on how that works if you are tiled on the z axis, or is the hardware actually taking this all into account internally?
15:41fdobridge: <gfxstrand> Oh, it works for Z tiling, too!
15:41fdobridge: <gfxstrand> It offsets into the tile
15:41fdobridge: <karolherbst🐧🦀> yeah..
15:41fdobridge: <karolherbst🐧🦀> that's why I'm curious
15:41fdobridge: <gfxstrand> The only reason why that doesn't totally blow up is because, outside of GOBs, NVIDIA's tiling strategy is very straightforward.
15:42fdobridge: <karolherbst🐧🦀> ahh
15:42fdobridge: <karolherbst🐧🦀> so everything just aligns very well and it "just works"?
15:42gloomineyes: juri_: there is no problems eventually such garbage as you all tend to be with karolherbst harassing and terror in others private territory get booted out from this life and planet, if you noticed you got shots of vaccines into butt cause of doing that, they end up sanctioning you trash.
15:42fdobridge: <gfxstrand> If you have a Z-tiled GOB (I guess that's a thing on Turing+?), we'll need to do Z gob offset using the base array layer
15:42fdobridge: <karolherbst🐧🦀> right..
15:43fdobridge: <gfxstrand> I know that's a thing because there are two new HW bits in the texture header: `GOB3D` and `GOB_DEPTH_OFFSET` and I suspect the later is for exactly this case.
15:43fdobridge: <karolherbst🐧🦀> yeah.. this would make sense
15:44fdobridge: <gfxstrand> For the render hardware, we'd just use the base layer
15:44fdobridge: <karolherbst🐧🦀> and the copy path is also aware of the tiling, right?
15:44fdobridge: <karolherbst🐧🦀> or is that done in a shader?
15:44fdobridge: <gfxstrand> Yeah but there's no problem there because the copy hardware can do as many Z slices as we want
15:45fdobridge: <karolherbst🐧🦀> yeah, fair
15:45fdobridge: <gfxstrand> I'm kinda surprised the render hardware screws this up. It works up to 4095 even though the blob only advertises 2048
15:45fdobridge: <gfxstrand> Maybe they're just rounding down to a power of 2?
15:45fdobridge: <karolherbst🐧🦀> and you don't operate on 2D views at this level anyway
15:46fdobridge: <karolherbst🐧🦀> isn't that like the normal array limit?
15:46fdobridge: <gfxstrand> Yeah, that's the array limit
15:46fdobridge: <gfxstrand> So arrays are fine
15:46fdobridge: <gfxstrand> I switched arrays as well, though, just for consistency
15:46fdobridge: <karolherbst🐧🦀> yeah.. I can imagine they didn't bother with 3D images there :ferrisUpsideDown:
15:46fdobridge: <karolherbst🐧🦀> and just optimized enough for 2d arrays
15:46fdobridge: <karolherbst🐧🦀> or so
15:46fdobridge: <gfxstrand> I suspect num layers is 12 bits internally and they just round down to a power of 2
15:47fdobridge: <karolherbst🐧🦀> yeah..
15:47fdobridge: <gfxstrand> It's a little weird that you can create bigger 3D textures than array textures
15:47fdobridge: <karolherbst🐧🦀> well... yeah, but also...
15:47fdobridge: <gfxstrand> But who am I to judge? I just write drivers.
15:47fdobridge: <karolherbst🐧🦀> gl has lower limits for arrays, so I guess...
15:48fdobridge: <karolherbst🐧🦀> but it's already kinda weird that there is more to 3d vs 2d arrays than just tiling
15:50fdobridge: <gfxstrand> Oh, they're fundamentally different
15:51fdobridge: <gfxstrand> Well, the difference is whether or not the miplevel applies to z
15:51fdobridge: <karolherbst🐧🦀> right
15:51fdobridge: <karolherbst🐧🦀> and the layer coord is always an int and stuff
15:51fdobridge: <karolherbst🐧🦀> but besides those details, you could just treat them the same on the hw level
15:51fdobridge: <karolherbst🐧🦀> and just configure it one or the other way
15:52fdobridge: <karolherbst🐧🦀> but I guess that's just nvidia being nvidia
15:52fdobridge: <marysaka> Do we happen to have any documentation about MME shadow RAM on any gen?
15:52fdobridge: <karolherbst🐧🦀> nope
15:52fdobridge: <karolherbst🐧🦀> the docs on MME are like.. well...
15:52fdobridge: <karolherbst🐧🦀> we don't have much
15:53fdobridge: <marysaka> NVIDIA seems to use that for conditional rendering compared to the traditional RENDER_ENABLE way
15:54fdobridge: <zmike.> @gfxstrand so what's next on the bug-smashing agenda now that you've finally defeated all the (cts) hangs
15:57fdobridge: <gfxstrand> No we don't. It's something I'd like to understand, though. That's the thing that I never did get figured out in my MME RE that's bugged me ever since.
15:58fdobridge: <gfxstrand> Once these tests run, I'll poke at sparse. I'd love it if we could submit GL 4.6
15:58fdobridge: <gfxstrand> Unfortunately, I have a feeling I'm going to end up learning how to run the GL CTS, aren't I?
15:58fdobridge: <gfxstrand> Or do you want to do the submissiosn?
15:58fdobridge: <gfxstrand> Or do you want to do the submissions? (edited)
15:58fdobridge: <gfxstrand> I have a feeling I have more hardware
16:00fdobridge: <zmike.> I have that feeling too
16:00fdobridge: <zmike.> great news though
16:00fdobridge: <zmike.> glcts submissions are pretty simple and you only need 64bit
16:01fdobridge: <zmike.> you just fire off `cts-runner` and you're basically done
16:03fdobridge: <zmike.> https://github.com/KhronosGroup/VK-GL-CTS/wiki/Creating-a-OpenGL-and-OpenGL-ES-Submission-Package is the authoritative documentation
16:06fdobridge: <pac85> Ptsd
16:08fdobridge: <gfxstrand> Hopefully this will be the first and only time I ever submit GL conformance
16:09fdobridge: <gfxstrand> I'm enjoying my new insane testing strategy
16:09fdobridge: <zmike.> imo just wait until you can do ES too
16:09fdobridge: <zmike.> and then do both at once
16:09fdobridge: <zmike.> it's only one extra bug
16:11fdobridge: <pac85> So zink on nvk is already known to pass all the tests?
16:11fdobridge: <zmike.> the baseline is in git
16:12fdobridge: <gfxstrand> I don't know what "baseline" means. Is it a results file in the ci subdir or something?
16:12fdobridge: <zmike.> yes
16:12fdobridge: <gfxstrand> There's a lot listed in zink-nvk-fails.txt
16:12fdobridge: <gfxstrand> Oh, those are piglits
16:12fdobridge: <zmike.> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/ci/zink-nvk-fails.txt?ref_type=heads
16:12fdobridge: <zmike.> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/ci/zink-nvk-skips.txt?ref_type=heads
16:13fdobridge: <zmike.> somehow you have a ton of ARB_uniform_buffer_object piglit fails
16:17fdobridge: <gfxstrand> If you've not run piglit in a while, those may be stale.
16:18fdobridge: <zmike.> I ran it friday?
16:18fdobridge: <zmike.> so probably not unless you fixed it over the weekend
16:18fdobridge: <gfxstrand> Oh, okay
16:18fdobridge: <gfxstrand> I'll have to look at some point
16:21fdobridge: <zmike.> I imagine it's something simple
16:25fdobridge: <gfxstrand> Probably
16:28fdobridge: <marysaka> I will write a proper fix for conditional rendering for now (tldr; hw reads 64 bits and not 32 bits for the compare) and dig that a bit
16:44fdobridge: <gfxstrand> `Pass: 1596039, Fail: 5, Crash: 3, Skip: 2158502, Duration: 54:44, Remaining: 0`
16:44fdobridge: <gfxstrand> I like having sub-1h CTS run times again. 😁
16:45fdobridge: <gfxstrand> I had to re-type it on top of drm-misc-fixes but that just survived a 32-thread 2-GPU CTS run with nothing at all in dmesg.
16:45fdobridge: <gfxstrand> We'll see how it goes this week.
16:46fdobridge: <gfxstrand> I really should figure out why the dEQP-VK.compute.pipeline.device_group.dispatch_base tests randomly segfault...
16:46fdobridge: <gfxstrand> I really should figure out why the `dEQP-VK.compute.*.dispatch_base` tests randomly segfault... (edited)
16:49fdobridge: <karolherbst🐧🦀> I kinda hope it fixes all those random issues :ferrisUpsideDown:
16:52fdobridge: <gfxstrand> @zmike. KHR-GL46.sparse_texture2_tests.StandardPageSizesTestCase is failing because it thinks Zink is returning (0,0,0) for the block size. Zink never calls into NVK to query it.
16:57fdobridge: <zmike.> what's the params for zink_get_sparse_texture_virtual_page_size?
16:57fdobridge: <gfxstrand> Looks like it's blowing up on `PIPE_FORMAT_B5G6R5_UNORM`
16:58fdobridge: <zmike.> I'm updating my proprietary baseline atm and can't test for a few
16:58fdobridge: <marysaka> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28106
16:58fdobridge: <zmike.> I mean is it hitting that hook?
16:58fdobridge: <zmike.> or how is it failing to query nvk
17:10fdobridge: <gfxstrand> Well, there's multiple issues.
17:11fdobridge: <gfxstrand> One is that I wasn't advertising `PIPE_FORMAT_B5G6R5_UNORM`. That's fixed now. The second is that Zink is asking for storage image support which is just bonkers.
17:12fdobridge: <zmike.> hm?
17:16fdobridge: <gfxstrand> Top patch in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28107
17:17fdobridge: <zmike.> ah
17:17fdobridge: <zmike.> hm
17:17fdobridge: <gfxstrand> And now it's blowing up on MSAA storage:
17:17fdobridge: <gfxstrand> ```
17:17fdobridge: <gfxstrand> glcts: ../src/gallium/drivers/zink/zink_resource.c:410: get_image_usage_for_feats: Assertion `templ->nr_samples <= 1 || screen->info.feats.features.shaderStorageImageMultisample' failed.
17:17fdobridge: <gfxstrand> ```
17:18fdobridge: <gfxstrand> Back to you!
17:20fdobridge: <zmike.> yeah ok gimme a few, I gotta fix this last cts fail with proprietary before I forget how format selection works...
17:21fdobridge: <gfxstrand> I'm CTSing the 565 format patch on the off chance I screwed it up
17:32fdobridge: <gfxstrand> Okay, now for the GLES bug. I'm giving that one even odds
17:41fdobridge: <gfxstrand> This one is also arguably a Zink bug though it's kinda annoying.
17:42fdobridge: <gfxstrand> The test is using `interpolateAtSample(var, i)` where `i` is some rediculous sample index on the order of 150 but it's doing so without multisampling.
17:43fdobridge: <gfxstrand> The GLSL spec says:
17:43fdobridge: <gfxstrand> > Returns the value of the input *interpolant* variable at the location of *sample* number sample. If multisample buffers are not available, the input variable will be evaluated at the center of the pixel. If sample *sample* does not exist, the position used to interpolate the input variable is undefined.
17:43fdobridge: <gfxstrand> However, the SPIR-V spec says:
17:43fdobridge: <gfxstrand> > Result is the value of the input *interpolant* variable at the location of *sample* number sample. If sample *sample* does not exist, the position used to interpolate the input variable is undefined.
17:44fdobridge: <gfxstrand> Note that the bit about MSAA is missing from the SPIR-V spec.
17:44fdobridge: <zmike.> yeah...
17:44fdobridge: <zmike.> hm
17:44fdobridge: <zmike.> I wonder if that's intentional
17:44fdobridge: <gfxstrand> It requires a shader key bit on NVIDIA so it would break ESO...
17:44fdobridge: <zmike.> sample shading in general is not possible with shader objects
17:45fdobridge: <gfxstrand> MSAA works fine
17:45fdobridge: <gfxstrand> Just not the api-level `minSampleShading` thing
17:45fdobridge: <zmike.> right...
17:46fdobridge: <gfxstrand> Oh, you already have `samples` in your Zink shader key
17:47fdobridge: <zmike.> that's for deleting samplemask variables
17:47fdobridge: <gfxstrand> And now it can be for deleting `interpolateAtSample()` calls. 😛
17:47fdobridge: <zmike.> 🤔
18:02fdobridge: <gfxstrand> Pushed a Zink patch to my sparse fixes MR. Feel free to rewrite or nak or whatever.
18:02fdobridge: <gfxstrand> It passes the test
18:05fdobridge: <zmike.> hm it's close but not quite
18:05fdobridge: <zmike.> lemme sprinkle some seasoning on top
18:20fdobridge: <zmike.> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28113
18:22fdobridge: <zmike.> thanks for your contribution
18:22fdobridge:<zmike.> back to sparse
18:23Lyude: btw dakr and airlied - I managed to get a modesetting device registered for rvkms over the weekend :)
18:24Lyude: somehow something is leaking such that it doesn't seem we're releasing various dri sysfs paths on module unload, but I figure that I'll get that fixed at some point
18:28fdobridge: <zmike.> wip https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28115
18:39fdobridge: <zmike.> looks like the other fails...
18:39fdobridge: <zmike.> huh.
18:40fdobridge: <zmike.> you've got the same weirdness as proprietary where R8I returns no data
18:40fdobridge: <zmike.> that's `KHR-GL46.sparse_texture2_tests.SparseTexture2Commitment` and `KHR-GL46.sparse_texture2_tests.SparseTexture2Lookup`
18:41fdobridge: <zmike.> `KHR-GL46.sparse_texture_clamp_tests.SparseTextureClampLookupResidency` and `KHR-GL46.sparse_texture_clamp_tests.SparseTextureClampLookupColor` seems like the issue is you don't support Z16?
18:44fdobridge: <zmike.> ah wait
18:48fdobridge: <zmike.> alright that fixes the clamp tests...
19:02fdobridge: <gfxstrand> Yeah, NVIDIA depth is weird
19:03fdobridge: <zmike.> that's not the issue
19:04fdobridge: <zmike.> just testing latest change on nv blob before switching back to test this again...
19:10fdobridge: <airlied> Is heaven still blue?
19:11fdobridge: <gfxstrand> AFAIK, yes.
19:11fdobridge: <gfxstrand> Yeah, that's really odd
19:12fdobridge: <zmike.> I think that's the issue with all the remaining tests
19:16fdobridge: <gfxstrand> I bet it's something going funky with 8-bit formats in general. I could believe that going that small breaks something.
19:16fdobridge: <zmike.> could be
19:16fdobridge: <zmike.> updated my sparse MR with all the fixes from my end
19:16fdobridge: <zmike.> there's 3 fails remaining, all with R8I broken
19:16fdobridge: <zmike.> and I think that's it
19:17fdobridge: <zmike.> nvidia GL blob can pass these tests
19:17fdobridge: <zmike.> so maybe there's something obvious they're doing that you can copy
19:21fdobridge: <gfxstrand> I added the 565 fix to !28103 so it'll go in when that one does
19:21fdobridge: <zmike.> nice
19:27fdobridge: <airlied> Are they wierd sized 8-bit? Like odd width or height?
19:28fdobridge: <zmike.> example fail:
19:28fdobridge: <zmike.> > Testing uncommitted regions access for target: 37120, format: 33321 - Sparse Allocate [levels: 3] - Commit Region [level: 0] - Fill Texture [level: 0] - API Reads - Verify Texture [level: 0] - Shader Reads - Verify Texture [level: 0] - Error detected at 128,0,0 for sample 0: expected [255] got [0]
19:32fdobridge: <gfxstrand> 512x512
19:40fdobridge: <gfxstrand> I guess it's time for a game of "Who got the image tiling wrong?"
19:41fdobridge: <gfxstrand> But first I need to get this CTS test to run for only the one format
19:42fdobridge: <tom3026> you dont seem to be all out of line disabling exceptions if one assumes this comment applies for kepler and up https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/common/unix/nvidia-3d/src/nvidia-3d-kepler.c#L62
19:43fdobridge: <gfxstrand> heh
19:43fdobridge: <gfxstrand> What I'm doing is a little more granular than the big hammer but yes
19:45fdobridge: <zmike.> it's a shame that either we didn't get to this in a month or two or that mobica doesn't work faster, as they're currently in the process of splitting out all the glcts sparse tests into individual cases
19:46fdobridge: <!DodoNVK (she) 🇱🇹> So NVK is so accurate that it emulates the proprietary driver behavior?
19:47fdobridge: <gfxstrand> IDK if that's the way I'd put it or not
19:49magic_rb: Whats the discord server that this is bridged through? If i could bridge through that it would make the whole experience nicer for me
19:49fdobridge: <!DodoNVK (she) 🇱🇹> magic_rb: https://discord.gg/CdZrXgTW97
19:50magic_rb: Thanks, ill join it later when i get to a PC
22:05fdobridge: <airlied> @gfxstrand so we should be able to expose the mappable VRAM on non-reBAR now?
22:20fdobridge: <gfxstrand> Maybe? I should swap in a Turing and give it a run. That or I might be able to disable ReBar in BIOS
22:22fdobridge: <gfxstrand> @airlied When I applied your new patch, I noticed that neither the map locking fix nor the `GETPARAM_VRAM_USED` fix have made it into drm-misc-fixes.
22:22fdobridge: <gfxstrand> Are my patches in another castle?
22:22fdobridge: <airlied> yeah those are in Linus tree, drm-misc-fixes needs to backmerge more often
22:23fdobridge: <airlied> 6.8 + that one fix should have everything
22:23fdobridge: <gfxstrand> Should I be running linus/master then?
22:23fdobridge: <gfxstrand> I swear, it's worse than playing mario
22:24fdobridge: <airlied> right now 6.8 + one fix is likely the best
22:25fdobridge: <airlied> not linus/master
22:25fdobridge: <airlied> since I assume linus/master is now merge window happy
22:25fdobridge: <gfxstrand> So where does 6.8 live?
22:25fdobridge: <airlied> v6.8 tag
22:26fdobridge: <airlied> from Linus tree
22:30fdobridge: <gfxstrand> Okay. Building that combo now
22:30fdobridge: <gfxstrand> Do you want me to test without ReBar for maximum breakage potential?
22:31fdobridge:<gfxstrand> can't wait until she can just pull 6.8.1 from Fedora and stop mucking about with kernels.
22:32fdobridge: <airlied> yeah I'd do non-rebar testing as well, though I tested on non-rebar with a hack to nvk to expose 256 mappable and it seemed to survive
22:32fdobridge: <airlied> once you are running a fedora kernel, you'll just feature request something else
22:33fdobridge: <airlied> exposing multiple queues 😛
22:36fdobridge: <airlied> if you complain too much about building your own kernel, I'll just go and hire ickle 😛
22:41fdobridge: <zmike.> @gfxstrand I think I might have tractored your z slice MR with baseline updates
22:41fdobridge: <zmike.> My b
22:45fdobridge: <gfxstrand> tractored?
22:46fdobridge: <gfxstrand> One sec. I'll fix it.
22:49fdobridge: <zmike.> Tractored is... some slang I picked up somewhere and can't even remember, I guess
22:49fdobridge: <zmike.> i.e., I threw a tractor at your MR
22:50fdobridge: <zmike.> Tractored is... some slang I picked up somewhere and can't even remember where, I guess (edited)
23:29fdobridge: <gfxstrand> Looks like it's sparse textureGatherOffset that's not working
23:29fdobridge: <gfxstrand> That's at least really specific
23:32fdobridge: <zmike.> 🙏
23:34fdobridge: <gfxstrand> Maybe we can just tell nir to lower that one. 😅
23:35fdobridge: <zmike.> Reminds me of when ANV discovered txf was broken for mutable format image views because somehow there was no CTS for it
23:44fdobridge: <gfxstrand> @zmike. Is there a debug flag to make Zink dump out SPIR-V assembly?
23:46fdobridge: <gfxstrand> nvm, I got it out of spirv_to_nir
23:47fdobridge: <zmike.> ZINK_DEBUG=spirv
23:47fdobridge: <zmike.> All the debug flags are documented in docs/
23:51fdobridge: <gfxstrand> Hrm... IDK why I couldn't find the Zink ones.