On 23/07/2020 21:32, Dave Airlie wrote:
I've got a 66 patch series here, does it have a cover letter I missed?
>
> Does it have a what is the goal of this series? Does it tell the
> reviewer where things are headed and why this is a good idea from a
> high level.
Chris sent it on one of the previous rounds upon my request - please see
https://www.spinics.net/lists/intel-gfx/msg243461.html. First paragraph
is the key.
This series of 66 is some other unrelated work which is a bit
misleading, but that the usual. :) Real amount of patches is more around
20, like that posting which had a cover letter.
The problem with these series is they are impossible to review from a
WTF does it do, and it forces people to review at a patch level, but
the high level concepts and implications go unmissed.
I've been reviewing both implementations so in case it helps I'll write
a few words... We had internal discussions and meetings on two different
approaches. With this in mind, I agree it is hard to get the full
picture looking from the outside when only limited amount of information
went out (in the for of the cover letter).
In short, core idea the series is doing is splitting out object backing
store reservation from address space management. This way it is able to
collect all possible backing store (and kernel memory allocations) into
this first stage, and it also does not have to feed the ww context down
the stack. (Because parts lower in the stack can therefore never try to
obtain a new buffer objects, or do memory allocation.)
To me that sounds a solid approach which is in line with obj dma_resv
locking rules.
And it definitely is not to be reviewed (just) on the patch-per-patch
basis. Applying all of it and looking at the end result is what is
needed and what I have done first before proceeded to look at individual
patches.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
