Well I guess another solution would be to just call it directly from the place the dri_extennsion code initially was, i.e. in dri_create_context.
Roland On 08.03.2010 17:21, Jakob Bornecrantz wrote: > Calling dri code from src/mesa/state_tracker is not allowed since it > supposed to be independent of windowing systems. That said from what I > can see both driInitExtensions and driInitSignleExtension could be > folded into mesa core, I can't see anything "dri special" about them. > > Cheers Jakob. > > On 8 mar 2010, at 16.12, Roland Scheidegger wrote: >> Otherwise, looks good to me, but I'd prefer if someone more familiar >> with the extension handling code could give it a look. >> >> Roland >> >> On 08.03.2010 17:03, Marek Olšák wrote: >>> Alright, I will add driInitExtensions(ctx, NULL, TRUE) at the end of >>> st_init_extensions. Anything else I missed or is it OK? >>> >>> -Marek >>> >>> On Mon, Mar 8, 2010 at 4:25 PM, Roland Scheidegger >>> <srol...@vmware.com >>> <mailto:srol...@vmware.com>> wrote: >>> >>> On 08.03.2010 14:22, Joakim Sindholt wrote: >>>> On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote: >>>>> On 07.03.2010 20:26, Marek Olšák wrote: >>>>>> This branch is aimed to address the following issues: >>>>>> * Extensions are advertised in both st/mesa and st/dri, doing >>> the same >>>>>> thing in two places. >>>>>> * The inability to disable extensions in pipe_screen::get_param >>> because >>>>>> st/dri overrides the decisions of st/mesa. >>>>>> >>>>>> Here's the branch: >>>>>> http://cgit.freedesktop.org/~mareko/mesa/log/?h=dri-extensions >>> <http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=dri-extensions> >>>>>> The first commit moves the differences between st/dri and >>> st/mesa to the >>>>>> latter and removes dri_init_extensions from st/dri. It doesn't >>> remove >>>>>> any extensions from the list except for those not advertised by >>> pipe_screen. >>>>>> The second commit enables texture_rectangle by default in >>> Gallium. To my >>>>>> knowledge any Gallium hardware can do this and I suspect it was >>>>>> dependent on NPOT textures by accident. >>>>>> >>>>>> All this is of course tested with piglit and glean. >>>>>> >>>>>> Please review. In case it's not OK, please let me know what >>> needs to be >>>>>> done. >>>>> The second commit looks fine to me. >>>>> The first one, I'm not sure. Maybe that's ok, but if so I'm >>>>> wondering >>>>> why, since this skips all the mapping business driInitExtensions >>> did and >>>>> just sets the extension enable bits to true. At least I'm fairly >>> sure it >>>>> was needed in the past... >>>>> >>>>> Roland >>>> I believe airlied pointed out earlier that >>>> >>> >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=17ef1f6074d6107c167f1956a5c60993904c0b72 >>> fixed that problem. >>> >>> But even with that commit, all drivers still call >>> driInitExtensions at >>> least once, though the parameter list can be NULL. I don't see >>> that >>> happening here. >>> >>> Roland >>> >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Mesa3d-dev mailing list >> Mesa3d-dev@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
