| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The V3D 3.x series of TMU writes with meaning depending on the texture
type is replaced with writes to specific registers for each texture
argument semantic.
|
|
|
|
|
| |
V3D 4.x texturing changes enough that #ifdefs would just make a mess of
it.
|
|
|
|
|
| |
For V4.1 texturing, I need the V4.1 XML, so the main compiler needs to
stop including V3.3 XML.
|
|
|
|
|
| |
We no longer have the small depth-specific output format enum, and instead
depth is just at the end of the output image format enum.
|
|
|
|
|
| |
The RGBX8 formats were dropped from V3D 4.x, but we don't really need them
anyway (we already handle other non-alpha formats by forcing A to 1).
|
| |
|
| |
|
|
|
|
|
| |
I want the library's entrypoints to still be unversioned, but the actual
packet dumping needs to be per-version.
|
|
|
|
|
| |
This is a major performance boost on all of V3D, but is required on V3D
4.x where shaders are always either 2- or 4-threaded.
|
|
|
|
|
|
|
|
|
|
| |
This fills in the delay slots of thread end as much as we can (other than
being cautious about potential TLBZ writes).
In the process, I moved the thread end THRSW instruction creation to the
scheduler. Once we start emitting THRSWs in the shader, we need to
schedule the thread-end one differently from other THRSWs, so having it in
there makes that easy.
|
|
|
|
| |
Apparently the VPM writes need to be flushed out before we end the shader.
|
|
|
|
|
| |
This required extending the CL submit ioctl, because the tile alloc/state
buffer setup has moved from the BCL to register writes.
|
|
|
|
|
| |
I had a .ifb being decoded weird in sampid, so this is to check that .ifb
is fine.
|
| |
|
|
|
|
|
| |
This is needed for LDVPM on V3D 4.x, but will also be needed for keeping
values out of the accumulators across THRSW.
|
|
|
|
|
|
|
|
|
|
|
| |
Now, instead of a magic write register for VPM stores we have an
instruction to do them (which means no packing of other ALU ops into it),
with the ability to reorder the VPM stores due to the offset being baked
into the instruction.
VPM loads also gain the ability to be reordered by packing the row into
the A argument. They also no longer write to the r3 accumulator, and
instead must be stored to a physical register.
|
|
|
|
|
| |
I had all the packing code in this file at one point, but these defines
now live in qpu_pack.c.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This required moving the register accesses to a separate v3dx file, since
the register definitions for each V3D version collide. It seems that
initializing the v3d_hw from a file dictating 3.3
(v3d_simulator_wrapper.cpp) is safe, though.
|
|
|
|
| |
Signals are more complicated than that, and tables ended up being better.
|
|
|
|
|
|
|
| |
The WRTMUC replaces the implicit uniform loads in the first two texture
instructions. LDVPM disappears in favor of an ALU op. LDVARY, LDTMU,
LDTLB, and LDUNIF*RF now write to arbitrary registers, which required
passing the devinfo through to a few more functions.
|
| |
|
|
|
|
|
|
|
| |
The TLB load/store path is rebuilt in this version. There is no longer a
single-byte resolved store or the 3-byte extended store. Instead, you get
to always use general loads/stores (which, honestly, was tempting even in
previous versions).
|
|
|
|
|
| |
I accidentally emitted this into the RCL instead of the per-tile generic
list, so we wouldn't get tiles after the first cleared.
|
|
|
|
|
| |
This is going to get more complicated with V3D 4.1 support, which redoes
all the TLB packets.
|
|
|
|
|
|
| |
To conditionally compile cl_emit() macros per V3D version, we need it to
expand to whatever V3D we're building for. This required emitting #define
V3D_VERSION 33 in all our currently 3.3-only code.
|
|
|
|
|
| |
This will be used by vc5 for prefixing functions and including the pack
header in v3d-version-dependent code, following the model of anv.
|
|
|
|
|
|
| |
We try to emit a #error and continue so that you can debug the missing
type at C compile time, but were missing a couple of definitions in that
path (sigh, python).
|
| |
|
|
|
|
|
|
|
| |
For clarification purposes.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
|
| |
To avoid compilation warnings and because this helper
shouldn't update anything.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upon reception of an event that lowered the number of active back buffers,
the code would immediately try to free all back buffers with an id equal to or
higher than the new number of active back buffers.
However, that could lead to an active or to-be-active back buffer being freed,
since the old number of back buffers was used when obtaining an idle back
buffer for use.
This lead to crashes when lowering the number of active back buffers by
transitioning from page-flipping to non-page-flipping presents.
Fix this by computing the number of active back buffers only when trying to
obtain a new back buffer.
Fixes: 15e208c4cc ("loader/dri3: Don't accidently free buffer holding new back content")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104214
Cc: "17.3" <[email protected]>
Tested-by: Andriy.Khulap <[email protected]>
Tested-by: Vadym Shovkoplias <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
Signed-off-by: Thomas Hellstrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From Vulkan spec:
"descriptorCount is the number of descriptors contained in the binding,
accessed in a shader as an array. If descriptorCount is zero this
binding entry is reserved and the resource must not be accessed from
any stage via this binding within any pipeline using the set layout."
Fixes:
dEQP-VK.binding_model.descriptor_update.empty_descriptor.uniform_buffer
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARB_ubo requires 12 UBOs (per stage) at least, but this limit has been
raised by GL 4.3 to 14, so don't advertize GL 4.3 without it (only checking
the vertex stage since all drivers probably have the same limit anyway for
other stages). (piglit has minmax tests for that kind of thing, but they go
only up to 3.3, so this won't really be noticed.)
I think this currently should not affect any driver - r600 until very
recently only supported 12 but now advertizes 14 too.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
We've seen some problems internally due to macro redefinition.
Fix this by adding HAVE_FUNC_ATTRIBUTE_NORETURN to c99_compat.h,
and defining it for msvc.
And avoid redefinition just in case.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the number of instances hasn't changed and we've already
emitted it, don't emit it again.
If the vertex shader is the same and the first_instance, vertex_offset
haven't changed don't emit them again.
This increases the fps in GL_vs_VK -t 1 -m -api vk from around 40
to around 60 here, it may not impact anything else.
Dieter also reported smoketest going from 1060->1200 fps.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Running dota2 since the below commit crashes with an llvm assert.
Trim the vector like the other user. This possible could also be
avoided by not padding inside the load vec3->vec4.
Fixes: 41c36c4549 (amd/common: use ac_build_buffer_load() for emitting UBO loads)
Reviewed-by: Samuel Pitoiset <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
Signed-off-by: <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
| |
Otherwise this could be undefined in the egl directory.
Signed-off-by: Dylan Baker <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This simplifies the build by removing the need to link targets against
libsensors.
Suggested-by: Emil Velikov <[email protected]>
Signed-off-by: Dylan Baker <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates two new internal dependencies, idep_nir_headers and
idep_nir. The former encapsulates the generation of nir_opcodes.h and
nir_builder_opcodes.h and adding src/compiler/nir as an include path.
This ensures that any target that needs nir headers will have the
includes and that the generated headers will be generated before the
target is build. The second, idep_nir, includes the first and
additionally links to libnir.
This is intended to make it easier to avoid race conditions in the build
when using nir, since the number of consumers for libnir and it's
headers are quite high.
Acked-by: Eric Engestrom <[email protected]>
Signed-off-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For things like:
loop
x = func()
list += x
end
just do:
loop
list += func()
end
Acked-by: Eric Engestrom <[email protected]>
Signed-off-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
| |
Don't use intermediate variables, use consistent whitespace.
Acked-by: Eric Engestrom <[email protected]>
Signed-off-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
These were added after adderlib was mesonified, but it still good to use
them instead of open coding them.
Acked-by: Eric Engestrom <[email protected]>
Signed-off-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the meosn build has a mix of two styles:
arg : [foo, ...
bar],
and
arg : [
foo, ...,
bar,
]
For consistency let's pick one. I've picked the later style, which I
think is more readable, and is more common in the mesa code base.
v2: - fix commit message
Acked-by: Eric Engestrom <[email protected]>
Signed-off-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
We already had to switch all of the W types to UW to prevent issues
with vector immediates on gen10. We may as well use unsigned types
everywhere.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gen 10 has a strange hardware bug involving V immediates with W types.
It appears that a mov(8) g2<1>W 0x76543210V will actually result in g2
getting the value {3, 2, 1, 0, 3, 2, 1, 0}. In particular, the bottom
four nibbles are repeated instead of the top four being taken. (A mov
of 0x00003210V yields the same result.) This bug does not appear in any
hardware documentation as far as we can tell and the simulator does not
implement the bug either.
Commit 6132992cdb858268af0e985727d80e4140be389c was mostly a no-op
except that it changed the type of the subgroup invocation from UW to W
and caused us to tickle this bug with basically every compute shader
that uses any sort of invocation ID (which is most of them). This is
also potentially an issue for geometry shader input pulls and SampleID
setup. The easy solution is just to change the few places where we use
a vector integer immediate with a W type to use a UW type.
Reviewed-by: Matt Turner <[email protected]>
Cc: [email protected]
Fixes: 6132992cdb858268af0e985727d80e4140be389c
|