WIP: EGL_KHR_partial_update support

This is a resurrection of Harish's EGL_KHR_partial_update series, with substantial interface rewrites and support for Gallium.

It removes the old DRI extension interface, which was only used to implement something similar to eglSwapBuffersWithDamage, and replaces it with a new interface which tags a partial-update region on to the drawable. The old series targeted a DRI context rather than a drawable, which made tracking more difficult: the partial-update region only applies to the winsys buffer, not to any user-supplied FBOs. It is also additional to the scissor region, rather than replacing it.

The series is marked WIP for several reasons:

• I couldn't sleep last night, so wrote this after waking up at 3am; it's probably very wrong in several places
• I don't have a working Raspberry Pi setup due to office move, so it's completely and utterly untested
• it was not immediately obvious to me where to track the region within Gallium; I went for pipe_resource as that seemed to be the most natural correlation to the DRIdrawable the region logically belongs to
• the Gallium implementation collapses the region into single-rect extents; it's not obvious to me how multiple rects would work with hardware, unless we dispatched one draw per rect ... ?

I have also written Weston support for EGL_KHR_partial_update, though the same caveats apply, i.e. completely untested.

Any feedback and suggestions on how to do it better are more than welcome.

/cc @anholt @eric @yuq825

added EGL gallium vc4 labels

mentioned in merge request wayland/weston!106 (merged)

mentioned in issue lima/mesa#59 (closed)

pipe_resource should only contain immutable variables. They can be read by multiple threads without locking. You need to find a different way to pass the scissor rectangle to the driver.

Thanks, that answers one of my questions at least! Do you have any good suggestions as to where else it should belong?

It's a tough question. You need to pass it through pipe_context somehow.

The easiest solution is to pass the context to dri2_set_damage_region and add pipe_context::set_resource_scissor(pipe, resource, &scissor). Then it's up to the driver how it wants to implement it, for example by having a per-context array of (resource, scissor) pairs, or by aadding fb_scissor into vc4_resource if @anholt doesn't care about multiple contexts and threads.

The more involved solution is to pass the scissor to st/mesa somehow and set it like any other scissor when the drawable is set in the framebuffer state.

Hm, OK. I'd thought it would be easier to move it out of the context, given that EGL has the specific knowledge of which region should be applied and when, and right now it doesn't communicate enough to either the Mesa / client API interface or the DRI interface to let it know which region should apply and when.

I don't think we need to worry about implementing support for multiple simultaneous contexts, since the text explicitly only applies to buffers from a winsys surface, and you can't have the same EGLSurface current in two contexts/threads simultaneously.

changed the description

OK. It looks like that a pipe_screen function that looks like the EGL function would be enough.

the Gallium implementation collapses the region into single-rect extents; it's not obvious to me how multiple rects would work with hardware, unless we dispatched one draw per rect ... ?

Well, I think this should depend on the renderer. For instance for tile-based renderers there's some pretty obvious things that can be done here; you can simply avoid updating tiles that are untouched by any damage-rects. So I doubt collapsing all regsions into a single rect isn't great for those renderers...

Right, Mali4xx GPU have to prepare a tile (16x16 block) render list for fragment stage. With accurate damage rect, lima can drop untouched tiles in the list to reduce render work.

Is the render list produced from userspace? Looking at a couple of drivers, it seemed to me like this would get dispatched directly from the VS/GP stage; whilst they do clip to a single scissor rect, this would mean dispatching one job per rectangle in the partial_update region.

Right, the render list is produced in userspace. More accurately, Mali4xx GPU will generate render command list for all tiles in the VS stage, then userspace driver need to prepare another list to only contain pointers to part of command blocks it wants FS to execute. So the job is dispatched once.

Oh, that's interesting, so you take the list, filter it and return it. I wonder if other hardware allows you to do that as well ...

closed