Re: [Mesa-dev] Plan for merging v3dv in mesa
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 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 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
Re: [Mesa-dev] Plan for merging v3dv in mesa
FYI: I just opened this issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3534 On Thu, Sep 17, 2020 at 12:13 PM 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? Then it can be the thing > that gets merged once the stuff in a and b land. > > --Jason > > On Thu, Sep 17, 2020 at 12:10 PM Jason Ekstrand 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 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
Re: [Mesa-dev] Plan for merging v3dv in mesa
One more comment: Could you make a big WIP MR with the whole driver to act as a pointer to the branch for now? Then it can be the thing that gets merged once the stuff in a and b land. --Jason On Thu, Sep 17, 2020 at 12:10 PM Jason Ekstrand 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 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
Re: [Mesa-dev] Plan for merging v3dv in mesa
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 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
[Mesa-dev] Plan for merging v3dv in mesa
Hi everybody, As some of you already know, we have been working on a Vulkan driver (v3dv) for the Broadcom V3D GPU present in the Raspberry Pi 4. So far we have beenworking on a personal branch, rebasing regularly, and we would like to start discussing about the process to merge the driver in Mesa. First, here is some data about the current state of the driver: Currently, we are targeting Vulkan 1.0 as our first milestone. At the moment, our Vulkan CTS results look like this: [701251/701251] Pass: 106776 Fail: 18 Skip: 594454 ExpectedFail: 0 UnexpectedPass: 0 Crash: 0 Timeout: 1 Missing: 0 Flake: 2 So we we are hoping to be able to submit the driver for conformance soon. We have not done much testing beyond CTS yet, however, we know that we can run all Vulkan ports of the Quake 1-3 classics as well as OpenArena and we also know that there is a PSP simulator that uses Vulkan that some people have used to run some games on the Rpi4 as well. We can also run many of the Sascha Willem's demos. So all in all, it seems that the driver can be useful already to people who want to start playing around with Vulkan on the Rpi4, and we would also like to start seeing more people doing exactly that so we can get feedback to continue polishing and improving the driver for real world usage. As for our proposal to merge the driver, following are our initial thoughts. We would like to know if this sounds reasonable before we start making preparations. 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. 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. 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. Does all this sound sensible? BR [1] "v3d/compiler: allow to batch spills" (MR#6632) [2] "broadcom/compiler: Allow spills of temporaries from TMU reads" (MR#6606) [3] "[RFC] vulkan/wsi: allow non-PCI devices to avoid the prime blit path" (MR#5917) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
