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

Reply via email to