On 04/19/2013 07:23 PM, Henri Verbeet wrote:
On 19 April 2013 16:48, Vadim Girlin <vadimgir...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
