01:03 mwk: qeeg: it's a page table
01:03 qeeg: what's it used for though?
01:03 mwk: translation of logical addresses within the DMA object to physical
01:03 mwk: notifier_idx * 0x10 is logical address
01:04 mwk: this logical address is looked up in the DMA object's page table to obtain physical address
01:04 mwk: of course, given that the address will always be < 0x100 for notifiers, only the first PTE matters
01:05 qeeg: ah
01:05 qeeg: how does that lookup work exactly?
01:05 qeeg: is the notifier_idx << 4 & 0xfff the lower 12 bits?
01:05 mwk: do you know how page tables work, in general?
01:05 qeeg: sort of?
01:05 qeeg: i dunno, it's pretty confusing tbh
01:07 mwk: okay
01:07 mwk: do you see the NV3_DMAOBJ structure?
01:07 qeeg: yes
01:07 mwk: there are several pieces to this structure
01:08 mwk: there's LIMIT, which defines how big the described logical address space is
01:08 mwk: if you ever use logical address > LIMIT, it'll page fault
01:09 mwk: second is ADJUST, which is added to the logical address before PTE lookup
01:09 mwk: third is TARGET, which tells you whether the accessed memory is in VRAM or system RAM
01:10 mwk: from what I recall, for NV3 in particular, it also determines if the object is paged or unpaged; VRAM is always non-paged, system RAM is always paged (but my recall of that part is a little hazy, I could be wrong)
01:11 qeeg: and how exactly is the physical address constructed from the logical address and ADJUST?
01:11 mwk: if it's paged: (logical_address + ADJUST) >> 12 is the index of the PTE; the physical address will be PTE.FRAME << 12 | (logical_address + ADJUST) & 0xfff
01:12 mwk: if it's unpaged: there is only one PTE, and the physical address is (PTE.FRAME << 12) + ADJUST + logical_address
01:12 qeeg: okay thanks
01:12 mwk: there's also the PRESENT and W flags in the PTE, which work as you'd expect from a PTE
01:13 mwk: (W is whether the page is writable)
01:23 HdkR: As someone that has packed PML4 tables, it can still be confusing even knowing the details :D
01:31 qeeg: mwk, it's still not matching what the win2k driver does sadly
01:31 qeeg: here's my code so far http://paste.debian.net/1265587/
01:42 mwk: uint32_t logical_addr = notify_obj_addr + (riva128->pgraph.notifier_obj << 4);
01:42 mwk: you shouldn't be adding notify_obj_addr
01:42 qeeg: oh?
01:42 qeeg: whoops lol
01:42 mwk: uint32_t paged_addr = (riva128_ramin_read_l(notify_obj_addr + (pte_index << 4) + 8, riva128) & 0xfffff000) | ((logical_addr + adjust) & 0xfff);
01:42 mwk: should be pte_index << 2
01:45 qeeg: still not working, sadly
01:47 qeeg: it just hangs waiting for the notifier to get written in the right place :/
01:48 mwk: vram_l[(unpaged_addr+1) & 0x3fffff] = notifier[1];
01:48 mwk: this should be unpaged_addr+4 obviously
01:48 mwk: ... wait
01:48 mwk: is it a uint32_t array?
01:48 qeeg: vram_l is a uint32_t array lol
01:48 qeeg: yea
01:49 mwk: then you should divide that address by 4
01:49 mwk: dma_bm_write(paged_addr, (uint8_t*)notifier, 4, 4);
01:49 qeeg: OH
01:49 qeeg: DURR
01:49 mwk: are the last params size in bytes or somehting? because it should be 16
01:50 qeeg: the second to last is how big each unit is, and the last param is how many units
01:50 mwk: huh.
01:50 mwk: strange, but fair enough
01:51 qeeg: nope, it still hangs
01:51 qeeg: even with all that fixed
01:55 mwk: well then, I assume you have some debugging tools
02:01 qeeg: this is the address that's calculated and the data it's fed to calculate it with http://paste.debian.net/1265588/
02:02 qeeg: any idea what's going wrong?
02:02 qeeg: i'm only running this with 512 mb of virtual ram so i'm not sure that address is correct...
02:04 qeeg: ramin address 0 is just 0 at this point... weird
02:04 mwk: this is all ridiculously out of context
02:05 qeeg: i can upload the full log, hold on
02:07 qeeg: https://mega.nz/file/R9llxCAR#Xs2LLLbv9L9kfbhJ5Al9YRuG0JhGEfi4KOl97j7mbAM
02:07 qeeg: pastebins won't work for this apparently lol
02:39 mwk: ... sigh.
02:39 mwk: say, haven't you been banned from this channel a while ago?
02:40 mwk: for, basically, being a stalker of mine, and demanding all my time to fix up your broken nv3 emulator code?
02:40 mwk: please leave.
04:50 KungFuJesus: Hmm, so, nv30 is giving me segfaults setting up vbos immediately in glxgears on a big endian architecture
04:50 KungFuJesus: I'm trying to figure out exactly why, the segfault is simply an invalid source pointer in a memcpy call down the stack
04:51 KungFuJesus: This is my stack trace: https://bpa.st/7YHTM I have unoptimized binaries and am hitting this pretty reliably with gdb
04:56 KungFuJesus: The invalid pointer would seem to be coming out of ctx->idxbuf on nv30_push.c:231, which seems to be mapping from a larger buffer's address space
04:57 KungFuJesus: any idea where to look here / where things are obviously awry? The stack doesn't get _too_ deep before the segfault occurs
04:59 KungFuJesus: my guess would be something weird like addressing a 32 bit integer by dereferencing the first 32 bits of a 64 bit integer. THere are a lot of things like (uint32_t*) casting from void* so that could be a hazard but a point in the right direction would be helpful
17:41 KungFuJesus: Well, I filed an issue, hopefully someone can spot the bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7972