02:02 karolherbst: I should go to sleep.. https://gist.github.com/karolherbst/f08a7c4cb66276e5a538ddc3f79c4e9d
02:02 karolherbst: but it seems like I found a way to get the process name of the thing creating the channel
16:29 karolherbst: pmoreau: mind forking https://gitlab.freedesktop.org/drm/nouveau and see how long it takes?
16:35 karolherbst: so uhm...
16:35 karolherbst: anybody up for reviewing the dead channel stuff?
19:07 pmoreau: karolherbst: Forking in progress
19:14 pmoreau: The dead channel work looked relatively straightforward, but I have never looked at IOCTLs so I would not be able to say whether adding such an IOCTL or doing it differently would be a good idea.
19:17 karolherbst: pmoreau: I am not adding an IOCTL
19:17 karolherbst: mesa/drm is libdrm
19:18 pmoreau: “IOCTL wrapper”, sorry
19:19 karolherbst: yeah well.. than I guess nobody reviews anything anymore ¯\_(ツ)_/¯ maybe I can convince skeggsb :/
19:21 pmoreau: And done for the forking, so something like 10–15 minutes.
19:22 karolherbst: shit
19:25 pmoreau: Is yours still going on?
19:28 pmoreau: Given that I am not sure how much longer I will be able to contribute to Nouveau and that my time until the end of the year will be quite limited (and would still like to try to wrap the NV50 OpenCL stuff before that, or as much as possible), I do not plan on diving in new areas to get the knowledge to review patches there, sadly.
19:28 karolherbst: nope, I've already done it months ago
19:28 pmoreau: Ah ok :-D
19:28 karolherbst: but bentiss said he was working on speeding it up so it should be done in an instant
19:28 pmoreau: Nice!
19:29 karolherbst: anyway.. getting close to have a process defined and acked to accept MRs through gitlab
19:29 karolherbst: it just would be super annoying if cloning takes hours
19:29 karolherbst: or minutes
19:30 karolherbst: pmoreau: mhh.. I think your fork is disabled now or did you set it to private on purpose? :D
19:30 pmoreau: The default when forking was to make it private, and I didn’t change that. 😅
19:30 karolherbst: ahh
19:31 pmoreau: Should be public now
19:31 karolherbst: right.. I limited forks to project members, thought that did something
19:32 pmoreau: I might be a member though
19:32 karolherbst: you aren't :)
19:32 pmoreau: Unless you kicked me out 😭 :-p
19:32 karolherbst: you are member of the nouveau group :D
19:32 karolherbst: but not of drm/nouveau
19:32 pmoreau: And isn’t the group a member of drm/nouveau?
19:32 karolherbst: nope
19:33 karolherbst: mhhh
19:33 karolherbst: let me try something
19:33 karolherbst: the group should be allowed to deal with issues
19:33 karolherbst: ohh wait
19:33 karolherbst: the nouveau group is "reporter"
19:33 karolherbst: what ever that means
19:34 karolherbst: pmoreau: can you edit issues, set labels or something?
19:34 pmoreau: Yup, I could change labels
19:34 karolherbst: ahh okay
19:34 karolherbst: that's good enough then
19:34 karolherbst: then everything is setup correctly
19:34 pmoreau: https://docs.gitlab.com/ee/user/permissions.html
19:34 karolherbst: yeah.. but we have ce
19:35 karolherbst: but yeah
19:35 karolherbst: that part might be identical
19:35 karolherbst: the problem is just that we really really want to limit who can accept MRs or limit the rules or something.. :/
19:36 karolherbst: pmoreau: btw.. how many mesa commits do you have? :D
19:37 pmoreau: Approving (and assigning) merge request seems to be limited to developer and above.
19:37 karolherbst: yeah
19:39 karolherbst: pmoreau: 81 commits in mesa if I count correctly?
19:40 pmoreau: 81 commits in main apparently 👀 damn, it did go up with all those 10-, 20-commit series!
19:41 karolherbst: pmoreau: I think you would get access to mesa, but I don't know the strict rules :D
19:41 karolherbst: in case you want to be able to merge stuff on your own
19:41 pmoreau: Wasn’t it something like 20 or 40 commits?
19:42 karolherbst: no clue :D
19:43 pmoreau: I don’t mind waiting for someone else to merge it for me, and as I said earlier I am not too sure how much longer I will be around. Let’s see first where I will end up next year and how that affects me contributing to Nouveau, and then I will ask for access. :-)
19:46 pmoreau: karolherbst: Regarding the max allocation size, what would you like Nouveau to return in that case? I wasn’t sure if by “old value” you meant the original `1ULL << 40`, or `dev->vram_size`.
19:47 karolherbst: yeah.. so... technically you can just allocate that much and hope for the best, sometimes it makes sense, sometimes not? dunno, but I think returning vram_size is the best idea for now unless there is a strong reason to really return the vm limit
19:50 pmoreau: I would agree with just returning vram_size, that would simplify things I belive.
19:51 pmoreau: I’ll change back my commit to what I had before then.
22:42 pmoreau: Why is RA like: “Nope, I am not going to give that temporary register an actual register, deal with it.” 👀
22:46 pmoreau: Trace can be found here (https://gitlab.freedesktop.org/pmoreau/mesa/-/snippets/2607), and %r106 is the one being ignored by RA for whatever reason.
23:13 karolherbst: pmoreau: because RA is just broken
23:14 karolherbst: pmoreau: ehh...
23:15 karolherbst: I am sure it has something to do with moving 0
23:15 karolherbst: normally we assign max reg to values containing 0
23:15 karolherbst: but I guess for weird reasons RA don't do it for those stores
23:15 karolherbst: *doesn't
23:16 pmoreau: I had done a mistake where I was telling the store “the input is a 16-bit value” but actually giving it a 32-bit value. Fixing it didn’t help though.
23:16 karolherbst: yeah.. check the zero reg handling
23:16 pmoreau: Mmh, let me try initialising it to something else than 0.
23:18 pmoreau: Nope, same issue with 1
23:19 karolherbst: weird....
23:19 karolherbst: well
23:19 karolherbst: RA does pick it up.. let's see
23:20 pmoreau: Could it be RA somehow assuming the constant could be folded into the store, and therefore deciding not to allocate a reg for it?
23:20 karolherbst: no
23:20 pmoreau: But given how there are specific passes for that way before RA runs, I don’t see why it would care about it.
23:20 karolherbst: mhh
23:20 karolherbst: "edge: (%103, deg 2/15) >-< (%106, deg 0/33)"
23:20 karolherbst: what does this 0 mean
23:21 pmoreau: Yeah, I saw that too. And your guess is as good as mine, most likely better even. :-D
23:21 karolherbst: yeah...
23:21 karolherbst: its the coloring stuff
23:22 karolherbst: ohhhhhh
23:22 karolherbst: pmoreau: force a 32 bit value
23:22 karolherbst: not 16
23:22 pmoreau: It’s the mistake I pointed out earlier and fixed, and no change
23:23 karolherbst: so you store a 32 bit value?
23:23 karolherbst: doing a 32 bit store
23:23 pmoreau: Yup, let me update the snippet
23:24 karolherbst: are sure the _value_ is 32 bit as well?
23:24 pmoreau: I’ll double-check that; snippet should now be updated to the latest version.
23:24 karolherbst: you can't see what size a value has
23:25 pmoreau: I can use a debugger and find it out though, which is what I’m doing atm.
23:25 karolherbst: okay
23:25 karolherbst: just making sure
23:26 karolherbst: anyway.. that degree stuff is related to how much storage a value taks
23:26 karolherbst: and 1 means "1 value"
23:26 karolherbst: which for nv50 means a 16 bit one
23:26 karolherbst: 2 == 32 bit reg
23:27 karolherbst: but then you have weird RA constraints and shit
23:27 pmoreau: How did it get a size of 1…
23:27 karolherbst: because the nir constant is 8 bit
23:28 pmoreau: Sure, but I’m quite certain you have a constraint to only allocate 32-bit values. Or that I added one, in case you hadn’t already.
23:28 karolherbst: there is this huge item on my todo list: 8/16 bit nir lowering :)
23:28 pmoreau: :-)
23:28 pmoreau: u2u16 is on my list of missing things, as it gets hit by the basic CTS test
23:28 karolherbst: pmoreau: Converter::convert(nir_load_const_instr *insn, uint8_t idx)
23:29 karolherbst: force getSSA(2) for the 8 case
23:29 pmoreau: Oooh
23:29 karolherbst: or try 4...
23:29 karolherbst: but 2 should be good enough
23:29 karolherbst: yeah..
23:29 karolherbst: hence me asking for the Value :D
23:29 pmoreau: Right, so that by-passes all constraints on registers if there is a special case for constants
23:29 pmoreau: 🙃
23:29 karolherbst: yep
23:31 pmoreau: That’s a lot better, thanks! Though the test still fails :-D
23:33 karolherbst: I think the first goal would be to get the nir path to not have any regressions for GL and GLES on nv50 :D
23:35 pmoreau: That would be nice.
23:37 pmoreau: Found two other places where `getSSA()` was called with a value potentially below 4 for GPRs.
23:38 karolherbst: yeah...
23:38 karolherbst: we really should do proper 8/16 lowering on a nir level
23:38 karolherbst: we even have the passes for it