[Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

[Gurkirpal Singh]

On Mon, Aug 14, 2017 at 5:04 PM, Christian König <christian.koenig at amd.com>
wrote:

> Am 14.08.2017 um 11:46 schrieb Julien Isorce:
>
> Hi Leo,
>
> >It would be better if you can extract the common code between bellagio
> and tizonia to avoid the duplication.
>
> This is something Gurkirpal and me discussed, like having
> state_trackers/omx/common, state_trackers/omx/bellagio,
> state_trackers/omx/tizonia. To anticipate that Gurkirpal sent an email
> https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg153562.html
> during the Community Bonding period in May (a few weeks from the date
> (early May) students are officially accepted to the date (end May) where
> student actually starts working)
>
> The problem with the directory layout above is that it would look like it
> will be built together in the same shared library. This is not good because
> it is suppose to export OMX_ComponentInit for each target. Of course this
> would still be possible to have 2 shared libs but I believe in
> state_trackers dir, all sub dir are for one target. Also we were afraid
> that there would be other limitations so we decided to go for a separate
> directory.
> And since there were no objections in Gurkirpal's mail above we went this
> way.
>
> Now if I look into state_trackers/omx_tizonia, in fact the common code
> with state_trackers/omx_bellagio does not have anything to do with omx. For
> example "slice_header". Maybe it can be moved to gallium/auxiliary/vl/ like
> it is done already for vl_rbsp_init. Same for omx_get_screen.
>
>
> Yeah, completely agree.
>
>
> So I suggest this 'factorization' to be not a blocker for merging
> state_trackers/omx_tizonia into usptream. But later on we can move
> gradually bits from state_trackers/omx_bellagio to gallium/auxiliary. And
> then make state_trackers/omx_tizonia use it as well.
>
>
> I would really prefer the other way around, e.g. re-factor first and then
> merge.
>
> This way you will only bother about maintaining
> state_trackers/omx_bellagio the time being. This also allows to not slowly
> get its work lost.
>
> Of course we would have done differently if we knew advance. But as today
> Gurkirpal won't have enough time to do this factorization/move as the
> project ends in 1 week. Having all of this merged in upstream is not
> mandatory to succeed the project but Gurkirpal will need some rest after
> these 3 months of hard work. And who knows what happens after, whether he
> will still be around after sometimes or not. And this is entirely up to him.
>
> So again I suggest this factorization/move not to be a blocker for the
> reasons above. What do you think?
>
>
> As I wrote above I would rather prefer that this deduplication happens
> before the merge, but that Gurkirpal doesn't have much more time for
> working on that is a good argument against it.
>
> BTW: What is Gurkirpal doing after his GSoC project?
>
After project completion I plan to continue working on adding the rest of
the components not without support about gstreamer related stuff. Also I
won't be able to put that much time into it as during the project so the
progress might be a bit slow.

>
> Regards,
> Christian.
>
>
> Thx
> Julien
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170814/b19f7314/attachment.html>