On Mon, Apr 26, 2010 at 6:54 PM, Keith Whitwell <kei...@vmware.com> wrote: > On Sat, 2010-04-24 at 07:25 -0700, Jakob Bornecrantz wrote: >> Hi Chia-I et all >> >> This Patch series does some minor refactoring in the st_api interface >> and some major one to st/dri. >> >> The first patch drops the st_module struct from st_api. This is because it >> was overlapping the st_api struct. Both represent the API. It also drops some >> extra symbols and instead just exposes a single st_api_create_* function to >> get the st_api struct from the state tracker. >> >> The following five patches refactor st/dri and removes some defines in favour >> of hooks on dri_screen. And instead of allocating a separate struct for >> st_manager and st_framebuffer makes them a base for dri_screen and >> dri_drawable. And finally moves the code from dri_st_api.c into dri_screen.c >> and dri_drawable.c. > > I've got some issues with the naming of these various state-tracker > level components. > > First up, API is crazy - this is not an application programming > interface. Applications don't have a clue about this, it's buried deep > inside the driver. > > Secondly, to label things st_XXX is probably misleading as it makes it > appear as if these components are universal to state trackers, or that > all state trackers must somehow use/conform to them. > > Can you think about what this code is really implementing & try to come > up with a better set of names for these components? Though not entirely true in current implementation, st_api.h is an interface between a manager and its dlopen()ed modules. Different modules provide different Khronos-style rendering APIs.
Most of the interface is described using Gallium types (pipe_context, pipe_texture, ...). The manager and the modules are naturally implemented as state trackers. But the interface has nothing to do with a state tracker. It is somewhat more like dri_interface.h in that driDriverAPI -> st_api_create_OpenGL __DriverAPIRec -> st_api __DRIscreen -> st_manager Maybe we can find a new namespace for the interface, and drop the "_iface" suffix of st_framebuffer_iface and st_context_iface. "struct st_api" describes the interface of an API module. It may be renamed to st_api_provider or st_module. -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev