11:55 kreyren: How can i perform read+write on linux to VRAM?
11:56 kreyren:is working on https://github.com/Kreyren/kreyren/issues/92
11:56 kreyren: FWIW the other implementation is using
11:56 kreyren: > physmem = os.open("/dev/" + os.environ.get("MEM","mem"), os.O_RDWR)
11:56 kreyren: x.x
13:01 pgwipeout: !nick pgwipeout
17:31 imirkin: pmoreau: going to push my nv50 compute series today. object now or never.
17:33 juri_: yay!
17:33 imirkin: juri_: this doesn't really help anything directly...
17:33 imirkin: but it's a step along the way
17:33 juri_: crud.
17:33 juri_: :D
17:34 imirkin: unless you've been dying to have GL ES 3.1 on your nv50-era gpu
17:34 imirkin: which i somewhat doubt
17:34 juri_: well, kudos regardless.
17:35 juri_: yeah, earliest i've got lying about is GF108GL.
17:36 imirkin: that should have compute already
17:36 imirkin: although i do need to go back and fix 3d images at some point
17:36 imirkin: i think it can be done the same way that i did it on nv50
17:36 imirkin: (i doubt that there's a single non-test application out there which uses 3d images though)
17:37 juri_: one of these days, i'll test that. i'm fussy; i don't want to run XOrg in order to use compute, and i haven't built a non-XOrg framework for using these.
17:37 imirkin:is confused ... how is xorg tied to compute?
17:38 juri_:shrugs.
17:38 juri_: just things i've heard.
17:38 imirkin: ah i see.
17:38 imirkin: you have now heard the inverse.
17:38 juri_: maybe no-one has disillusioned me yet. :)
17:38 imirkin: enjoy :)
17:38 juri_: good! :)
17:38 juri_: i like being wrong. makes the world a better place.
17:38 imirkin: we can't BOTH be right ...
17:38 imirkin: but we could both be wrong :)
17:39 juri_: one of these days, i'll be done with the projects that keep me busy.. eventually.. :)
17:40 imirkin: uh huh
17:45 imirkin: pmoreau: just doing some final runs of test suites to make sure i didn't regress something along the way
17:52 pmoreau: imirkin: Absolutely no objection from my end. Otherwise I wouldn’t have Rb’ed or Ab’ed 99.99% of the patches in the series. 😃
17:53 imirkin: pmoreau: =]
17:53 imirkin: pmoreau: presumably you haven't discovered any issues thus far
17:53 imirkin: (that track back to my patches)
17:53 pmoreau: No, but I haven’t tested any 3D stuff either.
17:53 imirkin: hehe ok
17:53 imirkin: well i'm running the test suites now
17:54 pmoreau: 👍️
17:54 imirkin: so hopefully they'll catch any funny business
17:54 imirkin: i think we still have interop problems
17:55 imirkin: i.e. if you use compute AND 3d
17:55 imirkin: but since nothing will be hitting that initially...
17:56 pmoreau: Yeah…
17:57 imirkin: a bunch of es3.1 interop tests fail
17:57 imirkin: i haven't investigated careuflly
17:57 pmoreau: Could maybe try supporting the cl_khr_gl_sharing extension to test those paths out.
17:58 imirkin: well, ES3.1 covers it well enough
17:58 imirkin: but yeah, that sharing stuff should probably exist too for CL
17:58 imirkin: i do want to expose ES3.1 ... maybe behind some debug flag
17:58 imirkin: since even on nva3+, it will fail some texgather tests
17:59 imirkin: iirc that's it though -- i.e. nva3+ should pass all of es3.1 except for the stupid texgather with non-r component =/
17:59 pmoreau: Mmh, is there an override macro for ES, like there is for GL and CL?
17:59 imirkin: sure
18:00 imirkin: er
18:00 imirkin: 3.1 :)
18:00 pmoreau: Ok
18:00 pmoreau: :-)
18:00 imirkin: you might need some additional patches that aren't in that nv50_compute MR
18:00 imirkin: which make the core a bit happier
18:01 imirkin: i'll send a separate series later to enable it
18:01 pmoreau: Sounds good!
18:01 imirkin: don't want to do too much in one go
18:02 pmoreau: Makes sense, as it might just make the review even longer or reduce the chances of getting a reviewer in the first place.
18:04 imirkin: exactly =]
18:04 imirkin: hrmph. seeing some KHR-GLES3 failures. sigh.
18:05 imirkin: [GL_RGBA4]=>[GL_R8] conversion [src target=GL_TEXTURE_2D, dst target=GL_TEXTURE_2D] supported contrary to GLES3.0 spec.
18:05 imirkin: oh wtvr dude
18:05 imirkin: not-my-fault
18:05 imirkin: Invalid format used but glCopyTexImage2D succeeded
18:05 pmoreau: :-D
18:05 pgwipeout[m]: Well, I've made some progress on my running nouveau on arm64.
18:05 RSpliet: Can't support additional things now!
18:05 imirkin: also not-my-fault.
18:06 pmoreau: How dare you support things! This is unacceptable behaviour! :-)
18:06 RSpliet: Before you know it GLES3.1 apps are actually going to _rely_ on it, just because nouveau can do it!
18:06 imirkin: gonna call this success.
18:06 imirkin: RSpliet: well, it's mesa core which allows it
18:06 imirkin: which is why it's "not my fault"
18:06 RSpliet: :-D
18:07 pgwipeout[m]: It would seem that yes, the option rom is in fact somewhat important in setting up the card for use.
18:07 imirkin: pgwipeout[m]: that's very sad
18:07 imirkin: pgwipeout[m]: also surprising, since the option rom doesn't get run when resuming from suspend
18:07 pgwipeout[m]: I built that hacked together OVMF that implemented qemu handling of the option roms.
18:08 pgwipeout[m]: I got a partial (see corrupt) display.
18:08 pgwipeout[m]: When you suspend, you save the state of certain registers and restore them on resume right?
18:08 imirkin: pgwipeout[m]: in nouveau? not _really_
18:08 imirkin: pgwipeout[m]: at the PCI level, not 100% sure
18:10 pgwipeout[m]: I only have experience with Tegra's implementations, but as I understand it they are very similar to the desktop GPUs.
18:10 imirkin: pgwipeout[m]: tegra184+ is identical to desktop GPUs, minus the display component
18:10 imirkin: the display piece is completely separate
18:11 RSpliet: Well, and the DRAM bit
18:11 pgwipeout[m]: When they go in complete low power mode, they save an execution vector that restores the state of the board.
18:11 imirkin: i mean on tegra, there's a "tegra" display piece, which works differently from how display works on desktop GPUs
18:11 imirkin: on x86, suspend is a very platform-driven thing
18:11 imirkin: i don't know the full details
18:11 imirkin: i do know that if you suspend-to-ram (S3) then when you come back, the option ROM doesn't get run
18:12 pgwipeout[m]: There's probably some very low level handling stuff that the option rom sets up that nouveau has just taken for granted, because it's always in that state.
18:12 imirkin: but it wouldn't be in that state on resume from s2ram
18:13 pgwipeout[m]: Suspend to ram saves the state and puts the ram into self refresh. On resume bios(uefi) handles the resume functions up until handing back off to the OS.
18:14 imirkin: pgwipeout[m]: yes. but the option ROM doesn't get run.
18:14 imirkin: but what the bios does ... no clue.
18:14 pgwipeout[m]: Are we sure that it doesn't get run when the bios executes its black box resume functions?
18:14 imirkin: pretty sure.
18:15 imirkin: but it could be that nouveau restores enough stuff to make it all go
18:15 pgwipeout[m]: So dumb question, does nouveau expect the gpu to be behind an iommu?
18:15 imirkin: nouveau doesn't care
18:16 imirkin: but if there's an iommu, it better be integrated into the platform :)
18:16 imirkin: i.e. there's no separate programming of an iommu
18:16 imirkin: nouveau works across a lot of x86, and x86 sometimes has, sometimes doesn't have an iommu
18:16 pgwipeout[m]: Okay just needed to make sure.
18:17 imirkin: it MIGHT require some amount of wc? not sure. would have to grep around.
18:17 imirkin: like it might expect PAT-type capabilities
18:17 pgwipeout[m]: Yeah I got some interesting display corruption when uefi initialized things.
18:18 pgwipeout[m]: I could see the cursor and text typed into the uefi console, but the text returned is a slightly different color and it wasn't visible.
18:18 pgwipeout[m]: Also there are some horizontal blue lines with red dots.
18:19 pgwipeout[m]: And the tianocore image wasn't visible, and when uefi handed off to the kernel it crashed when checking the uefi framebuffer.
18:20 imirkin: so still not 100% perfect
18:20 pgwipeout[m]: Nope, but that might be due to the hacky code that handles the option roms.
18:20 imirkin: unfortunately i don't have anything clever to say
18:20 pgwipeout[m]: It was written to handle PXE boot firmware.
18:20 imirkin: this stuff Just Works (tm) normally
18:21 pgwipeout[m]: Haha, on arm we never get to take "just works" for granted. We have to do everything ourselves.
18:21 imirkin: and i have enough problems not to have to worry about this sort of thing.
18:21 pgwipeout[m]: That's understandable.
18:22 imirkin: my mental model of boot is that the bios runs the option rom, and the option rom installs some interrupt handlers to allow the bios to display things.
18:22 imirkin: whether that's in any way connected to reality, i couldn't tell ya
18:22 pgwipeout[m]: This is board level init stuff, which hasn't really changed much in years.
18:23 imirkin: yeah. and there are bios's which handle this sort of thing on x86
18:23 imirkin: on arm, all bets are off
18:23 imirkin: although i hear modern arm has uefi too now
18:23 imirkin: or psci or whatever?
18:23 pgwipeout[m]: It looks like to me the option rom has a lot more that it can do, because it permits the bios/uefi display to work. The uefi display code is like acpi, just a bunch of generic calls and very small.
18:23 pgwipeout[m]: PSCI is our implementation of ACPI.
18:24 imirkin: ah
18:24 pgwipeout[m]: Server arm64 runs uefi, and most arm64 boards are moving that way.
18:24 imirkin: coz no one wants to deal with platform issues
18:24 pgwipeout[m]: Haha, but then we get these black box firmware issues. And they are bad.
18:25 imirkin: yea, but not-my-problem
18:25 imirkin: i guess the x86 guys have had 40 years to work this sort of thing out
18:25 pgwipeout[m]: The x86 guys still haven't got it worked out. Have you seen the splat that comes from ACPI's drivers because the ACPI implementation isn't correct in bios?
18:26 pgwipeout[m]: They wrote the spec and they still can't follow it.
18:26 imirkin: the ACPI implementation in the bios is the definition of correctness.
18:26 imirkin: ;)
18:27 pgwipeout[m]: Well I guess that's enough hackery for now. If anyone else wants to weigh in with ideas I'll check back later.
18:28 imirkin: gr. i forgot cube texturing also fails on gles3, since they want seamless cube filtering
18:28 imirkin: and pre-nva0 has seams.
20:03 imirkin: pmoreau: fyi, looks like tests are basically passing. CTS + dEQP seem happy.
20:04 imirkin: i'm merging.
20:21 pmoreau: Awesome!
20:23 imirkin: alright. now to get the "make ES3.1 work ok in mesa core when there's only "shitty" compute available"
20:24 imirkin: errr ... wut ... did i push them already?
20:25 imirkin: so i did.
20:25 imirkin: go me.
20:25 imirkin: so now i just need to push out some caps changes.
23:12 imirkin: pmoreau: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10569