This will eventually be relaxed, but we'll get the fallback path
working first.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
This is the actual mesa_format to use. In non-view cases this is always
the same as the mt's format.
V4: Comment style
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
We need to wire the original texture's mt into the view. All the hard
work of setting up an appropriate tree of gl_texture_image structures
has already been done by core mesa.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
If we were to relayout the miptree, we'd break any views that are
sharing it.
(Simplified based on suggestions from Eric)
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
We will need to call this to munge view formats.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
We will need this for munging the view's format.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
These formats can be cast to others (with different component types or
sizes) via ARB_texture_view or ARB_shader_image_load_store. We want
them to be laid out consistently so that we can just reinterpret the
memory with a different format.
In V1, this was done conditionally on a 'prefer_no_swizzle' flag which
was set in TexStorage/TextureView paths, but we need the same behavior
for ARB_shader_image_load_store (which also works with images created
via TexImage, so we don't want it to be conditional.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
The sampler can handle R8G8B8X8 (and substitute 1.0 for the fourth
component) but we can't use it as a render target.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
None of the other 3-component 16bpc formats are directly supported, so
they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
way makes texture views much more fiddly -- we don't want to have to do
crazy copying behind the scenes.
(with my other master + my experimental ARB_texture_view support) fixes
the piglit test: `spec/ARB_texture_view/view compare 48bit formats`
No regressions in gpu.tests on Haswell.
V4: Don't alter the formats table -- just don't match it to a mesa_format. [Kenneth]
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
This is supported by all generations, and is required for memory layout
consistency for texture_view.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
Now this is the preferred format for GL_SRGB8_ALPHA8.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
V4: Fix rebase conflicts with Brian's renaming of the texfetch
functions.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Eric Anholt <eric@anholt.net>
Previously, we would unpack the texels to floats using *_TO_FLOAT_TEX,
and then pack them into the desired format using FLOAT_TO_*. Unfortunately,
this isn't quite the inverse operation, and so some texel values would
end up off-by-one.
This fixes the GL_RGB8_SNORM and GL_RGB16_SNORM subcases in piglit's
arb_texture_view-format-consistency-get test on i965. The similar 1-, 2-
and 4-component cases already worked because they took the memcpy path
rather than repacking.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>
While linux uses .so as a default extension for shared libraries that is
not the case for other platforms. The loader in libGL (and others) assumes
that the dri module will always have a .so extension, thus it will fail
to load on the affected platforms.
Spotted-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Filenames passed to dlopen() don't need to use the platform's default extension
for shared libraries.
Using the '.so' extension when dlopen()ing DRI drivers is hardcoded into mesa
and the X server, so it should be hardcoded here in the Makefile as well.
A similar fix is probably also needed for gallium DRI drivers.
(Consider that if we were starting from scratch, perhaps we would use a custom
extension like .dri instead)
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
This reverts commit 61bedc3d6b.
As the header is the one defining the API/ABI and is distributed
during installation, we should be using it rather than re-defining
the XA version in configure.ac.
Bump the version in the header to 2.2.0, to reflect what was the
original intent of commit 42158926c6.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
With commit 1f1928db001(glx: Drop _Xglobal_lock while we create and
initialize glx display) we've split the big _Xglobal_lock handling in
a more fine grained manner.
Unfortunatelly we forgot to drop the unlock_mutex on the error paths,
leading to undefined behaviour as the mutex is already unlocked.
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We hit this assert with some piglit tests. Which appears to be a bug
outside of freedreno. Previously we were relying on assert() being
redefined to debug_assert() so that we didn't crash in release builds.
Somehow that stopped working. So just use debug_assert() directly.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Fixes a crash in svga_context_flush_buffers() if we use the 'draw' module
for AA lines (when the device doesn't support that feature). We need to
initialize this list before we setup the swtnl pieces.
Found/fixed by Charmaine Lee.
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
The "new" fragment shader backend has never supported the necessary
color conversion code for this to work. We began using the new backend
in Mesa 7.10 for GLSL (commit a81d423d93, October 2010),
and for ARB_fragment_program in Mesa 9.1 (commit 97615b2d8c,
August 2012).
I haven't heard any complaints, so I don't think anyone will miss this
feature. I believe mplayer used it at one point, but these days
defaults to other paths anyway.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
create_mov() was fixed up to handle neg/abs properly for interal mov's,
using absneg.f, but forgot to fix it for TGSI MOV's. The problem with
using add.f to handle negated mov's is that we can only take a single
const reg src. So:
MOV TEMP[n], -CONST[m]
would turn into:
add.f Rdst, (neg)CONST[m], 0.0
which would not work. Anyways, just remove the extra code and always
use create_mov() which DTRT.
This fixes piglit vs-op-neg-int test.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This should help prevent situations where we render without proper index
bounds. For example: https://bugs.freedesktop.org/show_bug.cgi?id=59455
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Applications frequently clear to colors other than 0.0 or 1.0, which
prevents us from doing fast color clears. In that case, we issue this
performance warning on basically every glClear call, resulting in so
much spam that it's nearly impossible to see any other messages.
Plus, I don't think it's useful. We aren't suggesting a better way to
do what the application developers want---we're just telling them it
would be faster to do something they don't want.
Driver developers have no control over the clear color, so this message
is totally useless to them.
A better alternative to get this sort of information is to use
INTEL_DEBUG=blorp, which tells you whether color clears were fast,
simd16 repdata, or slow.
v2: Rebase on has_color_component changes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Keep track of whether we actually have any sam instructions in the
resulting shader, rather than using TGSI SAMP declarations. If the sam
instruction is optimized out, because the result is not used, we don't
want to emit texture state, etc. In fact emitting sampler state and/or
setting PIXLODENABLE bit when there are no texture fetches seems to
cause lockup.
In theory this should never happen for a "normal" shader, unless the
state tracker is wonky. But it is a very real possibility for binning
pass shaders.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more detail comment. Compute limit outside inner loops.
v3: add bugzilla reference
v4: Correct cc syntax in commit log
v5: really grab the right patch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74988
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1, suggested v2-3]
v2: move allocation to a function as first step
to clean vid_enc_EncodeFrame
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leo Liu <leo.liu@amd.com>
For TEX instructions, the set of samplers and sampler views should
be consistent. The XA state tracker sometimes passes an inconsistent
set of samplers and sampler views. Rather than assert and die, issue
a warning.
v2: add debugging code to detect inconsistent state.
v3: also check for null sampler in svga_state_tss.c
Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Given
mov vgrf7, vgrf9.xyxz
add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
add vgrf10.x, vgrf6.xyzw, vgrf7.wwww
the last instruction would be wrongly changed to
add vgrf10.x, vgrf6.xyzw, vgrf9.zzzz
during copy propagation.
The issue is that when deciding if a record should be cleared, the old code
checked for
inst->dst.writemask & (1 << ch)
instead of
inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch))
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Cc: Jordan Justen <jljusten@gmail.com>
Cc: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romainck <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.1" <mesa-stable@freedesktop.org>
Nothing bad came of this because they weren't used after visitor running,
but leaving them in a bad state seems like a recipe for pain later.
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
When you've got a simple solid-color shader that doesn't generate
pixel_x/y interpolation, we were deciding that the first vgrf was both the
undefined pixel_x and pixel_y, and extending its live interval to avoid
the stride problem. That tricked other optimization that tries to see if
a particular instruction is the last use of a variable.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We stopped doing variable index lowering for uniforms in
a64c1eb9b1, 5 months after the comment was
added.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
While we wish our optimization passes could identify all the cases where
we can coalesce our variables, we miss out on a lot of opportunities.
total instructions in shared programs: 1673849 -> 1673166 (-0.04%)
instructions in affected programs: 299521 -> 298838 (-0.23%)
GAINED: 7
LOST: 0
Note that many programs are "hurt". The notable ones are where we produce
unrolling in cases we didn't before (presumably just because of the lower
instruction count). But there are also some cases where pushing things
right into the variables prevents copy propagation and tree grafting,
since we don't split our variable usage webs apart.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Chris Forbes
Michel Dänzer
Emil Velikov
Jon TURNEY
Rob Clark
Brian Paul
Kenneth Graunke
Marek Olšák
Iago Toral Quiroga
Topi Pohjolainen
Courtney Goeltzenleuchter
Leo Liu
Christian König
Chia-I Wu
Eric Anholt