04:36rhyskidd: grische, imirkin: mupuf and I have add some, but not all of the recently nv docs on BIOS info table to envytools
04:39rhyskidd: imirkin: those vbios blobs we were looking at is the PMU init microcode
04:39imirkin: hm ok
04:40rhyskidd: see https://chromium.googlesource.com/chromiumos/third_party/kernel/+/stabilize-smaug-7800.B-chromeos-3.18-old/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm204.c#77
04:40rhyskidd: that's from one of the Pixel C vendor trees
04:40imirkin: why so many unknown ops
04:41rhyskidd: am testing the offsets -- possible I did something silly with the struct parsing
04:41rhyskidd: (incorrect offsets = all the decoding breaks)
04:41rhyskidd: that's my theory
04:41imirkin: i tried some simple ones
04:41imirkin: but nothing that made a ton of sense
04:42imirkin: but i also didn't try a lot of them
08:18gyroninja: I am confused on how to file a bug. Specifically under what to file it under since I am not sure.
08:19gyroninja: I am running into an issue where my computer seems to somewhat randomly hang during the usage of an opengl application
08:20gyroninja: I was just able to get a kernel log with what I assume to be nouveau related error messages
08:21gyroninja: On the wiki page for HangDiagnosis I am reaching a level 3 (I can still use ssh).
11:35Michael__: Hi @imirkin_, I am working on 'Fix fbo-blending formats' and I have understood the requirements. I need a little help in where to start coding from.
12:36mupuf: Michael__ was not really patient :o
12:54pmoreau: gyroninja: If it’s a hang, I would file it as a kernel bug (it’s quite easy to move it to another component in bugzilla anyway).
12:55pmoreau: (And then, see https://nouveau.freedesktop.org/wiki/Bugs/ if you haven’t looked at it yet).
12:57pmoreau: rhyskidd: What PMU code is that? That’s not the PMU signed firmware needed for controlling the fan and such I guess, or is it?
13:00pmoreau: Wow, I haven’t woken up yet: I managed to completely miss glisse’s series in my mailbox :o
14:27pendingchaos: imirkin: It seems SUBPIXEL_PRECISION is per-viewport
15:23pendingchaos: setting 0xa18 does not seem to replicate the blob's slightly different results
16:18imirkin: pendingchaos: ok, makes sense. maybe 0xa18 is related to some of the other conservative raster settings
16:27pendingchaos: playing around with it, I'm getting flipped images and a point or line drawn at various different positions instead of a triangle
16:27pendingchaos: still not sure exactly how to use it
16:28imirkin: could be a per-viewport PolygonMode setting? dunno
17:08imirkin: pendingchaos: i wouldn't worry too much about it tbh - i was just thinking it might be related, but if it's not you don't necessarily have to figure out what it does :)
17:19pendingchaos: should SUBPIXEL_PRECISION be renamed to VIEWPORT_SUBPIXEL_PRECISION since it's per-viewport like VIEWPORT_*?
17:24imirkin: meh. your call. i'm happy either way.
17:24imirkin: there's other viewport stuff without that prefix
17:24imirkin: like the depth clamp stuff iirc
17:24pendingchaos: I won't be able to use NV_conservative_raster_underestimation btw
17:25pendingchaos: afaik, it's only supported on Volta
17:25imirkin: ah yeah, there's quite a bit of bringup to do on volta
17:25imirkin: not to mention the availability issues
17:25pendingchaos: I might be able to guess how it could be done after figuring out NV_conservative_raster_underestimation_triangles though
17:26imirkin: dunno if that's really necessary. i'd rather not have broken stuff checked in
17:26imirkin: diff gpu's can sometimes do things differently
17:27imirkin: from what i can tell, at least the ISA for Volta is a substantial rev on top of the existing stuff. as is its display thing. so i wouldn't be surprised if the 3d class also got an overhaul.
17:28pendingchaos: yeah, it would probably be a bad idea
17:54imirkin: pmoreau: do you know if maxwell v2 is sm_50 or sm_52?
17:54imirkin: looks like the half-float stuff exists on sm_52
17:56imirkin: even though i thought it was X1 / pascal-only
18:10pmoreau: imirkin: Depends which Maxwell v2 we are talking about
18:11pmoreau: sm_52 IIRC is the Maxwell tegra, sm_51 is for most consumer cards, and sm_50 is the Titan X chipset?
18:11pmoreau: But yes, only the Maxwell tegra should have fp16 support.
18:12pmoreau: Oops, no, I was wrong: sm_50 is Maxwell v1, sm_52 is all Maxwell v2, and sm_53 is the Tegra one
18:15imirkin: ok. nvdisasm seems to think that hadd/etc are available with sm_52
18:15imirkin: could be they messed up
18:16pmoreau: I think so
18:17pmoreau: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#maximize-instruction-throughput fp16 throughput is only reported starting with 5.3, thought they could have some in sm_52 that was buggy or not ready yet
18:22karolherbst: imirkin: did you check something besides hadd?
18:22imirkin: all of them are there
18:23imirkin: doing hmul2 now
18:23karolherbst: wondering what they do on hardware
18:23karolherbst: would be fun to expose fp16 on maxwell2....
18:23imirkin: could be illegal op
18:23imirkin: just coz nvdisasm says something doesn't make it so
18:23karolherbst: who knows
18:23imirkin: but it's a good start
18:24karolherbst: maybe it is super slow
18:24karolherbst: but that wouldn't be any different on non 1k+ GPUs anyway
18:24pmoreau: Even on Titan cards fp16 is super slow.
18:25pmoreau: The Tegra and the GP100/GV100 are the ones with good fp16 throughput
18:27pmoreau: karolherbst: Do I need to do anything special to get your branch working? It is throwing an INVALID_DEVICE error when creating a device.
18:28pmoreau: (on GM206)
18:29pmoreau:is recompiling as non-optimised debug to help with debugging
18:31pmoreau: (Note, I am not trying anything fancy, just running clinfo.)
18:35pmoreau: karolherbst: Never mind, probably an error somewhere in my config, where it is trying to initialise one of the software drivers, and fails at it cause I don’t have them compiled.
18:36karolherbst: nothing special afaik
18:36karolherbst: just use the right branch
18:37pmoreau: I am using the nouveau_nir_spirv_opencl_v2 one
18:37karolherbst: I hope you fetched recently?
18:37pmoreau: I cloned it 10 minutes ago
18:37karolherbst: but yeah, that should work
18:38karolherbst: maybe debug through the code and see where it fails
18:39pmoreau: It is trying to initialise one of the software drivers, but there is none configure, so clover throws an exception because it receives a NULL pipe.
18:40pmoreau: But I don’t hit that issue with my branch. Need to check the config differences between the two.
18:47pmoreau: Ah no, it’s the error in create_compiler_instance, because there is no IR_TARGET
18:48pmoreau: karolherbst: Have you not rebased on top of my branch yet, to get the fix?
18:48karolherbst: I was sure I added it
18:49karolherbst: ahh, I didn't push
18:51pmoreau: Thanks, working much better :-)
18:54pmoreau: Ah yeah, bunch of fails when running my memory_access tests: most structure ones, and mostly due to spirv_to_nir being unhappy about things.
19:17rhyskidd: pmoreau: an apparent early init PMU microcode. i'd like to be able to dump and decode it properly before jumping to conclusions
19:20pmoreau: rhyskidd: Nice find! :-)
19:22rhyskidd: it originated in the recent nv BIT table documentation -- and i just kept pulling on that string ...
19:27imirkin: rhyskidd: did you track down the offset issue?
20:27rhyskidd: haven't had a chance to look at it properly yet
21:20gyroninja: pmoreau: Where would I file it as a kernel bug? Woudl that be the Driver/nouveau component of xorg?
21:38pmoreau: gyroninja: That’s right
22:11pendingchaos: can someone explain to me (or point me to where I can find out) the difference between BEGIN_NVC0(), BEGIN_NIC0() and BEGIN_1IC0()?
22:14imirkin: check nvc0_winsys.h
22:15imirkin: and also http://envytools.readthedocs.io/en/latest/hw/fifo/dma-pusher.html#gf100-commands
22:16imirkin: (there's also IMMED_NVC0)
22:40karolherbst: uhh, no, I thought my IRC client was doing strange things, but it's alright