Branch pipe-format-simplify open for review

[michal-9]

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.

Thanks!

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Roland Scheidegger-4]

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...

Roland

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[michal-9]

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.

How severe is the gallium-noblocks change? I would like to avoid mergin
master into this branch.

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Tue, 2009-12-08 at 07:49 -0800, 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.
>
> How severe is the gallium-noblocks change? I would like to avoid mergin
> master into this branch.

Merging the master into this branch is exactly the same as merging this
branch into master. The only difference is that it allows people to
review the merge before landing into master. I don't know if it makes
much difference.

I reviewed the changes in the branch, and at least the changes to the
pipe interfaces and util module changes look good to me. This change was
on my wishlist, so thanks for going ahead and doing it.

Jose


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Roland Scheidegger-4]

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?

Roland

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Keith Whitwell-3]

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


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Younes Manton]

On Tue, Dec 8, 2009 at 9:55 AM, michal <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.
>
> Thanks!

The Nouveau stuff that you touched looks correct to me.

Any particular reason why the enums are explicitly numbered? I'd let
the compiler do the numbering for us unless there's a reason not to.
(Or is the intention here that future additions only happen at the
tail and we therefore implicitly threaten anyone considering otherwise
with the prospect of tediously updating all the entries that follow?
:) )

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Tue, 2009-12-08 at 08:33 -0800, Younes Manton wrote:

> On Tue, Dec 8, 2009 at 9:55 AM, michal <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.
> >
> > Thanks!
>
> The Nouveau stuff that you touched looks correct to me.
>
> Any particular reason why the enums are explicitly numbered? I'd let
> the compiler do the numbering for us unless there's a reason not to.
> (Or is the intention here that future additions only happen at the
> tail and we therefore implicitly threaten anyone considering otherwise
> with the prospect of tediously updating all the entries that follow?
> :) )

:) It's as you suspected in parenthesis -- to ensure that names<->values
mapping won't change, new values are added to the bottom, and old values
leave a hole.

Jose


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Christoph Bumiller-2]

michal schrieb:
> This branch simplifies pipe/p_format.h by making enum pipe_format what
> it should have been -- an enum.
>
> ...
>
> 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.
>  
Hi !
In nv50_vbo.c/nv50_vbo_type_to_hw you imply that  UTIL_FORMAT_LAYOUT_ARITH
means normalized (UNORM,  SNORM) and LAYOUT_ARRAY means SCALED, which
seems to be not the case.

PIPE_FORMAT_R32G32B32A32_SNORM for instance also has layout ARRAY.
I'm not sure what ARRAY/ARITH are supposed to mean ...

Anyway, you could probably base the check on channel[0].normalized,
since the formats used
for vertex elements are not mixed.
I still don't see how to distinguish SCALED and INT though, which at
some point will have
to indicate integer attributes ...

Christoph||
> Thanks!
> _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev@...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>  


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[michal-9]

Christoph Bumiller pisze:

> michal schrieb:
>  
>> This branch simplifies pipe/p_format.h by making enum pipe_format what
>> it should have been -- an enum.
>>
>> ...
>>
>> 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.
>>  
>>    
> Hi !
> In nv50_vbo.c/nv50_vbo_type_to_hw you imply that  UTIL_FORMAT_LAYOUT_ARITH
> means normalized (UNORM,  SNORM) and LAYOUT_ARRAY means SCALED, which
> seems to be not the case.
>
> PIPE_FORMAT_R32G32B32A32_SNORM for instance also has layout ARRAY.
> I'm not sure what ARRAY/ARITH are supposed to mean ...
>
>  

Thanks, I will fix that.

> Anyway, you could probably base the check on channel[0].normalized,
> since the formats used
> for vertex elements are not mixed.
> I still don't see how to distinguish SCALED and INT though, which at
> some point will have
> to indicate integer attributes ...
>
>  
Aren't those the same? What's the distinction between SCALED and INT on
NV hardware?


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Christoph Bumiller-2]

michal schrieb:

> Christoph Bumiller pisze:
>> michal schrieb:
>>  
>>> This branch simplifies pipe/p_format.h by making enum pipe_format
>>> what it should have been -- an enum.
>>>
>>> ...
>>>
>>> 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.
>>>      
>> Hi !
>> In nv50_vbo.c/nv50_vbo_type_to_hw you imply that
>> UTIL_FORMAT_LAYOUT_ARITH
>> means normalized (UNORM,  SNORM) and LAYOUT_ARRAY means SCALED, which
>> seems to be not the case.
>>
>> PIPE_FORMAT_R32G32B32A32_SNORM for instance also has layout ARRAY.
>> I'm not sure what ARRAY/ARITH are supposed to mean ...
>>
>>  
> Thanks, I will fix that.
>
>> Anyway, you could probably base the check on channel[0].normalized,
>> since the formats used
>> for vertex elements are not mixed.
>> I still don't see how to distinguish SCALED and INT though, which at
>> some point will have
>> to indicate integer attributes ...
>>
>>  
> Aren't those the same? What's the distinction between SCALED and INT
> on NV hardware?
>

Setting vertex attributes to SCALED does conversion from int to float,
UINT/SINT on the other hand provides them as 32 bit *integers* to the
vertex program (with appropriate extension, so it's not necessarily the
same as setting them to FLOAT).

What was the plan for VertexAttrib*I*Pointer (at that point where our
shaders actually use integers as integers) ?

Thanks, Christoph

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Tue, 2009-12-08 at 09:00 -0800, Christoph Bumiller wrote:

> michal schrieb:
> > This branch simplifies pipe/p_format.h by making enum pipe_format what
> > it should have been -- an enum.
> >
> > ...
> >
> > 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.
> >  
> Hi !
> In nv50_vbo.c/nv50_vbo_type_to_hw you imply that  UTIL_FORMAT_LAYOUT_ARITH
> means normalized (UNORM,  SNORM) and LAYOUT_ARRAY means SCALED, which
> seems to be not the case.
>
> PIPE_FORMAT_R32G32B32A32_SNORM for instance also has layout ARRAY.
> I'm not sure what ARRAY/ARITH are supposed to mean ...

I just documented UTIL_FORMAT_LAYOUT_*. It is really a subjective
attribute meant generating software (cpu) routines to translate pixel
to/from a format. It is quite likely this will grow/shrink with time.

Hardware drivers are better off using other more objective attributes in
util_format_description, or even PIPE_FORMAT_xxx names themselves.

> Anyway, you could probably base the check on channel[0].normalized,
> since the formats used
> for vertex elements are not mixed.
> I still don't see how to distinguish SCALED and INT though, which at
> some point will have
> to indicate integer attributes ...

Could you elaborate? At least u_format.h semantics are  that INT
describes how the bits should be interpreted into a value (integer as
opposed to floating point). SCALED concerns how those integer values
should be further interpreted, namely their range (0..1 or -1..1, in
opposition to INT_MIN..INT_MAX for the given bit width). I think it
covers all PIPE_FORMATS_xxx.

Jose


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Christoph Bumiller-2]

José Fonseca schrieb:

> On Tue, 2009-12-08 at 09:00 -0800, Christoph Bumiller wrote:
>> michal schrieb:
>>> This branch simplifies pipe/p_format.h by making enum pipe_format what
>>> it should have been -- an enum.
>>>
>>> ...
>>>
>>> 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.
>>>  
>> Hi !
>> In nv50_vbo.c/nv50_vbo_type_to_hw you imply that  UTIL_FORMAT_LAYOUT_ARITH
>> means normalized (UNORM,  SNORM) and LAYOUT_ARRAY means SCALED, which
>> seems to be not the case.
>>
>> PIPE_FORMAT_R32G32B32A32_SNORM for instance also has layout ARRAY.
>> I'm not sure what ARRAY/ARITH are supposed to mean ...
>
> I just documented UTIL_FORMAT_LAYOUT_*. It is really a subjective
> attribute meant generating software (cpu) routines to translate pixel
> to/from a format. It is quite likely this will grow/shrink with time.
>
> Hardware drivers are better off using other more objective attributes in
> util_format_description, or even PIPE_FORMAT_xxx names themselves.
>
>> Anyway, you could probably base the check on channel[0].normalized,
>> since the formats used
>> for vertex elements are not mixed.
>> I still don't see how to distinguish SCALED and INT though, which at
>> some point will have
>> to indicate integer attributes ...
>
> Could you elaborate? At least u_format.h semantics are  that INT
> describes how the bits should be interpreted into a value (integer as
> opposed to floating point). SCALED concerns how those integer values
> should be further interpreted, namely their range (0..1 or -1..1, in
> opposition to INT_MIN..INT_MAX for the given bit width). I think it
> covers all PIPE_FORMATS_xxx.
>
> Jose
>

I was just thinking about *real* integer "formats" that don't get
converted to floating point on input to VP or output to RT, that's
what I mean with SINT/UINT as opposed to SSCALED/USCALED.
Since we call the other formats the DXGI/DX10 way, we might do it
in that case too.

I realize the difference between SINT vs. SSCALED isn't how the
formats are to be interpreted, but instead how they are to be
treated (or conversely, how FP output register contents on nv50
are to be interpreted), so having both doesn't always make sense.

I suppose we could add an extra flag in RT and vertex element state
for that, and/or concern ourselves with this later, when it becomes
an issue.

Christoph

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[michal-9]

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?


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Keith Whitwell-3]

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev