Basically we needed to enforce a strict layering between state-tracker, driver and winsys, so that everything that the state-tracker did would go through the driver level and have the driver be able to intercept that and inject whatever necessary behaviour at that level.
Previously, many of the buffer management functions bypassed the driver and landed directly in the winsys, which turned out to be a big problem if the driver needed to do something special with those functions. I think the svga device fell into this category. At this stage, the pipe_winsys struct was deprecated, and drivers have been encouraged to define their own winsys interfaces. Because we didn't want to disrupt all the drivers, we defined a layered implementation of the screen functions in terms of the old pipe_winsys entity, and hooked that up in r300, nvXX, softpipe, etc, in the hope that they would slowly migrate to a pure pipe_screen implementation. So far nobody has done that afaik, but sooner or later it would be good to clean this up. One thing that will probably happen sooner rather than later is that softpipe will stop using pipe_winsys as its backend interface and just turn to MALLOC() for allocations and have a winsys that only exposes scanout-buffer allocations. Keith ________________________________________ From: Corbin Simpson [mostawesomed...@gmail.com] Sent: Friday, January 29, 2010 11:05 AM To: Cooper Yuan Cc: Mesa3D-Development Subject: Re: [Mesa3d-dev] About buffer management functions in gallium On Fri, Jan 29, 2010 at 1:44 AM, Cooper Yuan <coopery...@gmail.com> wrote: > Hi Corbin, > I noticed that functions related to buffer management, for instance, > pipe_create, surface_buffer_create, buffer+map, buffer_unmap, have been > defined in both pipe_winsys and pipe_screen. > Actually, we set this function pointer as our implementation, for example, > radeon_surface_buffer_create, only in pipe_winsys. > Would you tell me why there are two function pointer sets in both > pipe_winsys and pipe_screen and what's the intention. > Cooper (CCing people who can probably answer better than me.) Hi Cooper, All of the buffer management and fence handling used to be only in pipe_winsys back in Gallium 0.1, and the winsys was accessed directly from its pointer in pipe_screen. That's just the way it was. At some point during Gallium 0.2, these got copied to pipe_screen, and a simple helper called u_simple_screen got introduced. u_simple_screen wraps a pipe_winsys and handles the accesses through pipe_screen. So, if you call e.g. buffer_map on the pipe_screen, it calls u_pass_buffer_map which calls buffer_map on the pipe_winsys. I don't know *why* this is. It's made our lives easier though, so I'm not really arguing against it. Take it easy, ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
