08:04karolherbst: why is nv30 like that...
13:56karolherbst: throwing my newest branch against the CTS and let's see what happens :)
16:19TimurTabi: karolherbst: https://patchwork.freedesktop.org/patch/470437/
16:20TimurTabi: Looks like there was a different off-by-one error in nvbios_addr that was fixed a few months ago
16:20karolherbst: and it's already pushed
16:21karolherbst: it was about a vbios which used the very last byte
16:21TimurTabi: I'll have mine ready in a few minutes
16:21karolherbst: I am still wondering how "busy" I'll be today with "random" stuff today 🙃
16:23TimurTabi: I can even use the same Fixes: line as the other patch, lol
16:27karolherbst: main: [112272/112272] Pass: 102878 Fail: 1339 Skip: 8015 ExpectedFail: 0 UnexpectedPass: 0 Crash: 4 Timeout: 36 Missing: 0 Flake: 0 Duration: 2:34:42 Remaining: 0
16:27karolherbst: with MT fixes: [112272/112272] Pass: 103475 Fail: 733 Skip: 8015 ExpectedFail: 0 UnexpectedPass: 0 Crash: 4 Timeout: 37 Missing: 0 Flake: 8 Duration: 2:27:01 Remaining: 0
16:27karolherbst: I think I am doing something right here
16:29karolherbst: 90% of the fixes are "dEQP-GLES3.functional.transform_feedback.array_element.interleaved.lines"
16:29karolherbst: transform_feedback in general
16:31karolherbst: running the multithreading tests: [1461/1461] Pass: 1271 Fail: 11 Skip: 179 ExpectedFail: 0 UnexpectedPass: 0 Crash: 0 Timeout: 0 Missing: 0 Flake: 0 Duration: 1:26 Remaining: 0
16:31karolherbst: that's good enough for me
16:33karolherbst: anholt_: only the gm20b is wired up in mesa ci, right?
16:33anholt_: karolherbst: I wired it up for a bit, but I haven't set it up post move because the kernel never got stabilized.
16:33anholt_: picked up a couple tk1s, was going to see how they do next.
16:34karolherbst: I think I pushed out the one kernel fix I had for that, no?
16:34anholt_: the one that I had identified? yeah.
16:34anholt_: but we never got a fix for the remaining one that gave us like a 90% failure rate at boot.
16:34karolherbst: that iommu stuff, no?
16:34karolherbst: yeah.. no idea what's up with that
16:35karolherbst: well.. now I have to make sure nv50 and nv30 don't regress.. nv50 should be straight forward, but nv30.....
18:32karolherbst: anholt_: do you think you'd be up to reviewing the multithreading stuff? I don't think I would have anybody else to ask :(
18:50anholt_: I hadn't looked at it because you've got it marked as draft still
18:51karolherbst: yeah.. and I still need to do a few changes, I was just wondering
18:51karolherbst: but I might just push out the mm patch
18:51anholt_: pushing out separable, reviewed changes would help
18:55karolherbst: I am still very unhappy about the general state there, but this at least works and now doesn't regress single threading.. it still shows why we need a big rework, but we can do that later :)
18:56karolherbst: I was also thinking about splitting of the changes to the fencing code, but... that got quite messy so I gave up :/ so not sure how much I can split all the substantial work
18:59karolherbst: anholt_: btw, do you know of anything besides the android emulator which is doing heavily threaded GL?
19:00karolherbst: I mostly focused on that one as it felt like getting it to run perfectly well will be good enough, based on how many GL threads it spawns
19:37mupuf: karolherbst: did I send you my tk1? If not, I guess we could organize sending one to anholt_
19:45karolherbst: TimurTabi: seems like that is it? https://www.nvidia.com/download/driverResults.aspx/187834/en
19:54karolherbst: mupuf: you did
20:03karolherbst: mupuf: my hope was, that nvidia would send anholt_ a bunch of jetsons :p
20:03anholt_: I tried multiple times to get nv to send hw. no luck.
20:03karolherbst: where did communication broke this time?
20:06anholt_: tagr asking me what hardware I was looking for, me pasting the same thing I had sent before plus a bit of clarification in response, then no response again.
20:07karolherbst: ping john then
20:08karolherbst: john was the person I asked in the first place and he seemed fine with the general idea
21:18Ermine: Congrats everyone!
21:19Ermine: Did they release full-fledged firmware images?
21:24Lyude: are we able to get them working in nouveau?
21:25karolherbst: Lyude: TimurTabi is :P
21:25Lyude: let me know if I can help at all
21:26karolherbst: TimurTabi was working on some vbios stuff the last days
21:26Lyude: karolherbst: regarding pmu firmware? like, before this was dropped?
21:27karolherbst: ehh no
21:27karolherbst: asked questions about vbios parsing, published a patch today
21:28TimurTabi: just something I noticed while trying to learn about VBIOS
21:49tanriol: Is this going to help older generations too or are they out of luck?
21:49TimurTabi: Turing and later only, sorry.
21:51tanriol: Do you mean that any lessons learned from the new driver are likely to be useless for working with older GPUs?
21:52TimurTabi: I'm not sure how to answer that question. OpenRM moves the bulk of the driver onto a coprocessor called the GSP. Turing is the first GPU to have that processor.
21:52karolherbst: I think there is some code shared on some bits, which could help fixing some bugs
21:53karolherbst: but it wouldn't help in terms of advanced features like reclocking
21:53TimurTabi: The open source portion of the driver might provide some insight, like info about the VBIOS layout that was previously unknown.
21:54Ermine: If I knew that before, I would buy gtx1050ti instead of amd!
21:54karolherbst: well, that's pacal
21:55Ermine: Ah, indeed
21:55karolherbst: and not covered by this
21:55Ermine: I forgot.. Well, I take my words back
21:55tanriol: Hm, does not sound nice. As for reclocking, my GPU is just old enough to have that. Would be nice to be able to apply that to Vulkan-only software, but that's probably orthogonal to the new developments...
21:57Ermine: Well, 1650 has simiilar price to 1050ti
22:00Ermine: Apparently, they moved all secret code to GSP
22:00karolherbst: I think it will take some time until this becomes usefull anyway
22:00karolherbst: question is just how much
22:02RSpliet: Yeah, none of this is close to being mainlined. By the very least nouveau needs to be made to interface with it (or some other OSS user-space... but it's not like they just come falling from the sky)
22:06ajax: we already have other mesa drivers with two kernel backends
22:07RSpliet: Sure, it can be done. But it takes quite a bit of engineering effort. Not sure how far in people already are with that behind closed doors ;-)
22:21dviola: holy shit (the news)
22:21dviola: couldn't believe it with my eyes
22:21karolherbst: 🎉 🎉 🎉
22:24drakonis: what a time to be alive
22:24drakonis: is any of it usable for pre turing hardware?
22:25drakonis: it seems really weird to suggest using it in nouveau if it is only useful in the latest hardware generations
22:26HdkR: Whoa, it uses DRM for its ioctl interface
22:28drakonis: wow, nice.
22:28drakonis: the other question is
22:28drakonis: can it make maxwell usable?
22:28drakonis: gotta squeeze another year out of the gpu
22:30drakonis: ah, shame.
22:32drakonis: well, that dampens all excitement
22:32drakonis: amd it is then
22:32HdkR: How likely is the module to compile fine and work on AArch64? :)
22:33airlied: pretty sure aarch64 is supported
22:34airlied: ppc64 is not
22:34HdkR: What about RISCV64? :P
22:35HdkR: Slap a card in to the HiFive unmatched board
22:36airlied: try it and see :-P
22:36airlied: though you'd have no userspace
22:36HdkR: I have a userspace
22:36HdkR: I have their x86-64 driver
22:37HdkR: FEX-Emu can run the blob fine
22:37HdkR: Even if it uses undocumented x87 instructions :|