On 17/9/20 19:13, Jason Ekstrand wrote:
One more comment:  Could you make a big WIP MR with the whole driver
to act as a pointer to the branch for now?

Here you are:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766


  Then it can be the thing
that gets merged once the stuff in a and b land.


Trying to make things easier, I listed the commits for the a) and b) categories:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766#note_628333


I hope those links makes skim them easy (and provide feedback about which MR to create)



--Jason

On Thu, Sep 17, 2020 at 12:10 PM Jason Ekstrand <ja...@jlekstrand.net> wrote:
Good work, all!  I'm super-happy to see another Vulkan driver land in Mesa.

On Thu, Sep 17, 2020 at 8:52 AM apinheiro <apinhe...@igalia.com> wrote:
Our development branch is ~525 patches on top of master, categorized as follows:
    a) Patches that touch common Mesa infrastructure (NIR, Vulkan WSI, Meson, 
etc):  ~5 patches.
    b) Patches that touch common Broadcom infrastructure under src/broadcom 
(V3D backend compiler mostly): ~20 patches
    c) Patches that are independent and specific to the V3D Vulkan driver 
(under src/broadcom/vulkan): ~500 patches.

Since we are talking about a very large amount of patches, we are expecting 
that we can merge most of them without a review, particularly those in c) that 
implement the bulk of the Vulkan driver.
I think that's fine.

The patches in b) are mostly about extending our compiler backend to support 
Vulkan intrinsics and requirements as well a a few more general fixes or 
improvements. Our plan is to at least have someone in our team review them 
internally and grant Rbs, I think the only other person who might want to 
review these would be Eric if he has the time and is interested in doing so. We 
have sent some of these for early review [1][2] when we found they were more 
generic fixes or improvements to the compiler, but we might not want to do this 
for each and every one of them unless we see there is interest in reviewing 
them separately.
An ACK from Eric or someone other v3d devs would be good.  Not my
area, though, so I'll let others talk.

For the patches in a) we would like to at least get an Ack from other Mesa 
devs. They are mostly very simple things that just add an option to a NIR pass 
or a new intrinsic for use in our driver backend, so maybe it is not needed to 
create dedicated MRs and it is fine to just ping specific Mesa devs for reviews 
on those patches when we propose the large MR for the bulk of the driver. We 
did send one of these as an RFC some time ago [3] and it would be nice to get 
some more feedback there if possible.
I'd definitely like to see the patches in a) get real review.  I don't
know how many MRs you want to make there; do what makes sense.

Does all this sound sensible?
Yup.

--Jason
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to