00:31imirkin: fincs: there are 2 settings :)
00:31fincs: The alpha-to-coverage master enable is somewhere else nouveau already handles
00:31imirkin: i expect all 3 options are values there
00:31fincs: "default" doesn't seem to exist at all
00:31imirkin: i.e. a value of 2 also does something
00:31fincs: Looks like your typical GL jankiness
00:32imirkin: at least th ecomment for 12e0 in rnndb says that iirc
00:32imirkin: not authoritative, obviously
00:33fincs: I've only observed 0/1 writes
00:33imirkin: you may be right
00:33imirkin: i wonder what it does by dfeault
00:33imirkin: probably uses the dither rast setting?
14:08never_released: why is the "Will you support Tegra chips?" question on the FAQ here: https://nouveau.freedesktop.org/wiki/FAQ/ still a no?
14:17RSpliet: never_released: seems that "the best of our knowledge" isn't that good.
14:18RSpliet: More seriously, nouveau only has a handful of contributors currently, most of them on a payroll. The community enthousiasm has faded a little, and with that the contributions of small (but not unimportant) things like wiki edits.
14:18RSpliet: It doesn't help that the wiki isn't publicly editable, as a spam countermeasure.
14:31never_released: (bought an AGX Xavier and searching for resources about it right now, before it's delivered)
14:32RSpliet: hahaha, okay, that's a nice little cube. Unfortunately, I highly suspect Nouveau won't do much on that... yet
14:33never_released: RSpliet: nouveau wouldn't be usable even with the nvgpu kernel-mode component?
14:33never_released: or nvgpu means that I have to use the blob in user-space too?
14:34RSpliet: I don't know much about nvgpu - I assumed that was a special Android/Chrome OS hackjob
14:34RSpliet: But I don't think the nouveau userspace component (mesa) can compile for Volta yet
14:35RSpliet: Nah, no back-end for Volta or Turing in the compiler
14:36RSpliet: I presume the rest isn't wired up either then, Pascal is the latest gen that nouveau is useful for at the moment
14:37RSpliet: The kernel driver can do display for some Volta graphics cards, but not the Tegra variant I don't think.
14:38never_released: ok, will have to stay with Linux for Tegra then
14:38RSpliet: 'fraid so. Sorry!
14:39never_released: RSpliet: no problem, was looking at Nouveau because it can provide driver components for other than aarch64
14:39never_released: like, armhf is supported by the hardware
14:39never_released: but nvidia doesn't ship user-mode components for that (and perf doesn't really matter as long as it isn't software rendering)
14:40RSpliet: I don't think the kernel requires any floating point operations
14:40RSpliet: They're explicitly avoided in kernel code
14:41never_released: read: I meant armhf user-mode components to run some apps
14:41never_released: because there are things that are only on ARM because of the Raspberry Pi
14:42never_released: and those ship with... armhf (and ARMv6 at that sometimes) binaries
14:43RSpliet: jsut so we're on the same page: "hf" stands for hardware floating-point. It's somewhat orthogonal to the architecture (ARMv6, ARMv7, AArch64). For 64-bit ARM (AArch64), GCC *only* does hardware floating point
14:43RSpliet: my source: https://stackoverflow.com/questions/61114429/aarch64-linux-hard-float-or-soft-float
14:44never_released: yes, armel can do hardware floating point too, but it relies on copying over to the integer registers the whole time
14:44never_released: as a part of the platform ABI
14:44never_released: armhf uses an ABI actually adapted to hardware FP use
14:55RSpliet: I'm beyond my expertise on this one, but the documentation I found (ARM Architecture Reference Manual v8-A, GCC AArch64-Options) suggest that this floating-point ABI distinction no longer exists for AArch64. Sounds like legacy that was sensibly dropped as the ABI(s) had to be overhauled for 64-bit anyway.
14:56RSpliet: tagr is more of an expert on this I believe. He might be able to talk about your concerns with the Linux for Tegra distro - when/if he becomes available
14:59never_released: RSpliet: yes, it's that the use case involves running legacy apps
14:59RSpliet: Ah okay, gotcha!
15:00RSpliet: Sorry, my mind's stuck in a "meh, just recompile" open source fairy tale world! ;-)
15:01never_released: RSpliet: I wish that I could do that :D
15:03RSpliet: Best of luck getting that to work though... I don't think binary compatibility across major architecture versions has been as sacred for ARM as it is for x86
15:04RSpliet: It's all very hazy for me, but I don't think ARMv5-A binaries would still run on ARMv6-A. You might be lucky that your apps are ARMv6-A.
15:05never_released: actually, ARMv5 apps still work on ARMv8
15:05never_released: it's just that 32-bit compatibility is not mandatory on ARMv8
15:05never_released: but Nvidia implements it even on their custom CPUs
15:06never_released: (Cortex-A34, Cortex-A65 and some ARM server cores do not run 32-bit apps though)
15:14RSpliet: Interesting stuff, thanks for the brief educational chat :-)
16:00imirkin: never_released: it's in reference to tegra20/30
16:01imirkin: never_released: tk1/tx1 should work mostly fine
16:02never_released: ok, and guess that I'm out of luck at this point for Volta then...
16:03imirkin: i think that one works too...
16:03imirkin: there were some patches at least
16:03never_released: it works only with the nouveau kernel module right, or does it work with nvgpu too?
16:03imirkin: no clue about nvgpu - that's an nvidia product
16:04imirkin: ah no. only gp10b
16:05imirkin: ok, there's no reference to gv10b anywhere, so i'm clearly imagining things...
16:08imirkin: also note that mesa doesn't support volta at all currently, so even if nouveau kernel module did support it, you wouldn't really get anything out of it
16:09never_released: imirkin: thanks, will have to see what to do once I get the board then
19:35karolherbst: that reminds me.. still need to figure out why mesa is broken on my tegra
19:35karolherbst: or why tagr wasn't able to reproduce the last time he looked into this issue