06:49karolherbst: the PCIe bus isn't exactly fast
06:49karolherbst: also.. on some GPUs it's just pointless overhead (e.g. on unified memory architextures)
06:50karolherbst: but if that allows you to turn a blocking operation into a non-blocking one, there might be merit in doing that on demand (as some mesa drivers are doing internally)
14:32sima: jfalempe, you mentioned you're working on a v7 in reply to jani, but I'm not seeing that?
14:32sima: or did I look at the wrong series
14:33jfalempe: sima: I said if I do a v7 for other reasons, I will change the variable name.
14:34jfalempe: but I can do a v7 with only this rename, if you think it's better.
14:34sima: jfalempe, well more meaning should I review v6 or wait for v7?
14:35jfalempe: you can review v6, I've no v7 in preparation.
15:15tzimmermann: jfalempe, thanks for the review
15:15jfalempe: tzimmermann: you're welcome :)
17:01zamundaaa[m]: when I do multi gpu copies of buffers, is there any way to optimize it with damage tracking?
17:02zamundaaa[m]: I have a severely bandwidth restricted system here (eGPU), where copying the whole buffer from iGPU to eGPU gets me a max. of about 85 fps
17:03zamundaaa[m]: Very often, only small parts of the screen change though, so I implemented damage tracking with OpenGL and I get... 85 fps
17:04zamundaaa[m]: I basically just set glScissors for the changed rect(s), so only a 200x200 or so pixel area actually gets repainted in my test
17:04zamundaaa[m]: Am I doing something wrong, or is this just not expected to be any better?
17:10emersion: zamundaaa[m]: i wonder if the full buffer is still getting copied over...
17:10emersion: the driver doesn't even know which part is going to be sampled in advance
17:11emersion: if it knew, not sure there is logic to optimize this case...
17:11emersion: in the kernel
17:13zamundaaa[m]: You mean it copies the whole buffer from the iGPU to the dGPU, for me to then copy it again? Sounds... inefficient
17:22emersion: maybe MrCooper knows best what's up