10:37fdobridge: <marysaka> :painpeko:
10:37fdobridge: <marysaka> https://cdn.discordapp.com/attachments/1034184951790305330/1059782471257956392/image.png
15:13fdobridge: <marysaka> two more tests to go and I should be mostly done ✨
15:13fdobridge: <marysaka> https://cdn.discordapp.com/attachments/1034184951790305330/1059851885491798086/image.png
15:43fdobridge: <marysaka> well for DRAM limit I cannot really do the test like on tu104 because there is no DWRITE
15:44fdobridge: <marysaka> I tried using that one unknown opcode instead to see aaand
15:44fdobridge: <marysaka> ```
15:44fdobridge: <marysaka> [10744.185077] nouveau 0000:07:00.0: gr: TRAP ch 3 [103f93a000 mme_fermi_sim_h[38657]]
15:44fdobridge: <marysaka> [10744.185096] nouveau 0000:07:00.0: gr: MACRO 80000001 [TOO_FEW_PARAMS], pc: 0x006, op: 0x00000006
15:44fdobridge: <marysaka> ```
15:44fdobridge: <marysaka> I guess this is some kind of multi parameter load maybe? :AkkoDerp:
15:46fdobridge: <marysaka> yeah I think it's read fifoed considering related methods are defined in Fermi 2D engine, I guess I will test that out
15:52KungFuJesus: Awesome, karolherbst, I have a bisectable range for that issue I was exhibiting in mythtv
15:53KungFuJesus: deinterlacing is still causing flickering but I don't start to a blank screen 3/4 of the times when launching it
16:10fdobridge: <karolherbst🐧🦀> do you check envytools for some of the unknown bits?
16:12fdobridge: <marysaka> There wasn't much for MME macros in envydis in general and I don't see any definition for opcode 6
16:13fdobridge: <marysaka> interesting enough, all read fifoed methods seems to report as invalid so maybe it's not that...
16:13fdobridge: <marysaka> interesting enough, all read fifoed methods seems to report as invalid on Maxwell Gen 2 so maybe it's not that... (edited)
16:14fdobridge: <karolherbst🐧🦀> seems like opcode 4 is also something new?
16:14fdobridge: <karolherbst🐧🦀> seems like opcode 4 is also something unkown? (edited)
16:14fdobridge: <karolherbst🐧🦀> ehh wait.. the number is encoded somewhere else
16:15fdobridge: <marysaka> my only missing opcode is 6 :AkkoDerp:
16:15fdobridge: <karolherbst🐧🦀> given that 5 is read, 6 might be write
16:17fdobridge: <marysaka> I tried that and nope it's not sadly
16:17fdobridge: <marysaka> I'm going to try again just in case
16:18fdobridge: <karolherbst🐧🦀> mhh
16:18fdobridge: <karolherbst🐧🦀> could ping mwk and see if they know anything
16:23fdobridge: <gfxstrand> Finally back from holiday. What did I miss?
16:24fdobridge: <marysaka> Not much I think :AkkoYay:
16:37fdobridge: <marysaka> Okay so I forgot to change the encoding part earlier so of course that wasn't helping...
16:37fdobridge: <marysaka> @karolherbst🐧 it seems that this opcode has similar special requirement like BRANCH, it reports as invalid if the assignment opcode is set
16:37fdobridge: <karolherbst🐧🦀> mhh interesting
16:37fdobridge: <karolherbst🐧🦀> maybe a relative vs absolute branch thing?
16:38fdobridge: <karolherbst🐧🦀> or just something entirely different
16:39fdobridge: <karolherbst🐧🦀> @marysaka did you dump all the macros nvidia uploads? @gfxstrand had some hacky script to dump them for turing, but I am sure the same method might work for previous gens
16:40fdobridge: <karolherbst🐧🦀> might make it more obvious what the unknwon opcodes/bits are doing
16:40fdobridge: <marysaka> Well I guess I could dump some with Ryujinx but that opcode never got used
16:40fdobridge: <marysaka> (And that's with OpenGL, Vulkan and even NVN APIs)
16:40fdobridge: <gfxstrand> My horrible hacks should work for any generation. I really should clean that stuff up and try to gind a real plan.
16:40fdobridge: <gfxstrand> My horrible hacks should work for any generation. I really should clean that stuff up and try to find a real plan. (edited)
16:42fdobridge: <marysaka> wait a sec... it seems the code right after that instruction just never get called, so it's maybe a branch...?
16:43fdobridge: <karolherbst🐧🦀> or it just disables the next one based on a condition?
16:43fdobridge: <karolherbst🐧🦀> or you did really jump over it...
16:45fdobridge: <gfxstrand> It's possible branch requires a delay slot
16:45fdobridge: <gfxstrand> Or that there's an off-by-one in your address calculations.
16:46fdobridge: <gfxstrand> Getting that right for Turing was a PITA
16:47fdobridge: <marysaka> There is a no delay slot bit on the branch variant, but it seems to not apply here (getting ILLEGAL_OPCODE)
16:47fdobridge: <marysaka> I do wonder if it's not like the EXTENDED one that Turing have?
16:47fdobridge: <gfxstrand> For forward branches, my method for R/E for that was to have a series of ADD instructions which incremented a register and then jump into the middle of it and look at the count.
16:48fdobridge: <gfxstrand> Oh, you're getting an illegal opcode? Hrm...
16:48fdobridge: <gfxstrand> Sorry. I thought we were talking about branches. Maybe I need to read more context. 😅
16:48fdobridge: <marysaka> going to try what it seems to like but so far immediate + src[0] seems to not get me on illegal territory :notlikethis:
16:50fdobridge: <marysaka> So basically so far I have BZ and BNZ (opcode 7), I'm trying to figure out opcode 6
16:50fdobridge: <gfxstrand> So if you don't have DWRITE, how do you even test DREAD?
16:50fdobridge: <marysaka> I use methods
16:50fdobridge: <marysaka> and scratch
16:50fdobridge: <marysaka> I use semaphore method (edited)
16:51fdobridge: <marysaka> https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/175/diffs#658ecb9648761e891273ecd1594f6227ae764697_0_821
16:54fdobridge: <marysaka> I should add a check for values here, but it does work
16:54fdobridge: <marysaka> I should add a check for correct values here, but it does work (edited)
16:55fdobridge: <gfxstrand> Reading that test, it looks like what you're calling DREAD is more like STATE on Turing
17:00fdobridge: <gfxstrand> The Turing DREAD/DWRITE are for reading/writing a special section of scratch memory accessible to the MME. There are also ways to DMA from the RAM area to other memory on the command streamer once the MME is done. I think you can also pre-populate it but I never figured out how.
17:01fdobridge: <gfxstrand> The STATE opcode is for reading back bits of GPU state such as those stored in the MME scratch staes
17:03fdobridge: <marysaka> hmm so I was trying to confirm that it could read DRAM, and got something interesting actually
17:05fdobridge: <gfxstrand> oh?
17:06fdobridge: <marysaka> ```cpp
17:06fdobridge: <marysaka> mme_value x2 = mme_fermi_dread(&b, mme_imm(NV9097_SET_REPORT_SEMAPHORE_C / 4));
17:06fdobridge: <marysaka> ```
17:06fdobridge: <marysaka>
17:06fdobridge: <marysaka> This end up reading 0
17:08fdobridge: <marysaka> I kind of remember that in the early days of Switch emulation, people were dumping "empty" channel state with that opcode
17:08fdobridge: <gfxstrand> That would be the way to do it, yes.
17:09fdobridge: <gfxstrand> As for why `REPORT_SEMAPHORE_C` reads 0, I'm not sure. It probably reads whatever was last written to `REPORT_SEMAPHORE_C`.
17:09fdobridge: <gfxstrand> I could also believe that, for some state, it always reads back 0 if it's a write-only state.
17:09fdobridge: <gfxstrand> IDK if there are any such states but I could believe there are.
17:10fdobridge: <marysaka> hmm so I suppose this should be named STATE then?
17:11fdobridge: <gfxstrand> Yeah, I think so.
17:14fdobridge: <marysaka> About the command stream thing, if I understand correctly you are talking about command buffer being populated by a MME macro (or even just a previous command buffer)?
17:16fdobridge: <gfxstrand> On Turing+, there is a special RAM attached to the MME. I think its intended use is as scratch space if you need more than you have registers for. There are also commands to DMA to/from that ram from arbitrary GPU addresses. I got DMA out to work but never DMA in. I don't know why. I don't think Maxwell and earlier have this RAM at all.
17:16fdobridge: <gfxstrand> That RAM is what the DREAD/DWRITE opcodes on Turing access.
17:17fdobridge: <marysaka> Oh I see okay I misunderstood completely then
17:18fdobridge: <gfxstrand> Yeah, it's all quite confusing. There are a lot of bits and pieces strapped onto the MME on Turing. It's not clear what they're all for.
17:18fdobridge: <marysaka> :painpeko:
17:19fdobridge: <marysaka> I thought you were talking about the prefetch logic on command buffer initially, that also have weird rules if I remember correctly
17:25fdobridge: <marysaka> @gfxstrand so to recenter, the RAM you are talking about is set with ``NVC597_SET_MME_DATA_RAM_ADDRESS``?
17:25fdobridge: <marysaka> or maybe ``SET_MME_MEM_ADDRESS_A`` and others
17:31fdobridge: <gfxstrand> All three
17:32fdobridge: <marysaka> FERMI 2D engine have those registers defined
17:32fdobridge: <marysaka> tho they report as invalid if you try to access them on a Maxwell GPU from what I tested earlier so it's kind of odd :notlikethis:
17:33fdobridge: <gfxstrand> It's set up `MEM_ADDRESS_A/B` as some GPU memory address, `RAM_ADDRESS` as a dword offset into the MME RAM and then `MME_DMA_WRITE` to copy from the MME RAM to whatever GPU address.
17:33fdobridge: <gfxstrand> There's also a `MME_DMA_READ` but I've never gotten it to work.
17:38fdobridge: <marysaka> I see
17:45fdobridge: <karolherbst🐧🦀> wondering if some of them need a privileged channel to actually work
17:46fdobridge: <karolherbst🐧🦀> but why does `DMA_WRITE` work but not `DMA_READ`?
17:47fdobridge: <gfxstrand> I suspect I was just doing it wrong.
17:47fdobridge: <gfxstrand> Once I got the FIFOED version to work, I gave up on trying to DMA into the MME RAM.
17:50fdobridge: <karolherbst🐧🦀> heh
17:54KungFuJesus: karolherbst: the offending commit: ca1ec7272685bdadd4e339cb989ac503db0abd18
17:54fdobridge: <marysaka> Just added the scratch limit test... there is only space for 128 entries :painpeko:
17:54KungFuJesus: which I guess isn't too surprising, there's bug reports / PRs suggesting that TGSI is broken on nv30
17:55KungFuJesus: but...the commit message implies it was a pretty substantial win. It seems like fixing TGSI on nv30 would be worthwhile?
17:56karolherbst: KungFuJesus: uhhh :'( pain
17:56fdobridge: <gfxstrand> That's probably plenty. We're only using a couple right now.
17:56karolherbst: guess there is something wrong with the nir to tgsi translation then
17:57KungFuJesus: more annoyingly, it's not consistently broken, lol
17:57KungFuJesus: every few launches it might work
17:58fdobridge: <marysaka> oh yeah I just thought there was 256 entries initially
17:58karolherbst: KungFuJesus: huh....
17:58karolherbst: tried to run with valgrind or with libasan?
17:58karolherbst: could be some annoying memory corruption thing
17:58KungFuJesus: or it might partially work, where the text won't render correctly (mythtv's gl rendering does use shaders)
17:59anholt: I found nv30 to be unusuably unstable, even single threaded, even before that commit.
17:59KungFuJesus: anholt: I'm guessing you're hitting more surface area of the GL API than I am
17:59karolherbst: yeah.. anyway
18:00karolherbst: if using nir to tgsi regresses something, I suspect it's a bug either inside nir to tgsi or nv30 does start seeing TGSI stuff it didn't before
18:00anholt: my assessment was "either nv30 is plain broken already, or the hw is so old and rotten that all 3 gpus I have have failed, so we there's no way to test it."
18:00karolherbst: in either case...
18:00anholt: so my assumption on someone bisecting to that commit would be more of the "nv30 was already broken, and now we're tickling that for this workload"
18:00KungFuJesus: anholt: I don't think there was anything wrong with your GPU, this GPU is in pretty good shape and sees issues
18:00karolherbst: anholt: I have one particular nv40 GPU where gnome works without issues, but starting glxgears would literally kill the session...
18:01KungFuJesus: karolherbst: heh, my MR should fix that one, at least
18:01karolherbst: nice
18:01KungFuJesus: the minimal reproduction for that one was to construct a display list, so I can see how it might have been missed
18:02karolherbst: yeah, let's merge that fix then
18:02karolherbst: it's quite fun, that nv30 actually started to become "useable" last year...
18:02karolherbst: or two years ago
18:02karolherbst: ?
18:03KungFuJesus: lol, only took 16 years
18:03karolherbst: anyway.. I'm happy to keep the driver if people keep hacking on it :D I just probably won't look into issues myself unless I really have to (which I probably never will)
18:03KungFuJesus: I mean there's another texture byteswapping issue that's fixed by another MR that's been in there for about a year or so. That bug is independent of nouveau and goes back at _least_ to 2018
18:03karolherbst: ahh yes...
18:04karolherbst: big endian is just a mess atm
18:04karolherbst: because a lot of code treats big endian wrong
18:05KungFuJesus: this was a case where a packed texture format didn't have special big endian handling that was needed in the broader scope of mesa. The guy that fixed that found it via some comment bread trail
18:05karolherbst: figures
18:05KungFuJesus: Gotta keep fighting the fight for endian correctness. The Big Endian will rise again
18:05karolherbst: I mean... a lot of the code assumed you could handle big endian by swizzling channels
18:05karolherbst: which you can't
18:06karolherbst: but apparently that's how we handled big endian from the start
18:06karolherbst: all that swizzling code has to go
18:06karolherbst: there is no other sane way out there for proper big endian support
18:09KungFuJesus: I do wonder how the proprietary nvidia driver for Mac OS of yore handled it
18:11karolherbst: in the proper way
18:13fdobridge: <marysaka> Well I think my MR is done, the only missing part is making tu104 and fermi builder share code... and probably fixing the codestyle a bit
18:13KungFuJesus: Using altivec based vperm to swap 16 bytes of the texture at a time?
18:15KungFuJesus: karolherbst: You think that the TGSI issue here is host based memory corruption that valgrind can sus out? If so I can give it a go, I'll just need to again rebuild my glibc in split debug configuration
18:30fdobridge: <gfxstrand> Cool! Why don't I pop a Maxwell in my box and play around with it a bit.
18:31fdobridge: <gfxstrand> My brain's not working for anything else today (post holiday fog) so helping you get that landed sounds like a good task.
18:33fdobridge: <marysaka> sure :AkkoYay:
18:40fdobridge: <gfxstrand> I did just rebase the nvk/main branch a few minutes ago (starting off the new year with a fresh rebase). Mind rebasing on that quick?
18:41fdobridge: <gfxstrand> Oh, the fan noise...
18:43fdobridge: <marysaka> on it 👍
18:47fdobridge: <marysaka> should be rebased now
18:47karolherbst: KungFuJesus: yeah.. hopefully
18:47fdobridge: <karolherbst🐧🦀> @marysaka I guess I can also test it on the previous gens next week or something.. let's see how much I get done this week 🙃
18:48fdobridge: <marysaka> I can try this week end if you want, I still have my GT 440 around I guess
18:48fdobridge: <marysaka> for Kepler uuurgh I have an old laptop with a 860M I think that's Kepler but not sure
18:48fdobridge: <karolherbst🐧🦀> fermi isn't supported though
18:49fdobridge: <karolherbst🐧🦀> and probably never will be
18:49fdobridge: <karolherbst🐧🦀> I mean.. if you want you can look into fermi support
18:49fdobridge: <karolherbst🐧🦀> there are just two major things: no copy subchannel, so everything using xxb5 needs to be replaced by something fermi specific, also, compute launches are different
18:50fdobridge: <karolherbst🐧🦀> fermi does have the xxb5 subchannel in theory, but only for privilged channels afaik
18:50fdobridge: <marysaka> oh yeah I mean just to test MME tests on it
18:50fdobridge: <karolherbst🐧🦀> sounds about right.. but probably better to check
18:51fdobridge: <karolherbst🐧🦀> ahh...
18:51fdobridge: <karolherbst🐧🦀> I meant testing all of nvk
18:51fdobridge: <marysaka> ah I see
18:51fdobridge: <karolherbst🐧🦀> I'll run the CTS on all the hardware, no problem
18:51fdobridge: <karolherbst🐧🦀> I just want to land spirv support in rusticl this week first, and that requires me to fix the CL CTS
18:51fdobridge: <marysaka> It's a bit of mess in the current state as mme_value and others are probably going to conflict between tu104 and fermi side :nya_sad:
18:52fdobridge: <karolherbst🐧🦀> yeah.. just ping me once you are done or something 🙂
18:52fdobridge: <marysaka> I mean I'm not sure how to separate that tbh
18:52fdobridge: <gfxstrand> Sanity test fails on my Maxwell. 😭
18:53fdobridge: <marysaka> nani
18:53fdobridge: <karolherbst🐧🦀> noooo 😦
18:53fdobridge: <marysaka> is that Gen 1?
18:53fdobridge: <karolherbst🐧🦀> does compute still work tho
18:53fdobridge: <gfxstrand> Yeah, it's a Maxwell A in this case
18:53fdobridge: <marysaka> I don't have any of those urgh :nya_flop:
18:53fdobridge: <karolherbst🐧🦀> @gfxstrand you mean sanity vulkan or mme testing?
18:54fdobridge: <gfxstrand> Sanity MME
18:54fdobridge: <karolherbst🐧🦀> ahh
18:54fdobridge: <marysaka> is it the device finder not working or something else?
18:54fdobridge: <gfxstrand> Device finder seems to work.
18:54fdobridge: <gfxstrand> I've got both cards plugged in and it seems to be running on the Maxwell
18:55fdobridge: <gfxstrand> Getting piles of ILLEGAL_CLASS
18:55fdobridge: <karolherbst🐧🦀> ehh
18:55fdobridge: <marysaka> huh how that possible
18:55fdobridge: <karolherbst🐧🦀> guess the subchannel stuff is wrong then
18:55fdobridge: <karolherbst🐧🦀> or something
18:56fdobridge: <marysaka> can you check what device is being selected in ``mme_fermi_sim_test::SetUp()`` via the device id?
18:56fdobridge: <gfxstrand> Yeah. I think we just need to init subchans
18:56fdobridge: <marysaka> ah ok
18:57fdobridge: <gfxstrand> Yup. That was it.
18:58fdobridge: <gfxstrand> Pushed a patch on top to fix it
18:59fdobridge: <gfxstrand> I wasn't doing `SET_OBJECT` in the Turing tests either. 😲
18:59fdobridge: <karolherbst🐧🦀> yeah... for some hw it doens't matter
18:59fdobridge: <karolherbst🐧🦀> it's weird
18:59fdobridge: <karolherbst🐧🦀> for some the kernel works around broken userspace
18:59fdobridge: <gfxstrand> Easy fix
18:59fdobridge: <karolherbst🐧🦀> yeah
18:59fdobridge: <karolherbst🐧🦀> for ampere it matters again I think
19:00fdobridge: <karolherbst🐧🦀> @gfxstrand you don't have an ampere gpu, do you?
19:00fdobridge: <gfxstrand> No, not yet
19:00fdobridge: <karolherbst🐧🦀> k
19:00fdobridge: <karolherbst🐧🦀> now that the kernel stuff is merged, maybe I'll look into ampere and see how broken it is
19:00fdobridge: <marysaka> I kind of followed your tests and builder quite a bit :AkkoDerp:
19:01fdobridge: <marysaka> there is possibly bugs on the turing simulator around carry/borrow part that I need to confirm at some point
19:01fdobridge: <marysaka> (like ADDC/SUBB touch the carry on fermi MME need to confrm that for turing but I suppose it's the same)
19:04fdobridge: <gfxstrand> Oh, they do? Interesting. On Turing, each instruction has 2 ALU ops, 2 mthd, and 2 emit, all of which can be no-op. ADDC and SUBB are required to be the 2nd one with the initial ADD/SUB as the first.
19:04fdobridge: <gfxstrand> IDK if the carry value even exists between full instructions
19:09fdobridge: <gfxstrand> @marysaka So, for registers, I see you're reserving R0 and R1 Is there anything other special we need to do for RA there?
19:10fdobridge: <gfxstrand> Also, is R0 always zero or can it be written to?
19:11fdobridge: <gfxstrand> Ok, I think I see roughly how this works. Hrm... 🤔
19:13fdobridge: <gfxstrand> Only 7 registers. That's gonna be limiting...
19:16fdobridge:<gfxstrand> contemplates NIR back-ends again
19:19KungFuJesus: hah, also realized that a lot of the terrible issue you guys had been seeing with nv30 are probably not hitting me as badly since I'm building mesa without xa. Then again, I'm using fluxbox so hard to say if those features are being used all that much, anyway
19:21fdobridge: <gfxstrand> I was really hoping the Fermi MME would be a tiny bit more capable. 😕
19:27fdobridge: <gfxstrand> Our simple draw macro already uses 7 registers. Draw indexed uses 8 (but can be reduced to 7).
19:29fdobridge: <gfxstrand> With real liveness and RA they both will fit just fine in the Fermi MME's 7 regs.
19:29fdobridge: <gfxstrand> But that means liveness and real RA. 😭
19:29fdobridge: <gfxstrand> Or a couple well-placed `free_reg()` calls.
19:32fdobridge: <gfxstrand> I think I'll proceed under the assumption that we don't need RA for now. 😅
19:32fdobridge: <gfxstrand> The MME for queries is just not possible on Fermi
19:33fdobridge: <gfxstrand> We'll have to fire off a compute shader for that but that's ok. I was assuming we'd need to do that eventually anyway. I did MME because I'm lazy and didn't want to think about meta for queries.
19:35anholt: KungFuJesus: my testing didn't even have a window system running
19:36fdobridge: <karolherbst🐧🦀> @gfxstrand why would we need a compute shader?
19:37fdobridge: <gfxstrand> `vkCmdCopyQueryPoolResults()`
19:37fdobridge: <gfxstrand> Right now it's a giant MME
19:38fdobridge: <gfxstrand> Could do it with a vertex shader too if we want to avoid the channel switch stall.
19:38fdobridge: <karolherbst🐧🦀> let me see the macro first tho
19:39fdobridge: <gfxstrand> https://gitlab.freedesktop.org/nouveau/mesa/-/blob/nvk/main/src/nouveau/vulkan/nvk_query_pool.c#L536
19:39KungFuJesus: karolherbst: Trying valgrind first, but is there anything special to make mesa build with asan?
19:42karolherbst: KungFuJesus: nope
19:42karolherbst: just use the meson flag and it should just work
19:43KungFuJesus: asan is just so much better in my experience
19:43karolherbst: it is
19:45anholt: KungFuJesus: -D b_sanitize=address, and disable tests because some compiler tests fail
19:45anholt: if you end up looking at leaks, then you need libdlclose-skip.so (check .gitlab-ci/test/gitlab-ci.yml
19:46anholt: oh, and run your app with LD_PRELOAD=libasan.so.6
19:46KungFuJesus: right, done that one about a million times
19:55fdobridge: <marysaka> yeaaah :notlikethis:
19:56fdobridge: <marysaka> there is still some saveup that could be done here and there especially around mme_mov/mme_add with immediate but it's a mess
19:57fdobridge: <gfxstrand> Yeah
19:57fdobridge: <gfxstrand> It's ok. The good news is that it will be the same every time (it's not dynamic) so as long as we test on something pre-Turing regularly, it should be ok.
19:59fdobridge: <marysaka> I wonder tho maybe it would be okay to use scratch space a bit more with fermi
19:59fdobridge: <marysaka> I haven't seen the current turing macro yet
19:59fdobridge: <marysaka> I haven't seen the current turing macro yet tho (edited)
20:01KungFuJesus: lol, excellent, can't reproduce with debug build flags. Sounds like I might need to turn on ubsan as well. Does -D b_sanitize=address,undefined work as well?
20:08fdobridge: <marysaka> @gfxstrand do you happens to know what happens when you use the EXTENDED instruction with an empty fifo memory?
20:08fdobridge: <gfxstrand> no idea
20:08fdobridge: <marysaka> asking for that unknown opcode I'm still looking at
20:09fdobridge: <gfxstrand> I've been working under the assumption that it's just a sort of barrier
20:09fdobridge: <gfxstrand> I really don't know much about it
20:09fdobridge: <marysaka> like on Fermi, when you do a LOAD when you don't have parameter it just kill the macro it seems
20:09fdobridge: <marysaka> without any exception in kernel logs :notlikethis:
20:09fdobridge: <gfxstrand> 😦
20:10fdobridge: <marysaka> and well that one unknown opcode also kill it the same way so I'm kind of assuming it's related... but I still get illegal error on the address for that MME memory thing
20:10fdobridge: <marysaka> I should really grab a Fermi and test this, maybe that opcode is just a leftover or something :AkkoDerp:
20:26KungFuJesus: not seeing anything from asan or ubsan, I think we might be looking at a bug emitted in the shader compilation :-/
20:26KungFuJesus: either that or some buffer's not being properly flushed
20:41KungFuJesus: are we sure b_sanitize= is right?
20:44KungFuJesus: ohhh, I don't think it's enough to inject into the build flags
20:47KungFuJesus: ok, injecting "c_args" now
20:57fdobridge: <gfxstrand> @marysaka You can probably go ahead and make the isaspec change an MR against main.
21:00fdobridge: <marysaka> ah right I forgot that one 👍
21:02KungFuJesus: I _think_ this issue hides with -O0, but that may take a bit to track down
21:06fdobridge: <gfxstrand> Ugh... I'm starting to dislike the current MME builder.
21:06fdobridge: <gfxstrand> I think we need a tiny bit more abstraction.
21:06fdobridge: <gfxstrand> IDK that we need NIR but I think we need some sort of tiny intermediate something.
21:07fdobridge: <gfxstrand> At the very least, an enum of all ops and not use the TU104 enum directly.
21:07fdobridge: <marysaka> I guess yeah
21:07fdobridge: <gfxstrand> And fermi can just not support some of them
21:08fdobridge: <marysaka> :painpeko:
21:08fdobridge: <gfxstrand> I'm trying really hard to make it so that, inside NVK, we don't have to type every macro twice.
21:08fdobridge: <gfxstrand> If we can accomplish that, I think we win.
21:08fdobridge: <gfxstrand> Let me do some typing and see how horrible it all is.
21:15KungFuJesus: karolherbst: Does this get used by nv30/40? https://pastebin.com/yEg2Gzfe
21:44karolherbst: KungFuJesus: nope
21:45fdobridge: <karolherbst🐧🦀> @gfxstrand well.. whatever you come up with, it won't be worse than what we have inside gallium atm 🙃
21:47KungFuJesus: karolherbst: got a couple of hits, some of which look sus
21:47KungFuJesus: first: ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:101:4: runtime error: null pointer passed as argument 2, which is declared to never be null
21:47karolherbst: well
21:47karolherbst: thing is, if it would be that you'd notice
21:48KungFuJesus: and: https://pastebin.com/XCVabNpU
21:48karolherbst: ahh yes..
21:48karolherbst: that looks like a bug
21:48karolherbst: uhhh
21:49karolherbst: _mesa_array_format_flip_channels
21:49karolherbst: :pain:
21:49karolherbst: this has to go
21:49KungFuJesus: at _least_ an off by one bug, though it may have been the first access that bombed
21:49karolherbst: it's sooo wrong
21:49karolherbst: honestly... big endian inside mesa is done in the most wrong way possible
21:52KungFuJesus: so what is this code actually trying to accomplish? Is flip_xy a lookup table of sorts?
21:52karolherbst: apparently somebody was thinking that rgba on big endian looks like abgr
21:52karolherbst: and then things just evolved from that
21:52KungFuJesus: lol, I see why big endian is only affected
21:53karolherbst: yeah.. it's all so horible wrong
21:53karolherbst: *horibly
21:53KungFuJesus: big ol ifdef in there
21:53KungFuJesus: what's a good thing to try here?
21:53karolherbst: dunno.. remove all big endian code and hope it's just fixed? dunno
21:54karolherbst: I think someone has to take a real good look at this mess and do it once from a clean state for real
21:54karolherbst: because this swizzling channels around makes no sense
21:54karolherbst: however
21:54karolherbst: there are times we load pixels as uint32_t packs and sometimes we only access the channels
21:55karolherbst: and do weird load/store operations with different pointer types and what not
21:55karolherbst: so things just happen to be swapped around sometimes
21:55KungFuJesus: you think it _ought_ to behave properly if this ifdef gets ripped out?
21:56karolherbst: no, but probably easier to fix it this way for real
21:57KungFuJesus: The immediate problem being found by asan is a direct out of bounds index due to swizzle's values
21:57karolherbst: yeah.. figures
21:57karolherbst: what's the format?
21:58karolherbst: also..
21:58karolherbst: what's this flip_xy[6] thing if only the first 4 values are accessed anyway?
21:59karolherbst: uhhh
21:59KungFuJesus: all very good questions - should I inject some printfs?
21:59karolherbst: I hope the magic _mesa_array_format_set_swizzle is doens't mess stuff up
21:59karolherbst: ohhh
22:00karolherbst: it's a double indirect
22:00karolherbst: k...
22:00KungFuJesus: yeah, swizzle is an indexing into flip_xy
22:00KungFuJesus: uber efficient, lol
22:00karolherbst: this is all so wrong
22:01KungFuJesus: I plopped an #if 0 instead of ARCH_BIG_ENDIAN just to see if it gets further or gets me a proper image, even if byteswapped
22:02KungFuJesus: (which actually, it already is at the moment until that one PR goes in)
22:02karolherbst: probably renders garbage in a predictable way
22:02karolherbst: or maybe it just works
22:02karolherbst: dunno
22:04KungFuJesus: not immediately crashing but, also seeing some bit shifts that may be posing some sign extension issues?
22:05KungFuJesus: https://pastebin.com/Amki2uw8
22:05karolherbst: heh
22:05karolherbst: sounds like more big endian mess up... maybe not dunno
22:05KungFuJesus: I think PPC specifically struggles with these sort of things
22:06karolherbst: yeah well...
22:06KungFuJesus: I've seen something similar with char versus unsigned char
22:06karolherbst: ehh wait what
22:07karolherbst: ohhh
22:07karolherbst: int vs unsigned int
22:07KungFuJesus: right
22:07karolherbst: uhhh
22:07karolherbst: why is C that terrible
22:07karolherbst: fun part
22:07karolherbst: line_stipple_patternis uint32_t
22:07KungFuJesus: now if sign extension is the issue because the value itself is now way bigger due to endianness...then yeah maybe I did that by disabling that byte swap path
22:07karolherbst: I honestly don't know why it complains about it
22:08karolherbst: it's an unsigned 0x0000ffff value
22:08karolherbst: shifted by 16 left
22:08karolherbst: which is 0xffff0000
22:08karolherbst: sooo...
22:08karolherbst: what's the problem?
22:09KungFuJesus: compiler definitely thinks something is interpreted as a signed int somewhere
22:09karolherbst: try shifting by 16u
22:09karolherbst: uh... ul?
22:09karolherbst: mhh
22:09karolherbst: I guess u should be enough
22:09karolherbst: dunno
22:09karolherbst: probably some weirdo C spec thing which makes it signed
22:10KungFuJesus: and the value being OR'd with it, also unsigned?
22:10karolherbst: correct
22:14KungFuJesus: I'm a bit confused about the fragprog.c line...there's a logical or there, not a left shift
22:15KungFuJesus: oh maybe the macro has a shift
22:16karolherbst: ahh yes...
22:16karolherbst: should probably use 1u instead of 1...
22:18KungFuJesus: yeah, just fixed that
22:18KungFuJesus: lol, I wonder how many cryptic bugs that fixed
22:18karolherbst: probably none
22:27KungFuJesus: we sure these null pointer access claims are false positives?
22:27KungFuJesus: (pipe_surface)
22:28KungFuJesus: I'm also seeing a bunch of misalignment issues but maybe that could be due to the lack of swizzling? https://pastebin.com/euTGQhWT
22:35KungFuJesus: oh fun stuff, format_info header is generated via some python
22:37KungFuJesus: good god that's a lot of formats. I'm going to need to print the index and hope it's not something monsterous I have to count into this thing
22:37KungFuJesus: assuming any of this is our issue
22:37KungFuJesus: seemingly the issue disappears when optimizations are off, so maybe something being explicitly zero initialized somewhere makes it work?
22:38karolherbst: probably
22:38KungFuJesus: grepping for "Swizzle", quite a few show a value of 6
22:42KungFuJesus: it's really not clear to me where python is pulling in the swizzle array that's being printed in that format string
22:43KungFuJesus: oh it's hiding in format_parser.py
22:43KungFuJesus: thanks, Intel
22:46KungFuJesus: It looks like 6 is supposed to reprent "swizzle_none"? As in, "No data available for this channel". So, being undefined is somehow ok in that circumstance?
22:46KungFuJesus: this still seems odd to me
22:47KungFuJesus: This isn't _just_ nv30 code, like everything is using this, no?
22:48KungFuJesus: but seemingly only for big endian architectures
22:49KungFuJesus: alright so, my guess : this is one of those formats that have the "None" or undefined bit where we don't care about that channel. But because the "swizzle" shader being emitted is an invalid index with uninitialized memory, we end up with some rather undefined behavior
22:49KungFuJesus: I'll try to define the last bit as "0" in flip_xy and see if it fixes it
23:22KungFuJesus: this glsl compiler here is doing some rather unsavory things in C++ with types
23:22KungFuJesus: that's basically what the sanitizers are complaining about with that type cast
23:23KungFuJesus: I'm not even confident that's legal in C++, given that those are subclasses and not the other way around
23:23fdobridge: <gfxstrand> Stupid isaspec and its hard-coded generated filenames. 😦
23:27KungFuJesus: base class is a struct and is not a polymorphic type
23:32KungFuJesus: I mean in theory this cast _should_ be fine if you can guarantee that the pointer is of type ir_variable, but the sanitizers seem to disagree with that sentiment
23:36KungFuJesus: vtable invalid entries also maybe a bit troubling
23:46KungFuJesus: eh, this bit is also looking awfully suspicious: ../src/gallium/auxiliary/util/u_inlines.h:131:8: runtime error: member access within null pointer of type 'struct pipe_surface'
23:46KungFuJesus: old->reference should be illegal and it sounds like ubsan/asan are definitely finding old to be a null. I'm quite surprised that didn't cause a crash
23:48KungFuJesus: perhaps reference is at a 0 offset within the struct