On 9/9/20 3:07 AM, Dmitry Osipenko wrote:
05.09.2020 17:53, Mikko Perttunen пишет:
...
Hello, Mikko!
What do you think about to open-code all the host1x structs by moving
them all out into the public linux/host1x.h? Then we could inline all
these trivial single-line functions by having them defined in the public
header. This will avoid all the unnecessary overhead by allowing
compiler to optimize the code nicely.
Of course this could be a separate change and it could be done sometime
later, I just wanted to share this quick thought for the start of the
review.
Hi :)
I think for such micro-optimizations we should have a benchmark to
evaluate against. I'm not sure we have all that many function calls into
here overall that it would make a noticeable difference. In any case, as
you said, I'd prefer to keep further refactoring to a separate series to
avoid growing this series too much.
The performance difference doesn't bother me, it should be insignificant
in this particular case. The amount of the exported functions is what
makes me feel uncomfortable, and especially that most of those functions
are trivial.
I don't see a particular problem with this -- I think it's better to
keep the data structures in the driver-internal headers to to improve
modularization. I think we can get rid of the syncpt_get_by_id*
functions once we remove the staging code, so that would clean up things
as well.
My concern is that doing cleanups of the upstream drivers usually not
easy. Hence it could be a good thing to put effort into restructuring
the current code before new code is added. But at first we need to have
a full-featured draft implementation that will show what parts of the
driver require refactoring.
My feeling is that once we have the new UAPI implemented, refactoring
will be easier because we have a better idea of what we need of the
code, and we will be able to remove the staging code, allowing removal
or easier refactoring of many old paths.
While doing that, some of the new code will have to be changed again as
well, sure, but at least the entire time we will have a functional
implementation.
Mikko
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
