18:04pmoreau: karolherbst: Sorry about that, finally looking at the series and testing it.
18:05pmoreau: It is compiling on a recent Mesa, but I need to update it to take into account changes in the initial series, so that it works as intended.
18:05pmoreau: Do you happen to have used it recently on an updated Mesa?
18:09karolherbst: pmoreau: no
18:22codedmart: Lyude: You just wanted me to check that my backlight still works with those patches?
18:22codedmart: Sorry didn't do anything this weekend.
18:27Lyude: codedmart: np, and yeah if you could that would be appreciated
19:38pmoreau: karolherbst: Pushed an updated version; I tested it locally on a NV50 so I could only quickly test the API.
19:53karolherbst: pmoreau: ohh, mind posting the nv50 patches? I guess we could merge those already, just want to take a look at them
19:53karolherbst: that's mainly the kernel input stuff, no?
19:54pmoreau: For the NV50 patches, I just hacked the input so that the devices would be exposed by clover.
19:54pmoreau: But I haven’t changed the inner, so it’s currently complaining about getting an unknown IR in. :-)
19:54karolherbst: ahh, mhh, yeah
19:54karolherbst: we migh want to split up PIPE_COMPUTE
19:54karolherbst: into PIPE_GL_COMPUTE and PIPE_CL_COMPUTE or something
19:55pmoreau: This is what I have at the moment: https://hastebin.com/ofuxegemay.cs
19:55karolherbst: I'd like to have this separation anyway, as those are not the same thing
20:04imirkin_: iirc i turned off PIPE_CAP_COMPUTE because of some stupid vl crap
20:04imirkin_: i think this can be undone since hte stupid VL crap is now behind yet-another thing
20:04karolherbst: ahh, because vl uses compute shaders if the driver supports it
20:04karolherbst: ohh, good to hear
20:04imirkin_: since it basically requires AMD hw to operate
20:04imirkin_: it doesn't check for various capabilities/etc
20:05imirkin_: there's now like a PIPE_CAP_PREFER_COMPUTE_FOR_MULTIMEDIA
20:05imirkin_: or something equally long
20:06karolherbst: PIPE_CAP_PREFER_COMPUTE_FOR_MULTIMEDIA yep
20:52codedmart: Lyude: Screen backlight works as before. Everthing is all good.
20:53Lyude: codedmart: awesome, thanks! I'm starting work on your issue today btw
20:53Lyude: codedmart: btw, what kind of display does your X1 have
20:53imirkin_: Lyude: crc on backburner?
20:53Lyude: imirkin_: these are the rhel issues I was saying I had to go through first :p
20:53Lyude: but i worked a bit more with the crc stuff over the weekend
20:54Lyude: i'm not entirely sure yet but this crc interface might be a lot more awkward to use with igt then I originally thought
20:56Lyude: since it looks like that the GPU might actually not write any CRCs to the notifier region until the CRC capture has stopped, which would mean if we were to deliver CRCs to userspace immediately we would have to flip the notifier region every vbl. there's still some bits and some other things that I haven't tried to see if we can change that behavior though
20:56Lyude: (notifier region looks to be all zeroed during capture, but appears to actually get filled with proper CRC values once we disable capture)
20:56imirkin_: Lyude: hmmmm
20:56imirkin_: should read over the doc again
20:57imirkin_: not saying you're wrong
20:57imirkin_: but they may explain how it all works in there
20:57imirkin_: which you may understand better now that you have some idea of what you're doing :)
20:59Lyude: imirkin_: understandable :p, so far the interesting bits I've spotted: CRC capture during snooze frames thing (no idea what a snooze frame is, docs don't seem to say unfortunately). The other, although skeggsb said they didn't think this actually worked on hw but I'd like to give it another shot still, this one line:
21:00Lyude: "This CRC notifier structure is complete, i.e. all requested CRC's have been written and the CRC notifier context DMA has been changed or made NULL_HANDLE."
21:00Lyude: that's regarding NV907D_NOTIFIER_CRC_1_STATUS_0_DONE, but the interesting bit of that sentence is "and the CRC notifier context DMA __has been changed__ or made NULL_HANDLE"
21:03imirkin_: so ... i suspect that the expectation is that you change crc notifiers on each vblank?
21:03imirkin_: and so you're supposed to alternate between a pair of notifiers
21:03imirkin_: (or some list of them)
21:03imirkin_: which effectively buffers the crc's
21:04Lyude: imirkin_: yeah, well I don't know that nvidia does it that aggressively. the reason I'm doing that in nouveau is because igt seems to expect CRCs be delivered asap and not have a limit of how many can be reported
21:04imirkin_: well, there's no limit if you make a ring
21:04Lyude: imirkin_: unfortunately I don't see any way of doing that :
21:04Lyude: the docs say it just drops crcs when the notifier fills
21:04imirkin_: just keep updating the notifier on vblank? dunno
21:05Lyude: yeah, that's my plan atm
21:05Lyude: I'm a bit surprised though, the docs gave me the impression we'd at least see the CRCs in the buffer immediately
21:06imirkin_: you really should
21:06imirkin_: it's not like the silicon has an infinite buffer to put those CRC's in
21:06imirkin_: (that'd be a neat trick...)
21:06imirkin_:is a big fan of universal turing machines
21:07Lyude: if there's not really a clean way to make this work for the current drm crc apis though, I'm sure we can look into changing it to make it a bit more nv friendly
21:07Lyude: erm, the CRC apis I mean
21:07imirkin_: once we figure out how nv works :)
21:08imirkin_: i suspect they may also be open to more direct questioning
21:08imirkin_: esp since the docs are effectively public
21:08Lyude: yeah, most likely
21:22uis: Can cuda core used by nouveau?
21:23imirkin_: nouveau supports compute, if that's what you mean
21:23imirkin_: however nouveau does not support the CUDA API
21:26codedmart: Lyude: I have a P1 gen 2.
21:26codedmart: Let me check the display again.
21:26Lyude: codedmart: ooh, interesting, that's probably why your backlight actually works by default then
21:29codedmart: Lyude: I got the 1920x1080 IPS 500 nits
21:30codedmart: Do you have a Quadro T1000?
21:31Lyude: codedmart: not sure what the marketing name fo rthis chip is :P, sorry
21:32codedmart: I thought the X1 gen2 and P1 gen2 came with different cards.
21:33Lyude: codedmart: mhhh, I should probably check then. mind showing me the dmesg from your nv issue btw?
21:33Lyude: codedmart: or the pci-id of your crd, that'd probably also be useful
21:33codedmart: Did I not share that? I need to reset some things. I was trying some stuff with the proprietary driver.
21:34Lyude: codedmart: oh you may, sorry, I forgot I still have that email from you
21:34Lyude: *you may have
21:36codedmart: Is this what you are after? https://gist.github.com/codedmart/29de5cf6fa162a797d842a484abf24cf
21:37Lyude: mhhh, I've got a different card in here but it'll probably still work for the same issue
21:43codedmart: That would be idea;
21:48codedmart: Reinstalling nouveau again so I can test things if need be.
21:52imirkin_: uis: out of the box, just opengl compute
21:52imirkin_: karol & co have been working on opencl support
21:53imirkin_: note that you can pretty much do anything you need with opengl compute, but the programming model may not be as convenient as with CUDA or OpenCL
22:35karolherbst: imirkin_: btw, if you don't find time to look at the RA patch, I would like to push it today
22:36imirkin_: clearly i don't
22:53karolherbst: imirkin_: yeah.. the issue is just that I don't like the solution, but I think any better solution just requires a bigger rewrite of RA, which actually has a higher chance of messing things up :(
22:53imirkin_: i don't like the solution either :)
22:54imirkin_: but i haven't looked at the details to see if there's a better one
22:54karolherbst: I think the proper solution would look like the RA rework we've talked about recently. Having a structure collecting all infos and just doing changes at the very end if RA knows what has to be done
23:01imirkin_: karolherbst: might be relatively easy to do. dunno.
23:02imirkin_: or might be a less destructive approach to storing the info we currently do
23:02imirkin_: (/ easier-to-destroy approach)
23:02karolherbst: the thing I am more worried about is affecting all shaders, vs affecting only shaers which spill
23:02imirkin_: yeah =/
23:04karolherbst: I mean, I am sure that the fix is correct, it simply a big ugly and a proper rework would allow us to remove it again
23:43Lyude: codedmart: it, might take me a day or two longer to get started on your issue because since I updated to f31, my primary text editor no longer works and now I'm trying to figure out what to do about that ;_;
23:49Lyude: oh-this is actually really terrible but i figured out a hack to work around this
23:49Lyude: guess we're LD_PRELOADing for a while
23:49HdkR: Lyude: Join the neovim team :D
23:50Lyude: HdkR: I really wish this was neovim that was broken because that would be so much easier to fix. unfortunately it's the GUI frontend to neovim that I usually use, which has broken due to some apparent API changes with pango so now it doesn't redraw its window properly
23:51HdkR: ah, gross
23:51Lyude: and the github issue for that has been open for 23 days now, and it's in rust so it's way more effort for me to fix things in since I don't know rust, so I don't think it's getting fixed for a little while
23:51Lyude:has not had a great day
23:51Lyude: especially since I use this editor for my job
23:52HdkR: Is the GUI frontend much better than using nvim directly in a good terminal?
23:53Lyude: HdkR: honestly 99% of the reason I use a gui frontend is because you can't use a pretty significant chunk of keybindings without it
23:54Lyude: like, you can't bind <C-BS> nicely outside of gui mode for instance
23:54Lyude: ...on that note if anyone knows how to override LD_LIBRARY_PATH or some such for a single binary on the system I'd be extremely grateful
23:55HdkR: huh, interesting