00:14 < }8]> hi. ive got 2 boxes. both debian, one with a GT520 and one with a GT430. i read that nouveau supports both hdmi audio and vdpau but ill need to extract the firmware from the nvidia driver. the NVC0_Firmware wiki says theres a script to do this and directs you to the VideoAcceleration page.. but theres no script. so, does anyone know where to actually find this script?
00:55 orbea: }8]: read the actual instructions. :)
00:56 orbea: wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
00:56 orbea: its not a clickable link so I can see how someone might overlook it :P
02:12 rhyskidd: pushed up the minimal envytools Volta support, if anyone wants to take a look
02:12 HdkR: ooo
02:12 rhyskidd: thanks to mwk, the ssot refactor made this quite easy! thanks
02:13 rhyskidd: it works okay-ish on early VBIOSes
02:15 HdkR: aw, I was hoping for more juicy details :P
02:16 rhyskidd: it's a sign of a good abstracted base that new families are simply added :)
02:16 rhyskidd: (don't worry, there's plenty more work to come)
03:46 < }8]> orbea - using the latest stable nvidia driver (390.98) didnt work with that python script so i had to download an old one (340.32).. i guess it worked, it created a ton of files in the dir but it also said something about unknown PGRAPH order
03:49 orbea: }8]: read the instructions... :P
03:49 orbea: wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
03:49 orbea: dont need a new blob
03:49 orbea: }8]: really, read them... https://wiki.freedesktop.org/nouveau/VideoAcceleration/
03:54 < }8]> i was looking at https://nouveau.freedesktop.org/wiki/NVC0_Firmware/
03:55 orbea: ah, I didn't realize there was more than one page for that
04:01 < }8]> if this works, ill gladly dump the nvidia driver. i just need hdmi audio and vdpau to work for the dedicated htpc. no desktop install, only just what i need
04:02 orbea: }8]: it depends, some videos cause lot of graphical corruption, others work fine
04:03 orbea: mpv may be crashy with hwdec, it used to take the whole system out very fast, but I think it might be better now?
04:03 < }8]> ahh i hadnt read that. thats a deal-breaker then
04:03 orbea: i'd suggest mplayer for best results
04:03 < }8]> ive used mpv for a couple years at least and never had it crash w/vdpau
04:04 < }8]> unless you mean crashy with nouveau+vdpau+mpv
04:04 orbea: I mean with nouveau
04:04 orbea: i haven't used the blob in years
04:06 < }8]> gotcha, yeah i dunno then. but honestly, ive about had it with nvidia. at this point i'd almost rather just build some new htpcs and dump using video cards altogether
04:07 orbea: yea, the real solution is to buy amd instead :P
04:11 < }8]> im think of building a few nucs or mini-itx boxes. maybe its just time to retire these old boxes. the fastest one is an ancient amd x2 2200 IIRC. not exactly speedy but a $30 video card turned it into an htpc thanks to vdpau instead of sitting in a closet collecting dust bunnies
05:01 imirkin: the nvc0_firmware instructs you on how to generate your own firmware files from traces
05:01 imirkin: the video accel page has simple instructions that work ok for most people
05:02 imirkin: across all supported gens, some h264 files decode with weird artifacts
05:02 imirkin: if you're looking for good open-source support, go with intel or amd
05:13 HdkR: +1
05:22 < }8]> im leaning that way imirkin. i guess i just need to figure out which is more mature & actively developed between intel/amd
05:38 imirkin: both pretty good. if you need a higher-end board, amd is the only thing that offers the actual capabilities
05:39 imirkin: if it's just video decode, both are fairly equivalent afaik - both work but have (different) quirks
05:46 < }8]> yeah, just video decoding, dedicated htpc supporting 4k, hdr, 10bit .. thats all i need, no gaming, desktop, etc
05:47 imirkin: hdr / 10bit are still being worked out
05:47 imirkin: across all hw
05:47 imirkin: many intel chips have lame restrictions around hdmi
05:47 imirkin: namely that the hdmi support is only for 1.4
05:48 imirkin: you can use an active DP -> HDMI 2.0 encoder for 4k support
05:48 < }8]> i read a little about that. and that they have some hacky converter chip to simulate a real hdmi 2.0 port
05:49 < }8]> i did read though that they were supposed to have real hdmi 2.0 ports in their new offerings
05:49 imirkin: yeah, but like ... super-duper-new
05:49 imirkin: not sure if it's even released yet
05:50 < }8]> i like the nuc size but maybe a mini-itx ryzen system is the better option right now
05:51 imirkin: definitely double-check in the relevant channels
05:51 imirkin: whether your desired use-case is supported
05:52 gnarface: there are mini-itx boards for ryzen?
05:52 imirkin: although i can say with some certainty that proper hdr is not supported on any hw
05:52 < }8]> asus, asrock, and gigabyte make mini-itx ryzen boards
05:52 imirkin: 10bpp support has been improving
05:53 < }8]> i knew hdr is still a work in progress but it does seem theres a lot of activity in it
05:54 imirkin: there's some. i wouldn't say "a lot"
05:55 imirkin: mainly a couple of interested individuals playing with it a bit in their spare time
05:55 imirkin: i suspect it'll be all worked out in a year or so
05:55 < }8]> thats not the impression ive gotten from reading.. but then again, internet, so
05:56 imirkin: perhaps there are things i'm not aware of... ville sent a patchset a while back and has said he's not planning on doing more work on it
05:56 imirkin: that's the end of it.
14:10 rhyskidd: slowly progressing through the obvious Volta changes
14:13 rhyskidd: the BIT 'P' table looks changed, perhaps new entries or offsets?
14:14 rhyskidd: otherwise the BIT table and individual table versions look largely unchanged
14:17 rhyskidd: BIT 'i' table has an additional 0x4 length, relative to Pascal
16:59 plutoo: what does the "maddrsend" operation do
17:00 plutoo: ah i think i fond it
17:01 plutoo: no it's not really clear to me
18:09 karolherbst: imirkin: ... I found out why those image atomic tests fail :( and it is ugly
18:15 karolherbst: imirkin: there is basically a loop in each fragment shader doing do { old = v - 1; v = atomicMin(img, 0, old) } while (v != old)
18:15 karolherbst: but some (or all) fragment shaders are stuck in that loop forever
18:18 karolherbst: not all, because the value indeed changes
18:18 karolherbst: so either we launch to many vertices/fragments or something else is odd
18:18 karolherbst: the image is a image1D
19:00 imirkin: karolherbst: could you be mixing up imin vs umin?
19:03 imirkin: plutoo: https://github.com/envytools/envytools/blob/master/demmt/macro.c#L663
21:22 karolherbst: imirkin: no, it isn't imin vs umin
21:22 karolherbst: the value range is too small even
21:24 imirkin: other thing is it could be the stupid cctl thing
21:24 HdkR: woo cctl
21:24 imirkin: https://github.com/imirkin/mesa/commit/b250f6e610e6c6d966c1ae8511adce79cfdbc690
21:25 imirkin: shouldn't help here though
21:25 karolherbst: imirkin: https://gist.github.com/karolherbst/743a498aaf4fd89dc06863a805d90b35
21:25 karolherbst: imirkin: the loop depends on that if there is concurrent access, only one thread updates the values and every other thread tries again on next iteration
21:25 karolherbst: but
21:25 karolherbst: if there are infinite threads, it won't finish :)
21:26 karolherbst: imirkin: I put a "&& v > 0xffc00000u" into the while clause
21:26 karolherbst: and it finish a few seconds later
21:26 karolherbst: with the correct result
21:26 karolherbst: which I think is super odd
21:27 karolherbst: imirkin: I am sure the atomic operation works as expected
21:27 pmoreau: karolherbst: Could you please remind me which of your branches should one use to get all of your latest NIR and OpenCL stuff?
21:27 karolherbst: pmoreau: those with spirv in name
21:27 karolherbst: but I don't have one latest for opencl now
21:27 karolherbst: still trying to figure NIR bugs
21:27 karolherbst: *fix
21:28 karolherbst: pmoreau: I want to create a new series after fixing bindless
21:28 pmoreau: Okay.
21:28 karolherbst: and bindless kind of sounds important for OpenCL images :)
21:28 pmoreau: I wanted to try running the CTS with your work
21:28 karolherbst: ahh yeah
21:28 karolherbst: should work more or less
21:29 pmoreau: But I was wondering which branch to choose. I tried the nouveau_nir_v7, but that one only has the NIR bits, so it wasn’t too helpful. :-D
21:29 karolherbst: imirkin: maybe you have another explenation why adding that to the while clause prevents the timeout
21:29 pmoreau: So “nouveau_nir_spirv_opencl_v3” or “nouveau_nir_spirv_hmm_reduced” would be the ones to try, right?
21:30 karolherbst: (a lower value increases the time it finishes though)
21:30 karolherbst: uhm
21:30 karolherbst: yeah, lower
21:30 karolherbst: pmoreau: the reduced ones is just for the examples within the HMM-examples repository :)
21:30 pmoreau: Ah, okay. So not too useful on my GK107 laptop. :-D
21:31 karolherbst: not really
21:31 karolherbst: well the opencl_v3 branch is rebased on top of the hmm one
21:31 karolherbst: but it should work fine if you don't do SVM stuff
21:31 karolherbst: no idea what happens when you try svm
21:32 karolherbst: probably just killing channels
21:32 pmoreau: :-/
21:32 karolherbst: well
21:32 karolherbst: you pass a host pointer into g[]
21:32 karolherbst: so, yeah
21:36 karolherbst: imirkin: ohh there was another weirdo thing. "return GRID_T(v, 0, 0, 1);" -> "return GRID_T(v, idx.x, idx.y, 1);" makes it "working" as well..
21:39 karolherbst: mhhh
21:39 karolherbst: which just adds a "linterp pass" and the mad+cvt thing into $r1 and $r2
21:46 imirkin: i haven't looked carefully
21:46 imirkin: does it only fail with the nir pass, or also with tgsi?
21:47 karolherbst: same behaviour both
21:47 karolherbst: and it doesn't fail
21:47 karolherbst: it just times out
21:47 karolherbst: but the result is correct
21:47 pmoreau: karolherbst: You might want to rebase your “nouveau_nir_spirv_opencl_v3” branch as Meson fails to run, with “meson.build:1249:32: ERROR: Unknown statement.”.
21:47 karolherbst: pmoreau: uhhh
21:47 karolherbst: it should rebase cleanly mostly
21:48 karolherbst: but yeah, I should
21:48 pmoreau: No hurries though, I should be working on other things first.
21:48 karolherbst: but currently meson is coming to a point where it is more a hinderness than improving my workflow
21:49 karolherbst: meson violates already one important rule of software: don't add reasons not to upgrade software
21:49 karolherbst: and meson does it pretty brutally
21:49 karolherbst: meson upgrade: remove all build dirs and create them fram scratch :)
21:50 pmoreau: Yeah; I wrote a small script to re-initialise my build folder with all the options I want to set.
21:50 karolherbst: well yeah
21:50 karolherbst: but doing it for _every_ repository?
21:50 karolherbst: this is stupid
21:51 karolherbst: and should be quite a high prioritized bug
21:51 karolherbst: at least they added a warning that the version is incompatible as a "workaround" because it was totally failing before :)
21:52 pmoreau: Mesa is the only project I build that uses Meson, so I don’t have too many scripts to write.
21:52 pmoreau: But I agree that this is annoying.
21:53 orbea: autotools still works...
21:53 karolherbst: right
21:54 pmoreau: It does, but does not generate a compile_commands.json file nor does it generate Ninja build files (at least, not that I am aware of).
21:54 orbea: i cant say I ever found myself wanting those :)
21:55 orbea: autotools isn't great for sure, but its rather easy as far as a build script is concerned
21:55 pmoreau: :-)
21:55 karolherbst: well
21:56 karolherbst: autotools don't break your build dir because you aborted configure
21:56 karolherbst: meson does
22:19 karolherbst: imirkin: actually I think the test is wrong
22:20 karolherbst: has to be while (v == old)
22:20 karolherbst: maybe not even that
22:27 karolherbst: https://gist.githubusercontent.com/karolherbst/2a5f2e02ff8c870150e9b945f78c7399/raw/a163a36652dc37245363afc5a6cfbad59a91d268/mhh
22:31 karolherbst: ohh wait
22:31 karolherbst: I missunderstood imageAtomicMin
22:32 karolherbst: it returns the original value
22:40 plutoo: imirkin: "result" in this context is the operand?
22:40 plutoo: (envydis macro syntax)
22:57 plutoo: yeah -- seems to match up
22:57 plutoo: 00000006: ffff5097 exit branz $r2 0x3
22:57 plutoo: not sure what this means
22:57 plutoo: why would a "branz" instruction have the exit modifier
22:59 plutoo: seems the exit is triggered only when the branch isn't taken
22:59 plutoo: at least that's the only way it makes sense in this context