On Mon, 2009-01-26 at 11:30 -0800, Brian Paul wrote: > Keith Whitwell wrote: > > On Mon, 2009-01-26 at 10:10 -0800, Patrice Mandin wrote: > >> Hello, > >> > >> [Excuse me if it's not the right place to talk about Gallium, is > >> dri-devel a better place?] > >> > >> Last week I fixed a bug in nv30 gallium backend for nouveau, related to > >> GL_EXT_blend_equation_separate (and not GL_EXT_blend_func_separate as I > >> wrote in my commit), which seems to be a requirement for gallium > >> drivers, as visible in gallium-0.2 branch, > >> src/gallium/state_trackers/glx/dri/dri_extensions.c > >> > >> NV30 gpus (Geforce FX class) don't support it, so I would need to > >> remove it from the extension list; and maybe make it a PIPE_CAP_??? > >> like some other OpenGL stuff. > >> > >> My question are: is the current list of extensions for Gallium backend > >> fixed (specific requirements from some shader engines?), and must all > >> backend support said extensions? > >> > > > > This is a bit of a missing chunk of functionality. > > > > There are some queries that the pipe_screen interface exposes, and these > > could/should be used by the Mesa state tracker to figure out which > > extensions to turn on and off for a particular driver... but currently, > > we've just got some ugly bit of legacy code in each winsys which turns > > on a fairly arbitary list. > > > > Until the state tracker starts using queries to build the extension > > list, this type of bug will be common. > > > > If you're interested in figuring out how to do this, I think it'd be a > > great contribution to Gallium. I think this ties into but is not > > necessarily dependent on the code I've got in state_trackers/glx/dri > > which is a start on hoisting out a bunch of duplicated code from all the > > dri winsys's. > > Note that src/mesa/state_tracker/st_extensions.c has code which queries > the gallium screen to determine which GL extensions can be supported. > Perhaps that can be refactored and shared if the same thing is needed in > the GLX state tracker.
OK, looks like there's even less reason for the legacy code in the winsys modules than I realized. Keith ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
