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