[Mesa-dev] [PATCH 12/15] gallium: Add winsys loader for device enumeration and driver multiplexing.

[Jose Fonseca]

----- Original Message -----
> Christian König <deathsimple at vodafone.de> writes:
> >[...]
> > On 26.03.2012 17:20, Francisco Jerez wrote:
> >> Essentially it's an interface to enumerate the graphic devices
> >> that are
> >> present in the system (and by extension to create screens on them,
> >> enumeration alone is useless without having a way to do something
> >> with
> >> the devices you find).
> >>
> >> You're right that traditionally this hasn't been part of the
> >> winsys API,
> >> but the task is very tightly coupled with the underlying window
> >> system:
> >> to my innocent eyes it seems that it would make more sense to
> >> extend the
> >> winsys API with something like this.
> >
> > Well, they key point is that even if it is closely related to the
> > different window systems, it isn't a window system of its own!
> 
> Hm, I think we should first settle on what a winsys is. 

Kind of dated, but still relevant to this discussion:

  http://jrfonseca.blogspot.co.uk/2008/04/gallium3d-introduction.html

A lot changed since, but the layering concept has become even stronger than it was then.

On top of that, there is now the concept of a "target" (src/gallium/targets/foo), which is typically a dynamic library that links together consecutive layers (e.g., state tracker + pipe driver + winsys; or pipe driver + winsys)

> In my
> understanding it's a set of primitives that abstract the platform
> specific details of the implementation, where "details" include:
>  - device binding
>  - memory management
>  - command submission

> My proposal boils down to including "device enumeration" among these
> categories, because the implementation to use is going to be highly
> dependent on the specific platform and display architecture we're
> running on, e.g. it's not going to be the same when running on X/DRI,
> on
> the bare DRM device, on other operating systems...

I think the big disconnect here is that a "winsys" has the details you mention but is HW specific.

Therefore a module that loads something depending on the HW cannot possibly be a winsys.

Given your module talks about pipe_screen, it's either a state tracker, or a helper module that's used by state trackers.

Granted, the "winsys" name is not very en-lighting -- maybe "pipe driver backend" would be better --, but its role is clear nevertheless.

Jose