Remove the following duplicates from the formats table:
- R8G8B8A8_UNORM (V_,_T)
- R8G8B8X8_UNORM (_T,_T)
- DXT3_RGBA (_T,_T)
Only the first has an effect because the _T overrides the V_ initializer,
the latter two were harmless duplications of the same.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Add support for ETC2 compressed textures in the etnaviv driver.
One step closer towards GL ES 3 support.
For now, treat SRGB and RGB formats the same. It looks like these are
distinguished using a different bit in sampler state, and not part of
the format, but I have not yet been able to confirm this for sure.
(Only enabled on GC3000+ for now, as the GC2000 ETC2 decoder
implementation is buggy and we don't work around that)
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
It's incorrect to use $(LOCAL_PATH) in makefile recipes since it's
changing. The typical way to handle it is to use private variable.
Fortunately in this case we can just simplify them to $^.
See further:
https://patchwork.freedesktop.org/patch/167718/
Also simplify LOCAL_GENERATED_SOURCES.
Fixes: 2dd4e2ec (spirv: Generate spirv_info.c)
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Two of the ARB_shader_ballot piglit tests hit the find_lsb case,
removing some of the noise allowed me to better debug the test when it
was failing.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Some hardware, like i965, doesn't support group sizes greater than 32.
In that case, we can reduce the destination size of the ballot
intrinsic, which will simplify our code generation.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The implementation of ballotARB() will start by zeroing the flags
register. So, a doing something like
if (gl_SubGroupInvocationARB % 2u == 0u) {
... = ballotARB(true);
[...]
} else {
... = ballotARB(true);
[...]
}
(like fs-ballot-if-else.shader_test does) would generate identical MOVs
to the same destination (the flag register!), and we definitely do not
want to pull that out of the control flow.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The implementations of the ARB_shader_ballot intrinsics will explicitly
read the flag as a source register.
Reviewed-by: Matt Turner <mattst88@gmail.com>
We already had a channel_num system value, which I'm renaming to
subgroup_invocation to match the rest of the new system values.
Note that while ballotARB(true) will return zeros in the high 32-bits on
systems where gl_SubGroupSizeARB <= 32, the gl_SubGroup??MaskARB
variables do not consider whether channels are enabled. See issue (1) of
ARB_shader_ballot.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The implementations of the ARB_shader_group_vote intrinsics will
explicitly write the flag as the destination register.
Reviewed-by: Matt Turner <mattst88@gmail.com>
I don't expect anyone is going to care about using this in vec4 programs
(vertex/tessellation/geometry on Gen6/7), no one has come up with a good
way to implement it much less test it.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Specifically, constant fold intrinsics from ARB_shader_group_vote, but I
suspect it'll be useful for other things in the future.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These are intrinsics rather than opcodes, because they operate across
channels.
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Within i965, we have many different objects and confusingly when
submitting an execbuf we have lists of both our internal objects and a
list of the kernel's drm_i915_gem_exec_object with very similar names.
Rename the kernel's validation list to avoid the collison as it is only
used for interfacing with the kernel and so a peripheral use of
"object".
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This reverts commit b7153c3e9f.
The point of that commit was to ensure intel_prepare_render() occurred
before color resolves on the current framebuffer. In 0673bbfd9b
(i965: Move surface resolves back to draw/dispatch time), Jason moved
brw_predraw_resolve_framebuffer back to draw time, which is already
after a intel_prepare_render() call. So, this is no longer necessary.
Furthermore, it caused problems. "mpv" would only display a small
corner of movies, and Android started failing camera CTS tests.
This is because intel_prepare_render() ended up handling DRI2 events
which caused the drawable to be resized at an inopportune time, flagging
ctx->NewState |= _NEW_BUFFERS, but at a point where we've already copied
ctx->NewState, and failed to notice the newly set flag.
The lack of _NEW_BUFFERS caused us to skip 3DSTATE_DRAWING_RECTANGLE,
so the drawing ended up being clipped to an outdated framebuffer size.
Just drop the hack and go back to handling this at the proper time.
Thanks to Matti Hämäläinen (ccr), Tomasz Figa (tfiga), and Tapani Palli
for reporting these issues.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101558
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101704
Tested-by: Tapani Pälli <tapani.palli@intel.com>
No need to check if ID is not 0 because _mesa_HashFindFreeKeyBlock()
can't generate this value.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
No need to check if ID is not 0 because _mesa_lookup_vao()
already prevents this to happen.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
v2 (Jason):
- s/separate_stencil_surface/make_separate_stencil_surface/
- drop the check for separate stencil when wrapping an
existing buffer object with miptree. This is dead code as
the first needs_separate_stencil() checks is
MIPTREE_LAYOUT_FOR_BO-flag and says no.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Depth buffers are always Y-tiled. In brw_miptree_choose_tiling()
driver opts to use linear buffers for small and 1D but this does
not apply for depth - GL_DEPTH_COMPONENT and GL_DEPTH_STENCIL_EXT
are considered first.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
