| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This doesn't yet support PSIZ, but gets us at least some of TF working.
|
|
|
|
| |
It's a NIR driver_location, not a slot offset.
|
|
|
|
|
| |
The TF enable state appears to stick around until the next TF enable
packet is sent, so we only want to request TF when the shader is using it.
|
|
|
|
| |
I missed the "- 1" when reading the spec.
|
| |
|
|
|
|
|
| |
We will want something fancier for reusing a TF output within the same
frame, but we at least need this in order for piglit tests to work.
|
|
|
|
|
| |
The interpolation qualifier, if specified, is supposed to take precedence
over glShadeModel().
|
|
|
|
|
|
|
| |
The HW will halt when you hit a HALT packet, or when you hit the end
address. Tell CLIF if there's an end address is so that it can stop
correctly. (There was usually a 0 byte after the CL, so it would stop
anyway).
|
|
|
|
|
| |
I had misread the packet description: We always have a 32f depth, and a
separate u8 stencil.
|
|
|
|
| |
We can render to and sample from it just fine.
|
|
|
|
| |
Fixes glsl-fs-discard-02.
|
|
|
|
|
|
|
|
| |
In order to keep early-Z from writing early in a discard shader, you need
to set the "modifies Z" bit in the shader state (which the new
prog_data.discards will indicate). Then, in the shader we do a TLB write
to make Z passthrough happen (the QPU result is ignored, so we use a NULL
source).
|
|
|
|
| |
We don't want to write Z for discarded fragments.
|
| |
|
|
|
|
|
|
| |
I had base_vertex hacked into the shader state setup like in vc4, but it's
not correct for big offsets. Using the proper packet is easier and
hopefully means we can re-emit shader state setup less frequently.
|
|
|
|
| |
This lets us do index_bias and ARB_base_instance.
|
|
|
|
|
| |
This massively reduces the size of our RCL setup. It also gets us closer
to supporting multicore platforms.
|
|
|
|
| |
We're going to need these for MSAA, and to use the generic per-tile list.
|
|
|
|
|
|
| |
These existed so I could unpack just the sub-id field to switch on in the
old manual CLIF dumper. The new codegen handles sub-id automatically, but
only if these stub packets aren't there with an implicit sub-id=0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
V3D 3.3 is a continuation of the 3D implementation in VC4 (v2.1 and v2.6).
V3D 3.3 introduces an MMU (no more CMA allocations) and support for
GLES3.1. This driver is not currently conformant, though that will be a
target as soon as possible.
V3D 3.x parts use a new texture tiling layout common across many Broadcom
graphics parts including and the HVS scanout engine. It also massively
changes the QPU instructions, introducing a common physical register file
(no more A/B split) and half-float instructions, while removing the 4x8
unorm instructions in favor of half-float for talking to fixed function
interfaces. Because so much has changed, vc5 is implemented in a separate
gallium driver, using only the XML code-generation support from vc4.
v2: Fix tile layout for 64bpp textures. Fix texture swizzling for 32-bit
returns. Fix up a bit of MRT setup. Sync the simulator to kernel
behavior a bit more. Improve uniform debugging code. Rebase on
QIR->VIR rename. Move texture state mostly to the CSOs. Improve
cache flushing on the simulator. Fix program deletion
use-after-frees.
Acked-by: Dave Airlie <[email protected]> (uabi plan)
Acked-by: Daniel Vetter <[email protected]> (uabi plan)
|
|
|
|
|
|
|
|
|
|
|
| |
This is a pretty straightforward fork of VC4's NIR compiler to VC5. The
condition codes, registers, and I/O have all changed, making the backend
hard to share, though their heritage is still recognizable.
v2: Move to src/broadcom/compiler to match intel's layout, rename more
"vc5" to "v3d", rename QIR to VIR ("V3D IR") to avoid symbol conflicts
with vc4, use new v3d_debug header, add compiler init/free functions,
do texture swizzling in NIR to allow optimization.
|
|
|
|
|
|
|
|
| |
This will be usable with "VC5_DEBUG=cl" on the vc5 driver to stream a CLIF
file (the Broadcom equivalent of i965's AUB) to stderr. I haven't tested
that this is actually usable with the internal CLIF-consuming tools, but
is close enough as a baseline and is useful for visually inspecting the
command stream.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike VC4, I've defined an unpacked instruction format with pack/unpack
functions to convert to 64-bit encoded instructions. This will let us
incrementally put together our instructions and validate them in a more
natural way than the QPU_GET_FIELD/QPU_SET_FIELD used to.
The pack/unpack unfortuantely are written by hand. While I could define
genxml for parts of it, there are many special cases (like operand order
of commutative binops choosing which binop is being performed!) and it
probably wouldn't come out much cleaner.
The disasm unit test ensures that we have the same assembly format as
Broadcom's internal tools, other than whitespace changes.
v2: Fix automake variable redefinition complaints, add test to .gitignore
|
|
|
|
|
|
|
| |
Unlike vc4, where the compiler and gallium driver live together, for vc5
the compiler will live up in the shared broadcom directory, and need
access to the debug flags. Define a set of debug flags and helpers there,
so it can be shared between compiler, vc5, and vulkan.
|
|
|
|
|
|
|
|
|
|
|
|
| |
My intent is to develop the vc5 driver in-tree for some time to build the
CL generation and shader compiler code, and keep out-of-tree patches for
talking to an actual kernel driver until the kernel driver can be
stabilized on the hardware.
v2: Define a HAVE_BROADCOM_DRIVERS, like HAVE_INTEL or HAVE_AMD.
Reviewed-by: Adam Jackson <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been doing this inside of vc4, but vc5 wants it as well and it may be
useful for other drivers (Intel has a related path for pre-gen6 with MRT,
and freedreno had a TGSI path for it at one point).
This required defining a common enum for the standard comparison
functions, but other lowering passes are likely to also want that enum.
v2: Add to meson.build as well.
Acked-by: Rob Clark <[email protected]>
|
|
|
|
| |
trivial, fixes make check.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent is to use this extension on vc4 to allow X11 to do overlapping
CopyArea() within a pixmap without first blitting the pixmap to a
temporary. With associated glamor patches, improves x11perf
-copywinwin100 performance on a Raspberry Pi 3 from ~4700/sec to
~5130/sec, and is an even larger boost to uncomposited window movement
performance (most copywinwin100 copies don't overlap).
v2: Fix glIsEnabled() on the new enums.
v3: Drop the local spec since I'm upstreaming the spec.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because vc4 can control the order that tiles are rasterized in, we can use
it to implement overlapping blits using normal drawing and
GL_ARB_texture_barrier, as long as we can tell the kernel what order to
render the tiles in.
v2: Fix on the simulator.
v3: Add the cap (disabled) to other drivers, add rst docs for the cap.
v4: Rebase on PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS
v5: Split from the core gallium commit, drop some unnecessary code related
to glBlitFramebuffer(), fix a crash with clears before state has been
bound.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because vc4 can control the order that tiles are rasterized in, we can use
it to implement overlapping blits using normal drawing and
GL_ARB_texture_barrier, as long as we can tell the kernel what order to
render the tiles in.
This commit introduces the core gallium support, vc4 changes will follow.
v2: Fix on the simulator.
v3: Add the cap (disabled) to other drivers, add rst docs for the cap.
v4: Rebase on PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS
v5: Drop vc4 changes from this commit, for clarity.
Reviewed-by: Nicolai Hähnle <[email protected]> (v3)
|
|
|
|
|
|
| |
Improves x11perf -copywinwin100 from ~2000/sec to ~4700/sec. More
importantly, this is a prerequisite for the new GL_MESA_tile_raster_order
extension.
|
|
|
|
|
|
|
|
| |
v2: use !! in the function to be explicit about type conversion. Though,
gcc generates the same code with or without the logical !!.
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
Try to start removing things from the cluttered imports.h file.
v2: add new header to Makefile.sources
Reviewed-by: Roland Scheidegger <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Before we were doing RGBA4 on GLES3 only, but as of GLES2 2.0.22 it should
be RGBA4 as well. Fixes DEQP
functional.state_query.rbo.renderbuffer_internal_format.
Tested-by: Matt Turner <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extension is effectively a backport of GLES3's internalformat
handling to GLES 1/2. It guarantees that sized internalformats specified
for textures and renderbuffers have at least the specified size stored.
That's a pretty minimal requirement, so I think it can be dummy_true and
exposed as a standard in Mesa.
As a side effect, it also allows GL_RGB565 to be specified as a texture
format, not just as a renderbuffer. Mesa had previously been allowing 565
textures, which angered DEQP in the absence of this extension being
exposed.
v2: Allow 2101010rev with sized internalformats even on GLES3, citing the
extension spec. Extend extension checks for GLES2 contexts exposing
with texture_float, texture_half_float, and texture_rg.
v3: Fix ALPHA/LUMINANCE/LUMINANCE_ALPHA error checking (GLES3 CTS
failures)
v4: Mark GL_RGB10 non-color-renderable on ES, fix A/L/LA errors on GLES2
with float formats.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we were downconverting to 8888 automatically if the hardware
didn't suport it. However, with the advent of
GL_OES_required_internalformat, we have to actually store the
internalformats we advertise support for. And, it seems rather
disingenuous to advertise the extension if we don't actually support it.
v2: Throw an error when using the format on ES2 without the extension present.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
This keeps us from promoting them up to 8888, at the cost of not being
color-renderable.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is how VC4 stores 5551 textures, which we need to support for
GL_OES_required_internalformat.
v2: Extend commit message, fix svga driver build, add BE ordering from
Roland.
v3: Rebase on PIPE_FORMAT_R10G10B10X2_UNORM addition.
Reviewed-by: Marek Olšák <[email protected]> (v2)
Reviewed-by: Nicolai Hähnle <[email protected]> (v2)
|
|
|
|
|
|
|
|
|
|
| |
For supporting RGB5 in hardware with A in the low bit (vc4), we need this
format as well.
v2: Add proper _mesa_format_matches_format_and_type() support (from
Nicolai).
Reviewed-by: Nicolai Hähnle <[email protected]> (v1)
|
|
|
|
| |
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
| |
Tested with dEQP-EGL.functional.image.*renderbuffer* tests.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
| |
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Applications might pass in a buffer that is sized too large and rely
on the extra space of the buffer not being overwritten.
Fixes dEQP-GLES31.functional.state_query.internal_format.partial_query.num_sample_counts
Cc: [email protected]
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
The uploaders can own transfers which need to be unmapped. Destroy them
before the final sync (they're not used from the driver thread anyway)
so that the transfer_unmap call is processed by the driver.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|