07:34pmoreau: Good morning! It feels weird to be back here and have again IRC opened all the time. :-)
07:40loonycyborg: weird compared to what?
07:41loonycyborg: isn't having irc always open everyone's default state? :P
08:04pmoreau: loonycyborg: Right, it was my default state for some time but had to move away from it for the past year.
09:20tomeu: loonycyborg: he had to spend some time in the other side
09:20loonycyborg: Matrix? :P
09:22loonycyborg: btw you should really give matrix.org a try
09:23loonycyborg: it's basically like discord but federated
09:23loonycyborg: and can be bridged to irc too
09:32HdkR: Living life on the other side where the only thing available is Slack and Outlook email services.
09:38loonycyborg: use matrix to replace slack :P
09:44karolherbst: HdkR: be a good guy and create a rogue IRC server :p
09:50HdkR: karolherbst: There used to be one. Not sure if it poofed
09:51karolherbst: obviously if such an attempt fails, it's the fault of the company culture and switching companies is the only reasonable consequence :p
09:52HdkR: Yea, it's the only reasonable next step
09:54karolherbst: ohh, with my last company switch I actually got rid of those nasy things as well: slack, jira and fake agile :p
09:56HdkR: Must have increased productivity ten fold just getting everyone out of a web browser :P
09:57HdkR: Also stopping slack from consume a CPU core
09:57karolherbst: instead of slacking of on slack and IRC, I only do so on IRC, less confusing overall
09:58HdkR: Consolidating BS is the best BS
10:05HdkR: karolherbst: How goes Vulkan btw? :)
10:05HdkR: Something more important then. How goes OpenCL? :D
10:06karolherbst: mhh, I guess good enough
10:06karolherbst: not much left to do
10:07karolherbst: the biggest remaining things are consuming unstructured spirv and wiring up libclc
10:12loonycyborg: if you ever implement vulkan will you support fermi cards too?
10:12karolherbst: probably not as there are some hw limitations afaik
10:12karolherbst: maybe we could make it work though
10:13loonycyborg: afaik nvidia decided to not to implement it based on market share
10:13loonycyborg: not on hardware capabilities
10:13karolherbst: I am sure that's a rumour
10:13loonycyborg: could be wrong though
10:13karolherbst: I think they added it in some version by default, because kepler is essentially fermi, with some additions, so that slipped through
10:13loonycyborg: like people thought so because nvidia planned to support d3d12 on fermi
10:14karolherbst: but there are some things fermi simply can't do and which are required by vulkan... not quite sure what it wass
10:14karolherbst: loonycyborg: well, with enough effort you could probably workaround the limitations
10:14karolherbst: question is rather if you get reasonable performance or not
10:15loonycyborg: on the other hand some old fermi cards are quite powerful
10:15loonycyborg: this might end up a good way to make more use of them
10:15loonycyborg: in the future
10:15karolherbst: kepler was a big jump though
10:16karolherbst: the fastest kepler is roughly 3x as fast as the fastest fermi
10:16HdkR: karolherbst: Unstructured spir-v is a concern for all of mesa once the spirv extension is put in place right?
10:16karolherbst: HdkR: no
10:16karolherbst: vulkan spir-v has to be structured
10:16karolherbst: so it only matters if your driver supports CL
10:16HdkR: ah, it's just OpenCL SPIR-V then?
10:17karolherbst: well, that's how it is :p
10:17karolherbst: they should just require structued spir-v for CL as well honestly
10:17karolherbst: as there is no reasonable way to come up with one you can't structure
10:18karolherbst: mhh, trivially might be a bit overstrecthing it...
10:18karolherbst: my code structurizing is around 800 loc
10:19HdkR: Is goto available in CL?
10:19karolherbst: ohh actually the structurizer is just 350, the other lines are consuming all that crap
10:19karolherbst: HdkR: not really.. some vendors might implement it though if they are stupid
10:19HdkR: Is there a reference OpenCL C++ to SPIR-V frontend?
10:20karolherbst: not really. you could say that clang is one
10:20HdkR: Or is it effectively just the spirv-llvm-translator project?
10:20karolherbst: kind of
10:20karolherbst: but there is none directly though
10:20karolherbst: clang is a decent frontend for opencl, but it allows goto
10:21karolherbst: I think it only allows gotos to labels within the same function
10:21karolherbst: you can come up with some really nasty stuff this way
10:21HdkR: Good enough to be annoying
10:22HdkR: Does Khronos OpenCL spec not have a spec for the language?
10:24karolherbst: it has
10:24karolherbst: HdkR: https://www.khronos.org/registry/OpenCL/specs/2.2/pdf/OpenCL_C.pdf
10:24karolherbst: one occurance of goto :D
10:25karolherbst: maybe we should just disallow gotos entirely inside mesa
10:26karolherbst: would solve a lot of stupid issues
10:27HdkR: Sounds like something that would just be seen as a bug
10:27karolherbst: -EWONTFIX :p
10:27karolherbst: using goto on a GPU is already bad enough
10:28HdkR: Tell that to people using subroutines
11:01pmoreau: Anyone around with a Turing card, who could give me the NVxxx code for it?
11:02pmoreau: I would like to update the wiki with Turing, but have no idea which NVxxx code is being used for them, and only now the TU1xx codes instead (which can also be found on Wikipedia).
11:04pmoreau: I’m guessing NV15x for Volta and NV17x for Turing.
11:04karolherbst: pmoreau: uhm.. mhh, potentially yes
11:05karolherbst: but probably not today
11:05pmoreau: Okay, thanks. I’ll do a first pass to add the cards with the NVIDIA notation and leave the “Nouveau notation” at NVxxx.
11:13pmoreau: Silly me, I can find that info in “nvkm/engine/device/base.c”! -_"
11:13pmoreau: NV140 for GV100, and NV162 for Tu102.
11:41pmoreau: Okay, made a few updates to the wiki to add Volta and Turing.
11:42pmoreau: Someone with more knowledge should take care of updating the feature matrix (https://nouveau.freedesktop.org/wiki/FeatureMatrix/) as I mostly went with TODO for everything there (which I think is not entirely wrong, but still a bit pessimistic).
11:44HdkR: That's a whole lot of red on that list
11:44karolherbst: pmoreau: Multicard should work
11:44pmoreau: HdkR: It’s AMD taking over! :panic:
11:45karolherbst: whatever that means though :p
11:45HdkR: lol, about as much taken over as the steam hardware survey shows I guess
11:45pmoreau: I haven’t looked as those numbers in a while.
11:46HdkR: Hasn't really moved much
11:46taliptako: karolherbst, Hey is there any update on multithreading issues, we once talk about them that i got error when using Android Emulator
11:47karolherbst: taliptako: not really. There is some deeper issue I still have to figure out sadly :/
11:48taliptako: ah i see okay Good luck :)
11:49karolherbst: pmoreau: do you think you'll find more time for nouveau stuff now btw? Or still busy with other things?
11:51pmoreau: karolherbst: I should be able to work on Nouveau stuff now; I had time for it over the past two-three weeks, but I was still recovering from the paper deadline and so had no motivation whatsoever to do anything else than doing nothing.
11:51karolherbst: understandable :p
11:53pmoreau: I’ll go back to the module thread and review at least one of your patches before the week ends; I’ll probably open an MR for SPIRV-Tools as well regarding one linking issue.
11:55pmoreau: As my latest MRs for OpenCL-CTS have been merged, I’ll start looking into https://github.com/KhronosGroup/OpenCL-CTS/issues/259, though I’ll prioritise the tasks above. -^
11:56karolherbst: ahh, yeah, that would be helpful
22:36Lyude: anyone seen this issue recently with >1 displays on anything maxwell 2 or older? [ 228.617388] nouveau 0000:22:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd 0080 data 00000000 code 0040000a
22:36Lyude: evo channels start timing out and nouveau does a dump of them as well from there
22:36Lyude: easiest trigger seems to be boot with 2 displays connected (adding them afterwards doesn't seem to always trigger the issue)
22:51karolherbst: Lyude: mhh, interesting. Does it only happen on that GPU or on different ones as well?
22:52Lyude: karolherbst: seems to be at least kepler 1-maxwell 1
22:52karolherbst: mhh :/
22:52karolherbst: regression? Might be worth to bisect in such a case
22:53Lyude: but this is something I'd have hit before if it wasn't a regression, so hopefully this shouldn't be too tough
22:53Lyude: karolherbst: yeah-going to start on that tommorrow
22:53karolherbst: cool :)
22:53karolherbst: hopefully you have better luck than I had with my last bisection :/
22:53Lyude: karolherbst: any new progress on runtime PM hell investigations?
22:53Lyude: karolherbst: if I can bisect through i915 between kernel versions v4.2 and v4.4, I can bisect anything >:3
22:54karolherbst: Lyude: I had a git bisect log with more than 100 entries :)
22:54Lyude: lots of skips I'm assuming
22:54karolherbst: yeah :/
22:54karolherbst: it was this fun ttm regression
22:54karolherbst: the initial commit just broke the kernel
22:54Lyude: karolherbst: that's actually very relevant to the i915 thing I just mentioned because I had to deal with very similar issues
22:55karolherbst: and the kernel was fixed around 50 commits later...
22:55karolherbst: super painful
22:55Lyude: I ended up managing to workaround it by bisecting until I hit something that wasn't testible, save my bisect log somewhere and reset, bisect that commit to see where the fix is, reset and restore the previous bisect log, then apply whatever fixes are needed and fix conflicts then test
22:56Lyude: so i'll probably end up doing the same thing for this
22:56karolherbst: ohh, it was kind of obvious at some point where things broke. I just didn't look at the git look early enough
22:57Lyude: karolherbst: if you know which patch fixes the ttm regression you hit that'd probably be quite useful
22:57karolherbst: it's already backported an all
22:57Lyude: karolherbst: i mean, I'll still need to know what commit in the mainline kernel fixes it so I can apply it to any bisect steps that are broken
22:57karolherbst: "drm/ttm: fix re-init of global structures" is the ttm fix
22:57Lyude: awesome, thanks!
22:57karolherbst: uhm.. let me grab the id
22:58Lyude: karolherbst: that should be enough :)
22:58Lyude: i can figure out the id
22:58karolherbst: but why does that matter for i915?
22:58karolherbst: I thought they don't use ttm?
22:59Lyude: karolherbst: it was kind of a joke, v4.2 and v4.4 was a very dark time and there were a lot of points in i915's history between those two versions where things would be horrendously broken, I ended up having to bisect some fix there a few years back and I had to bisect like 3 seperate issues just to bisect the issue I was actually trying to fix
22:59karolherbst: the main issue was that just unloading and loading nouveau (or ay ttm based driver really) crashed the kernel
22:59karolherbst: I see
22:59Lyude: that's how I learned how to workaround broken history like that
23:00karolherbst: I usually just create a new branch and reorder stuff
23:00karolherbst: that's not possible with the kernel
23:00Lyude: karolherbst: also not sure if you saw the other mention in the RH chat-turing suspend/resume seems to be broken as well (in a different way) but i'm not sure if we expect that to be working yet?
23:01Lyude: i'm guessing we do
23:01karolherbst: maybe? dunno
23:01karolherbst: did it ever work?
23:01Lyude: karolherbst: not sure, going to retest that on drm-tip tommorrow as well
23:01karolherbst: in doubt I blame secure boot
23:02Lyude: no I definitely don't think it's a secboot issue, seems to be evo channel related
23:02karolherbst: ahh, yeah, skeggsb should know what's up there...