08:12 tagr: skeggsb: thanks for testing, I'll send out a proper patch soon
13:43 karolherbst: okay so.. uff
13:44 karolherbst: runpm + gdb = fail
15:25 imirkin: tagr: wow, you've been busy!
15:59 tagr: imirkin: there's more where that came from =)
15:59 tagr: imirkin: I've also revived my sync FD series that will allow Tegra DRM and Nouveau to work together to support implicit synchronization
16:00 tagr: which will make kmscube -A work
16:00 tagr: imirkin: just need to clean up the series and push out rebased userspace changes (there's a libdrm and a Mesa patch that go with it)
16:01 tagr: there's a tiny bit of new ABI, which it a bit of churn for something that's actually pretty tiny
16:01 tagr: but I don't really see a way around it
16:02 tagr: might be useful to hold the ABI change back and roll it into something bigger, but I'm not sure if anything's in the works
16:02 tagr: the ABI is mostly compatible with the current PUSHBUF IOCTL (it's uncreatively named PUSHBUF2 =) and layered on top, so it's not actually that bad
16:05 karolherbst: tagr: uff.. pushing for a new interface is always troubling :/
16:05 karolherbst: usually we need to merge the mesa changes first or... something?
16:05 karolherbst: there is something stated in the drm document as we really don't want to go through the pain to support something for many years
16:06 karolherbst: and figure out a year later that the interface isn't worth it
16:06 karolherbst: or broken or whatever
16:06 karolherbst: tagr: anyway, skeggsb is working on a new interface. You might want to sync up with him
16:07 tagr: karolherbst: I understand that, but on the upside I do have the libdrm and Mesa changes and this is for implicit synchronization, so it's fairly mainstream
16:07 tagr: yeah, if skeggsb has anything that we could roll this into, that'd be preferable of course
16:08 tagr: I'll likely just refresh everything I have and send out the series, then we can discuss about how best to move this forward
16:08 karolherbst: but yeah.. I am also working on moving libdrm into mesa to fix the outstanding multi context issue...
16:08 karolherbst: and it's quite painful
16:08 karolherbst: yeah.. sending them out is probably the best
16:09 tagr: are you trying to actually move libdrm into Mesa, or just replace libdrm usage in Mesa by direct IOCTL usage and duplicating whatever infrastructure is present in libdrm_nouveau?
16:09 karolherbst: replace
16:09 karolherbst: because I actually want to change the interface
16:09 karolherbst: and libdrm does annoying bits internally
16:09 tagr: mhm... I see how that would be a bit tedious
16:10 tagr: fortunately something you only have to do once, though
16:10 karolherbst: hopefully
16:10 tagr: it'd still be interesting to have something lower-level than Mesa around for basic testing, though
16:10 karolherbst: ohh, it won't be part of gallium
16:10 karolherbst: and only depends on libdrm actually
16:10 karolherbst: so it should be fairly easy to use for other stuff
16:11 tagr: it's going to take me a while before I get gv11b support far enough (if I actually do get past secboot at all =) to make use of Mesa
16:11 karolherbst: we don't support volta anyway
16:11 karolherbst: or turing
16:11 tagr: shouldn't it be possible to run at least some basic rendering with the existing driver?
16:11 karolherbst: new ISA
16:12 tagr: ah... bummer
16:12 karolherbst: and quite incompatible
16:12 karolherbst: it's not just new encodings
16:12 karolherbst: but the entire c/r stack was reworked
16:12 karolherbst: (or removed?!?)
16:13 karolherbst: and gr/compute are also different :)
16:13 karolherbst: and turing is different as well for the classes... at least the ISA stays the same compared to volta
16:13 tagr: not sure I can convince anyone to let me work on the ISA...
16:13 karolherbst: skeggsb already has patches
16:14 tagr: not that I had even the faintest idea about any of that
16:14 karolherbst: but he wants to figure out secboot on turing first
16:14 tagr: okay, one thing at a time
16:14 karolherbst: tagr: write a smart script pushing bits through nvdisasm -> congrats, you jut got the entire ISA :p
16:15 karolherbst: the ISA is indeed the trivial part
16:15 tagr: you still have to put things back together in Mesa, right?
16:15 karolherbst: the gr/compute classes are more annoying + writing the actual code
16:15 tagr: hmm... didn't somebody from NVIDIA publish class documentation for these? or was this only for display?
16:16 karolherbst: let me check
16:16 karolherbst: it's usually only displays + compute
16:16 karolherbst: yep
16:16 karolherbst: graph is way too much I think
16:16 karolherbst: there isn't much going on in the compute class..
16:16 karolherbst: it's actually not that big
16:44 HdkR: karolherbst: CRS was removed
17:03 karolherbst: okay, then it was removed :)
17:05 HdkR: It doesn't make as much sense with the new threading model
17:06 HdkR: (Although it could have been nice to still receive a "free" mask handling mechanism)
17:07 karolherbst: I never actually looked into compiled code with a complex CFG actually
17:07 karolherbst: maybe I should
17:07 karolherbst: or maybe not
17:07 karolherbst: depending on how much it will damage my sanity
17:07 HdkR: It won't be that bad
17:08 HdkR: It's way easier to track the CFG than previous archs
17:08 karolherbst: three nested loops was already bad enough on older gens
17:08 karolherbst: or rather the loop merging opt nvidia did
17:08 karolherbst: and honestly.. I don't look forward to ever implement that in codegen
17:08 HdkR: :P
17:09 karolherbst: I'd rather add if/else trees in nir than attempting any magic in codegen
17:10 HdkR: nir_nv instructions? :P
17:11 karolherbst: huh, why?
17:11 HdkR: Would anyone else actually benefit from if/else being described in the IR?
17:12 karolherbst: I am sure loop merging is worth it
17:12 karolherbst: on every arch
17:12 karolherbst: just.. I am sure you have a hard time finding people being insane enough to actually implement it.. even though, loop merging isn't that complicated
17:13 karolherbst: just looking at the shaders is
17:13 HdkR: Loop merging doesn't directly rely on if/else does it?
17:13 karolherbst: it does
17:13 karolherbst: well
17:13 karolherbst: you predicate instructions in the fully optimized shader
17:13 karolherbst: but
17:14 karolherbst: loop merging is more of a path selection kind of thing
17:15 HdkR: I guess I'm thinking of the wrong kind of loop merging or the constraints incorrectly
17:16 karolherbst: well.. instead of doing nested loops, you merge them into one loop
17:17 HdkR: oh! Nested loop merging, okay, I was thinking independent loops :P
17:17 karolherbst: ahh, no
17:17 karolherbst: that's boring :D
17:17 HdkR: THat makes way more sense of being annoying
17:18 karolherbst: it's a good way to reduce pressure on the crs....
17:19 karolherbst: I am sure that's one huge reason why some games run like shit on nouveau
17:19 HdkR: I could see that
17:20 HdkR: You'll still have stack woes on Volta+ in this instance though
17:20 karolherbst: HdkR: ever wondered if there are actually shaders using 7 predicates? :D
17:20 HdkR: Oh definitely, I've generated them before
17:20 karolherbst: ahh
17:21 HdkR: It's not terribly difficult but usually doesn't happen
17:23 HdkR: Spilling a predicate is always fun to see happen