| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
There's a magic bit in preload_regs which controls this. It doesn't
appear to be supported on G71 but it is on G52. I'd guess G72 supports
it too but I don't have a way to check this.
Needless to say, we'll need a quirks database for this.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4061>
|
|
|
|
|
|
|
|
|
| |
Code by Connor Abbott, reverting a part of
254f40fd535ef57dee2bcc4afd97840749ce5918 where it was removed during a
Midgard refactor.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4025>
|
|
|
|
|
|
|
|
|
|
|
| |
It fits snugly in a u64, just give a macro for direct computation rather
than fudging around with bitfields. Not sure if this actually matters
with well-optimized compilers but it makes the code subjectively cleaner
so it's worth it for that if nothing else.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3838>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3838>
|
|
|
|
|
|
|
| |
It's zero everywhere.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3835>
|
|
|
|
|
|
|
|
|
|
|
|
| |
(And bifrost_fb_extra to mali_framebuffer_extra, bifrost_render_target
to mali_render_target)
These structures are the norm on midgard t760+, drop the bifrost names,
it's silly... unrelated to the rest of the series but while I'm messing
with pandecode and cleaning up bifrost abstractions, might as well.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3835>
|
|
|
|
|
|
|
|
|
|
| |
It looks like these are the same structure, so this allows us to reuse
mali_shared_memory across architectures, and dispels with the
Bifrost-specific mystery of the scratchpads... nothing so mysterious
after all, just stack.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3835>
|
|
|
|
|
|
|
|
|
| |
This small structure is used to configure shared memory and stack for
compute shaders, and is also present at the beginning of framebuffer
descriptors. Let's factor it out.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3835>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We discovered 2 new shader flags used when a fragment shader updates
the depth/stencil value through a ZS writeout. If those flags are not
set, the depth/stencil value stored in the depth/stencil tilebuffer
remain unchanged.
While at it, rename unknown2 into flags_hi and rename flags into
flags_lo.
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3697>
|
|
|
|
|
|
| |
Acked-by: Daniel Stone <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3414>
|
|
|
|
|
|
| |
Acked-by: Daniel Stone <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3414>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As pointed out by Boris, what we were calling PAN_LINEAR depth textures
was in fact u-interleaved tiled (!), but we never noticed since we
flipped the flag used for sampling, leading to all sorts of fun bugs
when attempting to directly acess depth textures from the CPU. Which
begs the question -- if what we called LINEAR was tiled, how do we
actually render linear depth textures? It turns out the flags for AFBC
form a mali_block_format 2-bit code just like their render-target
counterparts, so we can render to any of the above.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Reported-by: Boris Brezillon <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3393>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3393>
|
|
|
|
| |
Reviewed-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
| |
With 3D textures we can have lots of layers, so better allocate it
dynamically at runtime.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
It has been unused for a while; let's just remove the abstraction.
Technically the hardware does support 32-bit job descriptors, but we
don't and we can't keep them from breaking so let's not pretend they
work.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Suggested-by: Boris Brezillon <[email protected]>
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
There's only one way to encode comparison functions in the command
stream, not two. It's just that the semantics for texture comparisons
are flipped from the semantics of stencil comparison. We can factor out
that flip to common Panfrost code, rather than tying it to a second
Gallium routine.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
| |
Somehow we have native hardware for all of these. Suspected by staring
at the bit pattern; confirmed by poking in various texture wrap modes
into the textures mesa demo and seeing what happens.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
It's an awfully fancy way to add one...
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
| |
It's a relic from before we understood the varying builtins. It should
never actually come up if the builtins are decoded correctly.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
| |
These are conventions by the blob (a convention we happent to follow).
They are not at all intrinsic to the hardware, so now that the
convention is implemented within the Midgard stack, these defines are
wholly unused. Remove them.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Just like varyings have special records for point coordinates (etc),
attributes have special records for vertex/instance ID. We can parse
these fairly easily, although they don't line up exactly with normal
attribute records.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
| |
gcc generates exceptionally bad code for panfrost_pack_work_groups_fused
otherwise ... although that routine is somehow still hot ...
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3067>
|
|
|
|
|
|
|
|
| |
Just use the MALI_MFBD tag directly; it's clean.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3118>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3118>
|
|
|
|
|
|
|
| |
It's conceptually independent from the upper part (which is not yet
understood, but for spilling generally remains equal to 0x1e).
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
It's the analogue pointer in SFBD.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
| |
See
https://lists.freedesktop.org/archives/dri-devel/2019-December/247601.html
Write value emphasises that it's just a generic write primitive.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
| |
It's not a tiler specific initialization; it's a generic GPU-side write
primitive that may be used for tiler reset on midgard.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
This is no longer used.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The algorithm is as described. Nothing fancy here, just need to add some
new code paths depending on which model we're running on.
Tomeu:
- Also disable tiling when !hierarchy and !vertex_count
- Avoid creating polygon lists smaller than the minimum when
vertex_count > 0 but tile size smaller than 16 byte
- Take into account tile size when calculating polygon list size for
!hierarchy
- Allow 0-sized tiles in a single dimension
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Signed-off-by: Tomeu Vizoso <[email protected]>
|
|
|
|
|
|
|
|
| |
Similarly to how it's already done in the compiler, add a way to express
differences between GPU models that need to be taken into account when
assembling the cmdstream.
Signed-off-by: Tomeu Vizoso <[email protected]>
|
|
|
|
|
|
|
| |
Enough trial and error ... just think even *more* Midgard about where
this field might be!
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is less complicated than previously thought. Note we have no way of
specifying the work register count for blend shaders; it must be
strictly less than the work register count of the corresponding fragment
shader (which is fine since we force the fragment shader to report a
count of 16 with a blend shader as a major hack until we get register
pressure down for blend shaders).
TODO: pandecode the flags.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
| |
During tests on T720, these fields were discovered.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
| |
MALI_DEPTH_TEST should only be set when depth->writemask is true,
not when the depth test is enabled. Let's rename the flag and patch
panfrost_bind_depth_stencil_state() to do the right thing.
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
I don't believe this is actually a tagged pointer; warn if it is.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
| |
Rather than passing through the transformed gl_Position, we can use the
hardware-level varying for this, which will correctly handle
gl_FragCoord.w
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
| |
We don't actually care about the *contents* of the index buffer, but we
would rather like to ensure it is present and of the correct size.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
| |
These tags need to match up with what's actually described by the MFBD,
so check this. Once this is checked, since the type and contents of the
FBD are obvious from printing above, there's no need to explicitly mark
off the framebuffer line.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
This is another bit field describing layout.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
No need to be so verbose.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
| |
There is no "chunknown" structure; that part of the union is an artefact
from falsely believing vertex/tiler MFBDs could have render targets
attached (they can't). These are just plain old AFBC fields, and if
there is no AFBC, it's error to set these field.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
| |
Verify sizes / masks / etc against something logical to cull down the
trace space and automatically guard against a number of potential
hazards.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
| |
We don't have a good way to confirm this, but it parallels the kernel
definitons for MMU faults nicely.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
| |
It's a chicken bit, as far as I can tell. Buck buck.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Midgard does not accept a index_bias directly and relies instead on a
bias correction offset (offset_bias_correction) in order to calculate
the unbiased vertex index.
We need to make sure we adjust offset_start and vertex_count in order to
take into account the index_bias as required by a
glDrawElementsBaseVertex call and then supply a additional
offset_bias_correction to the hardware.
Signed-off-by: Rohan Garg <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
|