mesa merge requestshttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests2024-03-26T09:03:10Zhttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28200panfrost: Move the image attribute offset adjustment to a NIR pass2024-03-26T09:03:10ZBoris Brezillonpanfrost: Move the image attribute offset adjustment to a NIR pass### What does this MR do and why?
The recent transition of panvk to vk_dynamic_graphics_state led us
to rework the way we were dealing with image attributes passed to
vertex shaders.
Indeed, the gallium and vulkan drivers deal with ver...### What does this MR do and why?
The recent transition of panvk to vk_dynamic_graphics_state led us
to rework the way we were dealing with image attributes passed to
vertex shaders.
Indeed, the gallium and vulkan drivers deal with vertex attribute
emission differently. The gallium driver re-emits the VS attributes
on each draw, while the vulkan driver uses explicit attribute/image
descriptor dirtiness tracking, and could keep the attribute array
around if a new pipeline using a different number of attributes is
bound. If we want to be able to do that, we need to assign a fixed
offset for image attributes, such that the Vulkan descriptor
lowering pass knows where the images are in the attribute table
no matter the actual number of VS attributes used by the shader.
We could teach the Bifrost backend how to deal with a custom offset
but doing that in a lowering pass also simplifies a bit the Midgard
code.
Note that this MR doesn't change the way we do it in panvk. This will
be part of the MR transitioning panvk to vk_dynamic_graphics_state,
but I thought I'd submit this patch ahead, so we have the generic part
sorted out before the panvk changes.
/cc @kusma @ericsmith @marysakaMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28175pan/bi: Prepare things to allow real push_constant support in panvk2024-03-26T14:10:22ZBoris Brezillonpan/bi: Prepare things to allow real push_constant support in panvk### What does this MR do and why?
Right now panvk lowers push constant accesses to UBO loads. Prepare the bifrost backend compiler so we can support push constants for real.
/cc @marysaka @kusma### What does this MR do and why?
Right now panvk lowers push constant accesses to UBO loads. Prepare the bifrost backend compiler so we can support push constants for real.
/cc @marysaka @kusmaMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170panvk: Split panvk source files2024-03-27T10:07:39ZBoris Brezillonpanvk: Split panvk source files### What does this MR do and why?
Right now, panvk source split is a bit odd, with almost all the driver internal functions and structs defined in panvk_private.h, various stuff implemented in panvk_device.c even though they're not dire...### What does this MR do and why?
Right now, panvk source split is a bit odd, with almost all the driver internal functions and structs defined in panvk_private.h, various stuff implemented in panvk_device.c even though they're not directly related to VkDevice, and everything descriptor set related in panvk_descriptor_set.c,h.
We also sometimes have implementation for a VkXxxx concept split in panvk_vX_xxxx.c (for the per-gen part) and panvk_xxx.c (for the generic part). While this might help reduce the binary size, it's overly confusing, and if we're really interested in reducing the final driver size, we might be better off providing a way to disable architectures. This MR merges panvk_xxx.c into panvk_vX_xxxx.c and makes such implementations entirely per-gen, which also allows us to use the mali_xxx_packed structs direction, instead of some opaque uint32_t arrays sized to cover the max of all supported arches.
BTW, I'm seriously considering getting rid of the panvk_vX_ prefix and prefix both per-gen and gen-agnostic source files with panvk_ (the distinction could still be identified by looking at meson.build file, or the header).
@kusma How would you feel about that ^.
This cleanup is just the first step before further per-gen specialization that will be needed for v9 and v10 support. Ultimately, we will end up with something like:
```
# Valhall adopted a new descriptor model closer to what Vulkan wants
src/panfrost/vulkan/{bifrost,valhall}/panvk_[vX_]descriptor_set[_layout].{c,h}
src/panfrost/vulkan/{bifrost,valhall}/panvk_[vX_]pipeline[_layout].{c,h}
src/panfrost/vulkan/{bifrost,valhall}/panvk_vX_nir_lower_descriptors.c
src/panfrost/vulkan/{bifrost,valhall}/panvk_[vX_]cmd_desc.{c,h}
# Job frontend changes the way we issue draw/dispatch calls, and the way we track the cmd buffer state
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]cmd_gfx.c
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]cmd_compute.c
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]cmd_buffer.{c,h}
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]queue.{c,h}
# Events are natively supported on CSF
src/panfrost/vulkan/{jm,csf}/panvk_[vX_]event.{c,h}
# Once transitioned to vk_meta, anything meta should be generic
src/panfrost/vulkan/panvk_meta.{c,h}
# Everything that is already generic after this MR will stay
src/panfrost/vulkan/panvk_priv_bo.{c,h}
src/panfrost/vulkan/panvk_android.c
src/panfrost/vulkan/panvk_buffer.{c,h}
src/panfrost/vulkan/panvk_image.{c,h}
src/panfrost/vulkan/panvk_cmd_pool.{c,h}
src/panfrost/vulkan/panvk_physical_device.{c,h}
src/panfrost/vulkan/panvk_instance.{c,h}
src/panfrost/vulkan/panvk_mempool.{c,h}
src/panfrost/vulkan/panvk_wsi.{c,h}
src/panfrost/vulkan/panvk_macros.h
src/panfrost/vulkan/panvk_varyings.h
...
# Some files are per-gen, but their implementation is similar enough that it doesn't deserve a bifrost/valhall split
# and can instead be specialized with #if PAN_ARCH == xx sections in the code
src/panfrost/vulkan/panvk_[vX_]buffer_view.{c,h}
src/panfrost/vulkan/panvk_[vX_]image_view.{c,h}
src/panfrost/vulkan/panvk_[vX_]shader.{c,h}
src/panfrost/vulkan/panvk_[vX_]sampler.{c,h}
src/panfrost/vulkan/panvk_[vX_]device.{c,h}
```
Getting there requires mores cleanups (like the transition to vk_meta, the transition to vk_graphics_state for cmdbuf state tracking, or the split of panvk_cmd_buffer.{c,h} in smaller pieces that can be specialized independently), but I'd like to have your opinion early on so I don't spend too much time splitting things as I suggest if you think that's irrelevant.
This MR depends on !28104 and !28167.
/cc @kusma @nanokatze @marysaka @rmckeeverMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27738pan/va: Add missing valhall_enums dep to bifrost_tests2024-02-22T19:02:05ZMark Janespan/va: Add missing valhall_enums dep to bifrost_tests### What does this MR do and why?
```plaintext
pan/va: Add missing valhall_enums dep to bifrost_tests
bifrost_tests compilation fails if the valhall_enums.h has not been
generated.
```### What does this MR do and why?
```plaintext
pan/va: Add missing valhall_enums dep to bifrost_tests
bifrost_tests compilation fails if the valhall_enums.h has not been
generated.
```Marge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27626panfrost: Support multi-sampled image load/store on Midgard and Bifrost2024-02-26T23:39:51ZEric Smithpanfrost: Support multi-sampled image load/store on Midgard and Bifrost```
panfrost: Support multi-sampled image load/store on Midgard and Bifrost
The Panfrost hardware treats multi-sampled images in a very similar way to
3D textures, so take advantage of this by adding a new lowering pass
to make multi-sa...```
panfrost: Support multi-sampled image load/store on Midgard and Bifrost
The Panfrost hardware treats multi-sampled images in a very similar way to
3D textures, so take advantage of this by adding a new lowering pass
to make multi-sampled imageLoad/imageStore look like 3D accesses.
(Tested on Midgard and Bifrost. Probably works on Valhall as well, but not yet tested there.)
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
```Marge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24943ci: Disable known broken Bifrost Vulkan job2023-09-02T13:52:34ZAlyssa Rosenzweigci: Disable known broken Bifrost Vulkan jobUntil someone does the work to eliminate faults, PanVK will be inherently flaky
and should not be in CI. deqp-runner can eat a lot of flakes, and then retrying
the whole job eats more flakes, but neither is a substitute for not testing
k...Until someone does the work to eliminate faults, PanVK will be inherently flaky
and should not be in CI. deqp-runner can eat a lot of flakes, and then retrying
the whole job eats more flakes, but neither is a substitute for not testing
known broken (and hence flaky) code and both increase runtime unacceptably. the
g52-vk job earned 2 spots on the latest leaderboard for slowest jobs, I clicked
on https://gitlab.freedesktop.org/mesa/mesa/-/jobs/48142375 to see a jawdropping
54 flakes reported by deqp-runner.
If people insist on keeping the job, then panfrost-g52-vk needs to be demoted to
manual until after someone fixes all these bugs on the driver side. If that's
not going to happen, then there's no point in it being in CI at all. It's broken
code. After a buggy MR, it'll still be broken code. CI doesn't matter if we're
ok with it being broken.
Please do the right thing and remove this job. Please don't make me ask a fourth
time.
---
If people genuinely want me to submit an MR deleting Bifrost PanVK, at this point I will. There were silly political reasons why we didn't want to send that MR, but life's too short for me to factor silly politics into my decision making. I genuinely don't see the value of Vulkan support for anything older than v9, given the poor performance relative to GLES and the utter lack of Linux + Vulkan content that would actually run on Bifrost. DXVK/VKD3D are both out due to geometry shaders, which are in turn out due to layered rendering, which is added in v9 and presumably nobody will do the painful painful thing of emulating on Bifrost for the sake of running games slowly. Casual Android stuff will be happy with GLES3.2, I suspect. Zink/ANGLE aren't relevant here because the GLES driver will get better performance on Bifrost (the usual indexed/indirect nonsense). Most Vulkan content that would run will also have a GL/ES renderer, which again we expect to perform better given that Bifrost is actively hostile to adult drivers. I'm just genuinely unsure what people expect to do with Bifrost + VK. Maybe some Big Corp(TM) embedded application that's Vulkan-only because some tech lead somewhere decided that Vulkan is the future even though Bifrost is the present? If they want to fund bifrost+panvk, be my guest, I don't even mind leaving the code in tree for them to hack on, but it'll be a lot cheaper to bisect whatever regressions happen between now and that bizarro future than to actually make Bifrost + PanVK productizable.
I've heard from an ex-Intel developer that she regrets Haswell Vulkan support ... never conformant, never performant, and never can be deleted now that people use it. I suppose that's me & Bifrost.
My skepticism aside, I'm refraining from submitting that MR out of respect for the team working on Valhall PanVK, since I expect it would complicate their rebase. Regardless, we can't be running known broken code in CI (bugs = faults = flakes = unhappy developers), at least for non-robust stacks (panfrost.ko included). This needs to be policy if it isn't already. Merging this single character change deals with the hot problem without any fanfare or adverse effects. We can talk about the 10,000 line change at XDC.Needs mergeMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24610panfrost: upcast uint8/uint16 before shifting them beyond their range2024-02-05T06:34:12ZEric Engestromeric@engestrom.chpanfrost: upcast uint8/uint16 before shifting them beyond their range ../src/panfrost/compiler/compiler.h:89:14: runtime error: left shift of 51966 by 16 places cannot be represented in type 'int'
#0 0x55c72fd7dda4 in bi_apply_swizzle ../src/panfrost/compiler/compiler.h:89
#1 0x55c72fd8... ../src/panfrost/compiler/compiler.h:89:14: runtime error: left shift of 51966 by 16 places cannot be represented in type 'int'
#0 0x55c72fd7dda4 in bi_apply_swizzle ../src/panfrost/compiler/compiler.h:89
#1 0x55c72fd808d6 in bi_source_value ../src/panfrost/compiler/bi_opt_constant_fold.c:35
#2 0x55c72fd80a83 in bi_fold_constant ../src/panfrost/compiler/bi_opt_constant_fold.c:52
#3 0x55c72fb2080c in constant_fold_pred ../src/panfrost/compiler/test/test-constant-fold.cpp:48
#4 0x55c72fb21a65 in ConstantFold_Swizzles_Test::TestBody() ../src/panfrost/compiler/test/test-constant-fold.cpp:103
#5 0x55c73070cc97 in void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../src/gtest/src/gtest.cc:2621
#6 0x55c7306f0df7 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ../src/gtest/src/gtest.cc:2657
#7 0x55c730694add in testing::Test::Run() ../src/gtest/src/gtest.cc:2696
#8 0x55c73069798d in testing::TestInfo::Run() ../src/gtest/src/gtest.cc:2845
#9 0x55c73069b684 in testing::TestSuite::Run() ../src/gtest/src/gtest.cc:3004
#10 0x55c7306ccfcb in testing::internal::UnitTestImpl::RunAllTests() ../src/gtest/src/gtest.cc:5890
#11 0x55c73071053c in bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ../src/gtest/src/gtest.cc:2621
#12 0x55c7306f4ed3 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ../src/gtest/src/gtest.cc:2657
#13 0x55c7306c23fa in testing::UnitTest::Run() ../src/gtest/src/gtest.cc:5455
#14 0x55c730748faf in RUN_ALL_TESTS() ../src/gtest/include/gtest/gtest.h:2314
#15 0x55c730748ffa in main ../src/gtest/src/gtest_main.cc:63
#16 0x7f8554bcc1c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#17 0x7f8554bcc284 in __libc_start_main_impl ../csu/libc-start.c:360
#18 0x55c72fb18be0 in _start (/builds/mesa/mesa/_build/src/panfrost/compiler/bifrost_tests+0xbd0be0)Needs mergeMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24266gallium/panfrost: support directly sampled but non-CSC I420/YV12 formats2023-11-08T14:03:31ZItalo Nicolagallium/panfrost: support directly sampled but non-CSC I420/YV12 formatsBifrost can sample from these multiplanar formats, with lower alignment requirements than RGB formats, but needs shader CSC.
This is pending on !21109Bifrost can sample from these multiplanar formats, with lower alignment requirements than RGB formats, but needs shader CSC.
This is pending on !21109Needs mergeMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23836nir: Add pixel_coord, frag_coord_zw intrinsics2023-06-29T04:09:57ZAlyssa Rosenzweignir: Add pixel_coord, frag_coord_zw intrinsicsOn some architectures, gl_FragCoord.xy is available as an integer but gl_FragCoord.zw requires interpolation. Add dedicated intrinsics and lower gl_FragCoord in NIR. This lets us share some code between Bifrost and AGX.
---
I wanted `...On some architectures, gl_FragCoord.xy is available as an integer but gl_FragCoord.zw requires interpolation. Add dedicated intrinsics and lower gl_FragCoord in NIR. This lets us share some code between Bifrost and AGX.
---
I wanted `load_pixel_coord` to write a lowering on Asahi. Once I added the intrinsic in, reworking everything to use it made sense.Needs mergeMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23235panfrost/ci: Skip Piglit tests known to crash2023-05-25T15:45:37ZAlyssa Rosenzweigpanfrost/ci: Skip Piglit tests known to crashA bunch of Piglits cause crashes, at least when run with PAN_MESA_DEBUG=sync.
For many, the crashes are due to faults. Although Piglits are nominally
process-isolated, faults can leak across processes to subpar recovery, meaning
these cr...A bunch of Piglits cause crashes, at least when run with PAN_MESA_DEBUG=sync.
For many, the crashes are due to faults. Although Piglits are nominally
process-isolated, faults can leak across processes to subpar recovery, meaning
these crashes are liable to cause robust passing tests to flakes. So, skip any
tests known to crash to make sure the coverage is solid.
Given that we run piglit on panfrost in pre-merge CI, but there's nobody
actively working on fixing piglits for panfrost, I think this is the best
compromise. It means we get to keep the coverage (and ensure we don't regress
piglits that are currently passing) but we don't risk flaking CI. Currently
deqp-runner is eating massive numbers of piglit flakes. While it's really great
that the infrastructure is robust in that way, it'd be better to not have those
flakes in CI in the first place (for run time, if not robustness).
If someone starts hacking on Bifrost + desktop OpenGL again for some reason and
fixes these tests locally, they can reenable them then.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>Needs mergeMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22223gallium: Remove PIPE_CAP_TEXTURE_BUFFER_SAMPLER2023-04-07T01:55:56ZAlyssa Rosenzweiggallium: Remove PIPE_CAP_TEXTURE_BUFFER_SAMPLERFirst, teach Panfrost to upload its own internal sampler when txf is used. It already does that on Valhall, it just needs the workaround backported to Midgard and Bifrost. Then Panfrost no longer needs the hack that is PIPE_CAP_TEXTURE_B...First, teach Panfrost to upload its own internal sampler when txf is used. It already does that on Valhall, it just needs the workaround backported to Midgard and Bifrost. Then Panfrost no longer needs the hack that is PIPE_CAP_TEXTURE_BUFFER_SAMPLER. With no users left, remove the CAP.
The CAP was already not respected by rusticl, so you couldn't set it if you wanted OpenCL support (which is why it was already not needed on Valhall and just needed a bit of generalizing). I regret introducing the CAP in the first place, and no more drivers should use it. Remove it to make sure they don't.
Functional revert of d5d3f77e4ac ("gallium: Add new cap PIPE_CAP_TEXTURE_BUFFER_SAMPLER").
@bbrezillon for panfrost + bifrost changes
@italove for panfrost + midgard changes
@mareko for gallium change
@kwg as a reviewer of the reverted change.
@gfxstrand nir/print cleanup at the end
@zmike my latest contribution to the "delete the CAPs" projectNeeds mergeMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21987gallium: decompose quad strips into quads if supported2023-04-04T17:49:07ZAntonino Maniscalcogallium: decompose quad strips into quads if supportedThis changes gallium to decompose quad strips into quads instead of triangles
when the driver advertises support for them.
This should result in a more correct result when those are drawn
with the line raster primitve (avoids showing th...This changes gallium to decompose quad strips into quads instead of triangles
when the driver advertises support for them.
This should result in a more correct result when those are drawn
with the line raster primitve (avoids showing the diagonal line).
This MR was separated out of !21238 and it only affects drivers that support the quad primitive but not the quad strip primitive (~~of which there are probably none currently but~~ such as panfrost for GPUs older than Midgard and v6 Bifrost, plus the mentioned MR needs it)Marge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21831panfrost: Don't round up Midgard polygon list BOs2023-03-28T20:48:26ZAlyssa Rosenzweigpanfrost: Don't round up Midgard polygon list BOsRounding up the polygon list BO can waste large amounts of memory. In a common
case I observed, it rounded up 11MB to 16MB, wasting 5MB. That adds up quickly
across processes, especially on the 2GB machines.
This only applies to Midgard...Rounding up the polygon list BO can waste large amounts of memory. In a common
case I observed, it rounded up 11MB to 16MB, wasting 5MB. That adds up quickly
across processes, especially on the 2GB machines.
This only applies to Midgard. On Bifrost and newer, the driver does not
explicitly allocate this data structure. Cc stable because this rounding is
incorrect and the increase in RAM usage can cause real problems (especially
given how slow the shrinker is).
Cc @italove, I would appreciate if you would double check the calculation here because I sure didn't :~)Needs reviewMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21109panfrost: support hw sampling of YUV textures on bifrost2023-08-07T19:57:32ZItalo Nicolapanfrost: support hw sampling of YUV textures on bifrostThis MR adds a new texture descriptor for sampling single and multiplane YUV textures on bifrost. When sampling from YUV textures, the stride /offset alignment requirement may be smaller than the usual 64-bytes, so this MR also changes t...This MR adds a new texture descriptor for sampling single and multiplane YUV textures on bifrost. When sampling from YUV textures, the stride /offset alignment requirement may be smaller than the usual 64-bytes, so this MR also changes that requirement for the relevant formats.
The gallium/st patch is needed for making `PIPE_FORMAT_NV21` behave similar to `PIPE_FORMAT_NV12`, by doing CSC in the shader but making use of the hw YUV texture sampler.
cc @cphealy @alyssaNeeds reviewMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21082agx: Keep varyings forwarded to texture as fp322023-03-25T14:21:25ZAlyssa Rosenzweigagx: Keep varyings forwarded to texture as fp32This works around bugs in a LOT of applications, since fp16 texture coordinates
are almost never appropriate even though it's a valid implementation of the GLES
spec. It also doesn't seem to matter for perf.
Code from the Bifrost compil...This works around bugs in a LOT of applications, since fp16 texture coordinates
are almost never appropriate even though it's a valid implementation of the GLES
spec. It also doesn't seem to matter for perf.
Code from the Bifrost compiler which implements the same workaround for slightly
different reasons.
Cc @asahilinaNeeds reviewMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20906pan/bi: Make all sysvals explicit in the NIR2023-03-24T00:31:04ZAlyssa Rosenzweigpan/bi: Make all sysvals explicit in the NIRCurrently, we have a number of NIR system values that are consumed by the compiler, which supplies an ordered list of system values for the driver to upload as part of the ABI. Furthermore we have a few implicit system values which the b...Currently, we have a number of NIR system values that are consumed by the compiler, which supplies an ordered list of system values for the driver to upload as part of the ABI. Furthermore we have a few implicit system values which the backend compiler materializes on the fly. This works ok for GL -- it isn't great but it's good enough -- but it's a significant technical debt for Vulkan.
In the future, we will want to lower system values in NIR in the *driver*. This will allow the GL and VK drivers to lower the same system values in different ways, reflecting the different binding models and available pipeline state and so on. To get there, we need all system values to be explicit in the NIR. This is already the case for the Midgard compiler, but in Bifrost we have 3 implicit sysvals we need to deal with. The way to fix that is simple: move the lowerings early, from backend instruction selection to NIR lowering passes. Then in the future, we'll be able to split up compiling in two phases, allowing the driver to apply its own NIR lowerings in between these lowerings and backend isel.
Draft because this series isn't well tested yet.Needs reviewMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20688mesa: Set info.separate_shader for ARB programs2023-04-24T18:08:57ZAlyssa Rosenzweigmesa: Set info.separate_shader for ARB programsARB programs are logically separate, and Mesa will happily mix and match them.
We need to alert backends of this fact, by setting nir->info.separate_shader.
Otherwise, backends may link shaders invalidly.
Fixes fp-abs-01 on Bifrost. (We...ARB programs are logically separate, and Mesa will happily mix and match them.
We need to alert backends of this fact, by setting nir->info.separate_shader.
Otherwise, backends may link shaders invalidly.
Fixes fp-abs-01 on Bifrost. (We don't use separate_shader for anything on
Valhall, so the issue doesn't appear there.)
Compare 151aa19c215 ("ttn: Set nir->info.separate_shader"), which fixed a
similar issue with TGSI.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stableMarge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20685panfrost: Fix logic ops on Bifrost2023-01-26T17:10:11ZAlyssa Rosenzweigpanfrost: Fix logic ops on Bifrostopaque should not be set when logicops are enabled, that needs blending
even on Bifrost. Fixes is for when I believe the bug became possible to hit.
The logical error is older.
Fixes Piglit logicop tests again.
Fixes: d849d9779a7 ("pan...opaque should not be set when logicops are enabled, that needs blending
even on Bifrost. Fixes is for when I believe the bug became possible to hit.
The logical error is older.
Fixes Piglit logicop tests again.
Fixes: d849d9779a7 ("panfrost: Avoid blend shader when not blending")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>Marge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20684panfrost: Implement GL_EXT_render_snorm on Bifrost+2023-02-03T17:34:39ZAlyssa Rosenzweigpanfrost: Implement GL_EXT_render_snorm on Bifrost+It's really easy! Once we have the appropriate fixes, from !20016 and !20683 respectively. I added this support in order to test !20016 properly, but I see no reason not to ship it.It's really easy! Once we have the appropriate fixes, from !20016 and !20683 respectively. I added this support in order to test !20016 properly, but I see no reason not to ship it.Marge BotMarge Bothttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20455pan/bi: Rename panfrost/bifrost -> panfrost/compiler2023-01-02T18:22:57ZAlyssa Rosenzweigpan/bi: Rename panfrost/bifrost -> panfrost/compilerThis is the compiler for both Bifrost and Valhall, and presumably future
Mali GPUs too. Give it a more generic name so we can use the bifrost/ path for
something a bit more specific.
For historical reasons the compiler's name is still "...This is the compiler for both Bifrost and Valhall, and presumably future
Mali GPUs too. Give it a more generic name so we can use the bifrost/ path for
something a bit more specific.
For historical reasons the compiler's name is still "bifrost" and uses the
prefix `bi_`. I think that's ok in the same way that i915 in the kernel supports
way more than just i915.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>Marge BotMarge Bot