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