[Mesa-dev] r600g: status of the r600-sb branch

[Vadim Girlin]

On 04/19/2013 07:23 PM, Henri Verbeet wrote:
> On 19 April 2013 16:48, Vadim Girlin <vadimgirlin at gmail.com> wrote:
>> In the previous status update I said that the r600-sb branch is not ready to
>> be merged yet, but recently I've done some cleanups and reworks, and though
>> I haven't finished everything that I planned initially, I think now it's in
>> a better state and may be considered for merging.
>>
>> I'm interested to know if the people think that merging of the r600-sb
>> branch makes sense at all. I'll try to explain here why it makes sense to
>> me.
>>
> Personally, I'd be in favour of merging this at some point. While I
> haven't exactly done extensive testing or benchmarking with the
> branch, the things I did try at least worked correctly, so I'd say
> that's a good start at least.
>
> I'm afraid I can't claim extensive review either, but I guess the most
> obvious things I don't like about it are that it's C++, and spread
> over a large number of < 1000 line files. Similarly, I don't really
> see the point of  having a header file for just about each .cpp file.
> One for private interfaces and one for the public interface should
> probably be plenty.

I thought about that, but I'm just not sure what would be a preferred 
way. I agree that a lot of small files don't look very good, on the 
other hand it makes all classes better separated and readable, that's 
why I was not sure which way is best. Of course I can merge some files 
together if it's preferable.

> I'm not quite sure how others feel about that,
> although I suspect I'm not alone in at least the preference of C over
> C++.

The choice of C++ (unlike in my previous branch that used C) was mostly 
driven by the fact that optimization algorithms usually deal with a lot 
of different complex data structures, containers, etc, and C++ allows to 
isolate implementation of all such things in separate and easily 
replaceable classes and concentrate on the logic, making the code more 
clean and readable.

> I also suspect it would help if this was some kind of logical,
> bisectable series of patches instead of a single commit that adds 18k+
> lines.

I haven't tried to keep it as a series of independent patches because 
during the development most changes were pretty intrusive and introduced 
new features, some parts were seriously reworked/rewritten more than one 
time, requiring changes in other parts, especially when intermediate 
representation of the code was changed. It was usually easier for me to 
simply fix the new regressions in the new code than to revert any 
changes and lose new features, so bisection wouldn't be very helpful 
anyway. That's why I didn't even try to keep the history. Anyway most of 
the code in the branch is new, so I don't think that the history of the 
patches that rewrite the same code few times during a development would 
make it more readable than simply reading the final code.

Vadim