On Tue, 2009-12-15 at 05:36 -0800, michal wrote: > Keith Whitwell pisze: > > On Tue, 2009-12-08 at 08:16 -0800, Roland Scheidegger wrote: > > > >> On 08.12.2009 16:49, michal wrote: > >> > >>> Roland Scheidegger pisze: > >>> > >>>> On 08.12.2009 15:55, michal wrote: > >>>> > >>>> > >>>>> This branch simplifies pipe/p_format.h by making enum pipe_format what > >>>>> it should have been -- an enum. > >>>>> > >>>>> As a result there is no extra information encoded in it and one needs > >>>>> to > >>>>> use auxiliary/util/u_format.h to get that info instead. Linking to the > >>>>> auxiliary/util lib is necessary. > >>>>> > >>>>> Please review and if you can test if it doesn't break your setup, I > >>>>> will > >>>>> appreciate it. > >>>>> > >>>>> I would like to hear from r300 and nouveau guys, as those drivers were > >>>>> using some internal macros and I weren't 100% sure I got the conversion > >>>>> right. > >>>>> > >>>>> > >>>> Looks nice, though it is unfortunately based on pre gallium-noblocks > >>>> merge, so I suspect you'll get a conflict for almost every patch chunk > >>>> at least in drivers if you try to merge it... > >>>> > >>>> > >>>> > >>> I didn't touch pipe blocks -- I left the pf_getblock* and friends in > >>> pipe_format.h intact. > >>> > >> Yes, but you're bound to get lots of conflicts because you replaced for > >> instance pf_format_get_block with util_format_get_block whereas that > >> stuff is removed from master because pipe_format_block (and the > >> block/nblocksx/nblocksy variables in pipe_texture and pipe_transfer) are > >> gone completely. > >> I quickly tried a merge and there were conflicts in over 40 files - from > >> a quick glance though they should be trivial to resolve. And I don't > >> think there's too much hidden stuff which won't work any longer - just > >> let util_format_get_block die and it should probably work out ok. > >> > >> > >>> How severe is the gallium-noblocks change? I would like to avoid mergin > >>> master into this branch. > >>> > >> It's not really that severe, it just touched a lot of the same places in > >> drivers this change does. > >> btw, I also avoided merging master to feature branch when I merged > >> gallium-noblocks, and instead fixed up conflicts on merge to master (and > >> adpated stuff which needed changes later). Is there some policy for this? > >> > > > > Ian's video of Linus talking about merges may give some clues? > > > > > > > Keith, > > Do I have your ack on that branch and can go ahead and merge it back to > master? >
Yes, it looks good. I trust you've run through the mesa demos and similar basic testing - if so go ahead and merge. Keith ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
