23:35 Lyude: karolherbst: is there a way to get a vague idea of how much pci bandwidth is currently being used?
23:36 karolherbst: Lyude: you could configure the idle engine counter for PCIe
23:36 karolherbst: but if you are wondering: we are _terrible_ at making use of the bandwidth
23:36 karolherbst: so if the question is: do we use the bandwidth, the anser is: not even close
23:36 RSpliet: any idea why that is?
23:36 karolherbst: depends
23:37 karolherbst: for prime offloading something is just broken and we can't make use of all bandwidth
23:37 karolherbst: for some games we just push a lot of data through the bus
23:38 RSpliet: Might be overzealous synchronisation? Or just "forgot to enable bit X that configures arbiter Y more preferably"
23:38 karolherbst: might be
23:38 RSpliet: The prime off-loading thing that is
23:38 karolherbst: I know that nvidia gets quite close to make use of the bus
23:38 karolherbst: even with prime offloading
23:38 RSpliet: Watermarks that are set too low, stuff like that
23:38 karolherbst: I didn't look into that yet
23:39 karolherbst: I just know that if you increase the speed from 2.5 to 8.0, you get like 50% more bandwidth
23:39 karolherbst: or well.. "fps"
23:39 karolherbst: or something..
23:39 karolherbst: I think we should look into what sucks here, but I don't know
23:39 karolherbst: I just know that it does indeed suck
23:40 RSpliet: That's.... not necessarily bad. It just means the bottleneck is elsewhere from that point on.
23:40 karolherbst: Lyude: btw, code: https://github.com/karolherbst/nouveau/commits/pmu_counters_v4
23:40 karolherbst: RSpliet: ohh, for prime offloading pcie is not the bottleneck for sure, but something is just fisht
23:40 karolherbst: *fishy
23:41 Lyude: karolherbst: mhm, in this case we're going to be pretty bad using bandwidth since this is igt
23:42 karolherbst: yeah...
23:42 Lyude: but anyway i got bored and some tiling formats pass igt tests now
23:42 karolherbst: ahh, cool
23:43 Lyude: very unsure if most of this code is right lol, since it ended up looking easiest to use libdrm, but do gem allocation by hand (which would have required refcounting which would have been pretty painful to implement in igt considering nothing else does that in igt)
23:43 karolherbst: Lyude: just use a bufctx
23:45 Lyude: karolherbst: for bos?
23:45 karolherbst: yeah
23:45 karolherbst: bufctx has essentially bins you can fill and reset
23:46 karolherbst: at least I think they might be helpful here? dunno
23:46 Lyude: karolherbst: all I really need is a gem handle for a bo
23:47 karolherbst: mhh
23:47 karolherbst: that's nouveau_bo.handle, no?
23:49 Lyude: karolherbst: yes, but it's a lot easier in igt to avoid the whole nouveau_bo struct because all of the kms library stuff for igt expects whatever it's driver testing to return a new bo handle and pretty much nothing else. We could try keeping a list of bos with their associated nouveau_bo structs or look them up with the lookup commands in libdrm for nouveau, but there's not really a way to tell
23:49 Lyude: when we need to deref that handle because it's not being used. At least there isn't without reworking a lot of igt's libraries
23:50 karolherbst: ahh, I see
23:50 Lyude: plus the gem ioctl is pretty much one of the least complicated parts of the api, so it's not that much code
23:51 Lyude: for ce and stuff though
23:51 Lyude: oops
23:51 Lyude: *will be using libdrm for ce and such though I imagine