00:39 <sarbes> Thanks, that's good to know. It would be nice to shave off some few ms when uploading 1920x1080 textures. Such assets are already retrieved/decoded asynchronously, the animation system accounts for that. And it can easily wait a frame or two longer.

00:41 <sarbes> We are doing lord knows what in our main (rendering) thread. So a bit of relief is most welcome.

01:04 <sarbes> Anyway, I'm out for the night. I would really appreciate some more input, I'll be reading the log. Thanks a bunch!

09:00 <tomeu> sarbes: btw, this is what panfrost does when preparing to copy a texture: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/panfrost/pan_resource.c#L940

14:53 <sarbes> tomeu: Nothing wild as far as I can see. The AFBC path should be chosen most often, blitting the application supplied texture to a staging texture. When unmapping, the actual AFBC texture is created. I guess 1) won't be much slower than blitting. So far so good.

15:01 <sarbes> What I'm struggling with is to see how different glBufferData usage hints get through. One could assume that GL_STREAM_DRAW would use linear textures, GL_DYNAMIC_DRAW would use tiled textures and GL_STATIC_DRAW would use AFBC textures

15:06 <tomeu> panfrost doesn't seem to do much atm:

15:06 <tomeu> [tomeu@cizrna mesa]$ git grep PIPE_USAGE src/gallium/drivers/panfrost/

15:06 <tomeu> src/gallium/drivers/panfrost/pan_resource.c: if (pres->base.usage == PIPE_USAGE_STREAM)

15:06 <tomeu> src/gallium/drivers/panfrost/pan_resource.c: return can_tile && (pres->base.usage != PIPE_USAGE_STREAM);

15:06 <tomeu> you can check what other gallium drivers do

15:22 <sarbes> And that's fine. But for some reason, mutable buffers seem not able to use PIPE_USAGE_STREAM https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/mesa/main/bufferobj.c#L234. PIPE_USAGE_STAGING is used instead.

15:28 <sarbes> Of course, there could be a reason behind it. That's why I was asking 3) yesterday. The related PR talks a bit about a shortcut for radeonsi (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1929?commit_id=7f6b9baee2dde4acecf38e77758d379fc249daf9).

16:00 <alyssa> stepri01: Do we have a real use case for devfreq with multiple supplies?

16:00 <alyssa> AFAIK, that necessarily requires vendor-specific coupling code

16:00 <alyssa> historically that's been shoved in a kbase vendor folder (downstream of downstream...) but that's not necessarily a pattern for us to emulate

16:01 <alyssa> MediaTek needs multiply supplies (and carries a pile of kbase vendor code for devfreq)

16:02 <alyssa> A colleague of mine is working on an alternative approach, where soc/mediatek gains a special driver to couple the extra sram supply to the main mali supply, and then panfrost uses the regular 1-supply code without any special considerations

16:02 <alyssa> I don't know if that's better or worse, but it gets vendor code out of my subsystem ;-)

16:02 <alyssa> https://patchwork.kernel.org/project/linux-mediatek/patch/20220628110128.64137-1-angelogioacchino.delregno@collabora.com/