Sharing surfaces and multiple drivers

[Brian Paul]

Jon Smirl wrote:
> On 4/30/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
> 
>>>This can be complex, create a software surface in RAM using SW mesa.
>>>Now you want to use it with an R200 context. The R200 context can't
>>>get to it. You need to use a SW mesa context to copy between system
>>>RAM and AGP space. Then the R200 one to get from AGP space to VRAM. Or
>>>maybe use the mesa context to copy directly to VRAM.
>>
>>EGL contexts and surfaces are created with respect to an EGLDisplay
>>connection.  An EGL context/surface created with one display can't be
>>used with another.
>>
>>I've been assuming that an EGLDisplay connection corresponds to a
>>graphics card/device.  So, moving/sharing surfaces between devices
>>isn't directly supported.
>>
>>Can you live without that feature for the time being?
> 
> 
> I'm not asking for automatic migration of a surface to another display
> if the display can't access it. If the display can't access it you
> would just get an error.
> 
> But I would assume that every hardware driver can copy a surface from
> VRAM to AGP/PCI space if asked to. Once in AGP/PCI space I would
> assume that Software MESA can then access the surface. SW mesa could
> then move the surface to where the other hardware can find it. The
> compositing manager would manually make the copy calls to migrate the
> surface.

I guess I'm not sure who's responsible for moving surfaces around.  SW 
Mesa in and of itself never does that kind of thing.  The closest 
analogy might be texture residency.  The OpenGL driver can move 
textures between RAM/VRAM/AGP depending on various memory constraints. 
  The glPrioritizeTextures() call can give hints about where to place 
textures in memory.  But today there's no explicit memory management 
API.  It's been discussed as an ARB project in the past but it never 
materialized.


> This would let the compositing manager then choose to render a window
> using hardware/VRAM and copy it to the other board or it could render
> the window using SW mesa and copy to each board.

I guess the key question is whether the compositor needs the ability 
to explicitly place surfaces/textures in various memories, or if we 
can leave it up to the drivers to do their best.

-Brian