Otherwise, the PBuffer's size was never set. This also initializes
the buffer size for windows, pixmaps, etc.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=61012
Note: This is a candidate for the stable branches.
A single element in a GLX reply is contained in the header itself.
The number of elements is denoted in the "n" field of the reply.
If "n" is 1, the length of additional data is 0.
The XXX_data_length() function of xcb does not return the length of
the (optional, n>1) data but the number of elements.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=59876
Note: This is a candidate for the stable branches.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We weren't mapping the PBO when using the bitmap cache (but we had
the PBO code for the non-cache path.)
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=61026
Note: This is a candidate for the stable branches.
This fixes a regression from ab74fee5e1.
When we use the clip coordinate to compute the screen-space interpolation
factor, we need to first apply the divide-by-W step to the clip
coordinate.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=60938
Note: This is a candidate for the 9.1 branch.
It has become a bit messy.
Changes:
- finally correct checking for transfer ops depending on the base format
- making sure the base internal format and the texture format match
(we were ignoring it, but it's important for correctness)
- the way-too-strict rule that both src and dst base formats must be the same
was dropped; ensuring the simpler and more permissive rule mentioned above
is enough
- stop using util_blit_pixels; pipe->blit is flexible enough, and now that we
have RGBX and red-alpha formats, pipe->blit can be used for more cases
Reviewed-by: Brian Paul <brianp@vmware.com>
A temporary texture is created such that it matches the format and type
combination and pixels are copied to it using memcpy. Then the blit is used to
copy the temporary texture to the texture image being modified by TexImage or
TexSubImage. The blit takes care of the format and type conversion and
swizzling. The result is a very fast texture upload involving as little CPU
as possible.
This improves performance in apps which upload textures during rendering.
An example is the Wine OpenGL backend for DirectDraw, which I used to test
the game StarCraft. Profiling had shown that TexSubImage was taking 50% of
CPU time without this patch, which was the main motivation for this work, and
now TexSubImage only takes 14% of CPU time. I had to underclock my CPU to see
any difference in the game and this patch does make the game a lot faster
if the CPU is slow (or using the powersave cpufreq profile).
Reviewed-by: Brian Paul <brianp@vmware.com>
This is not easy to hit, because we have 3 code paths now
(tried in this order):
- memcpy-based (skips the blit) -> _mesa_tex_getimage
- blit-based
- slow pixel packing -> _mesa_tex_getimage
The main difference later in the code is the parameters of
_mesa_image_address3d.
Reviewed-by: Brian Paul <brianp@vmware.com>
Based on r600g commit 2b9659c9e6 .
Fixes crashes with 4 piglit tests which are now hitting these formats.
NOTE: This is a candidate for the 9.1 branch.
_mesa_delete_renderbuffer does not call the driver-specific
renderbuffer delete function, so the blorp code was leaking the
Intel-specific bits, including some GEM objects.
Call the renderbuffer's ->Delete() method instead, which does the
right thing.
Fixes Unity rapidly sending the machine into the arms of the OOM-killer
Note: This is a candidate for the 9.1 branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
We need to encode them as Texture instructions since the NumOffsets field
is encoded there. However, we don't encode the actual target in there, this
is derived from the sampler view src later.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Need to take the type into account. Also, if we want to allow
mov's with modifiers we need to pick a type (assume float).
v2: don't allow all modifiers on all type, in particular don't allow
absolute on non-float types and don't allow negate on unsigned.
Also treat UADD as signed (despite the name) since it is used
for handling both signed and unsigned integer arguments and otherwise
modifiers don't work.
Also add tgsi docs clarifying this.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The emulation of these if there's no rounding instruction available
is a bit more complicated than what the code did.
In particular, doing fp-to-int/int-to-fp will not work if the exponent
is large enough (and with NaNs, Infs). Hence such values need to be filtered
out and the original value returned in this case (which fortunately should
always be exact). This comes at the expense of performance (if your cpu
doesn't support rounding instructions).
Furthermore, floor/ifloor/ceil/iceil were affected by precision issues for
values near negative (for floor) or positive (for ceil) zero, fix that as well
(fixing this issue might not actually be slower except for ceil/iceil if the
type is not signed which is probably rare - note iceil has no callers left
in any case).
Also add some new rounding test values in lp_test_arit to actually test
for that stuff (which previously would have failed without sse41).
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=59701.
To help catch mixed up context pointer bugs in the future, add a
trace_context_check() function and some new assertions.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
When a trace_surface object is created in trace_surf_create() we
weren't correctly setting the surface's context pointer. Instead of
it being the trace context, it was the wrapped driver's context.
This caused things to blow up sometimes during surface deallocation.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The GL_ARB_texture_rg spec says that we need to support both texturing
and rendering for the GL_RED and GL_RG formats. So move the format
check up into the rendertarget_mapping[] list. Also, add
PIPE_FORMAT_R8_UNORM to the list of formats required.
Note: This is a candidate for the stable branches.
Reviewed-by: Marek Olšák <maraeo@gmail.com>
We'd been ad-hoc inserting instructions in some SEND messages with no
knowledge of when it was required (so extra instructions), but not all SENDs
(so not often enough). This should do much better than that, though it's
still flow-control-ignorant.
v2: Use BRW_MAX_MRF instead of magic numbers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58960
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: Candidate for the stable branches.
In GLSL, sampler indices are allocated contiguously from 0. But in the
case of ARB_fragment_program (and possibly fixed function), an app that
uses texture 0 and 2 will use sampler indices 0 and 2, so we were only
allocating space for samplers 0 and 1 and setting up sampler 0. We
would read garbage for sampler 2, resulting in flickering textures and
an angry simulator.
Fixes bad rendering in 0 A.D. and ETQW. This was fixed for pre-gen7 by
28f4be9eb9
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25201
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58680
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable branches.
I should say "fix", but it has never been used until now.
S8Z24 is the format equivalent to the GL_UNSIGNED_INT_24_8 packing,
so we'll start to see it more often with st/mesa now making smart decisions
about formats.
The DB<->CB copy can change the channel ordering for transfers, other than
that, the internal DB format doesn't really matter.
R600-R700 support is possible except shadow mapping.
FMT_24_8 is broken if the SAMPLE_C instruction is used (no idea why).
Also the sampler swizzling was broken in theory and the fact it worked was
a lucky coincidence.
radeonsi might need to port this.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
The default alignment is 4, so this fast path was rarely hit. Rather
than introduce logic to handle alignment, just use the Mesa core
function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46632
Cc: neil@linux.intel.com
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The code was rather broken for non-XYZW on 8-wide, but all of our
callers were using XYZW anyway. For my experiments with using writemask
on texturing, I've been using manual header setup in the compiler
backends, since we want to actually know what registers are written for
optimization and register allocation.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Detect a duplicate Shader type as and error instead of silently allowing
it, restrict to ES2 API.
v2: Tapani Pälli <tapani.palli@intel.com>
- make the check run time instead of compile time
v3: chadv
- Quote spec on which error to generate.
Signed-off-by: bma <Bo.Ma@windriver.com>
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
Fixes broken clipping in supertuxkart and presumably many other applications.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51471
NOTE: Candidate for the stable branches.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The hardware just doesn't support it. I suspect this was a regression from
the move to fixed MESA_FORMATs for compressed textures and that previously we
were storing uncompressed for this or something.
Fixes GPU hangs in piglit "texwrap GL_EXT_texture_sRGB-s3tc bordercolor
swizzled" on my GM965.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All of the GLSL specs from GLSL 1.30 (and GLSL ES 3.00) onward contain
language requiring certain integer variables to be declared with the
"flat" keyword, but they differ in exactly *when* the rule is
enforced:
(a) GLSL 1.30 and 1.40 say that vertex shader outputs having integral
type must be declared as "flat". There is no restriction on fragment
shader inputs.
(b) GLSL 1.50 through 4.30 say that fragment shader inputs having
integral type must be declared as "flat". There is no restriction on
vertex shader outputs.
(c) GLSL ES 3.00 says that both vertex shader outputs and fragment
shader inputs having integral type must be declared as "flat".
Previously, Mesa's behaviour was consistent with (a). This patch
makes it consistent with (b) when compiling desktop shaders, and (c)
when compiling ES shaders.
Rationale for desktop shaders: once we add geometry shaders, (b) really
seems like the right choice, because it requires "flat" in just the
situations where it matters. Since we may want to extend geometry
shader support back before GLSL 1.50 (via ARB_geometry_shader4), it
seems sensible to apply this rule to all GLSL versions. Also, this
matches the behaviour of the nVidia proprietary driver for Linux, and
the expectations of Intel's oglconform test suite.
Rationale for ES shaders: since the behaviour specified in GLSL ES
3.00 matches neither pre-GLSL-1.50 nor post-GLSL-1.50 behaviour, it
seems likely that this was a deliberate choice on the part of the GLES
folks to be more restrictive. Also, the argument in favor of (b)
doesn't apply to GLES, since it doesn't support geometry shaders at
all.
Some discussion about this has already happened on the Mesa-dev list.
See:
http://lists.freedesktop.org/archives/mesa-dev/2013-February/034199.html
Fixes piglit tests:
- glsl-1.30/compiler/interpolation-qualifiers/nonflat-*.frag
- glsl-1.30/compiler/interpolation-qualifiers/vs-flat-int-0{2,3,4,5}.vert
- glsl-es-3.00/compiler/interpolation-qualifiers/varying-struct-nonflat-{int,uint}.frag
Fixes oglconform tests:
- glsl-q-inperpol negative.fragin.{int,uint,ivec,uvec}
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
In the GLSL 1.30 spec, section 4.3.6 ("Outputs") says:
"If a vertex output is a signed or unsigned integer or integer
vector, then it must be qualified with the interpolation qualifier
flat."
The GLSL ES 3.00 spec further clarifies, in section 4.3.6 ("Output
Variables"):
"Vertex shader outputs that are, *or contain*, signed or unsigned
integers or integer vectors must be qualified with the
interpolation qualifier flat."
(Emphasis mine.)
The language in the GLSL ES 3.00 spec is clearly correct and should be
applied to all shading language versions, since varyings that contain
ints can't be interpolated, regardless of which shading language
version is in use.
(Note that in GLSL 1.50 the restriction is changed to apply to
fragment shader inputs rather than vertex shader outputs, to
accommodate the fact that in the presence of geometry shaders, vertex
shader outputs are not necessarily interpolated. That will be
addressed by a future patch).
NOTE: This is a candidate for stable branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
From GLSL ES 3.00 section 4.5.4 ("Default Precision Qualifiers"):
"The precision statement
precision precision-qualifier type;
can be used to establish a default precision qualifier. The type
field can be either int or float or any of the sampler types, and
the precision-qualifier can be lowp, mediump, or highp."
GLSL ES 1.00 has similar language. GLSL 1.30 doesn't allow precision
qualifiers on sampler types, but this seems like an oversight (since
the intention of including these in GLSL 1.30 is to allow
compatibility with ES shaders).
Previously, Mesa followed GLSL 1.30 and only allowed default precision
qualifiers to be set for float and int. This patch makes it follow
GLSL ES rules in all cases.
Fixes Piglit tests default-precision-sampler.{vert,frag}.
Partially addresses https://bugs.freedesktop.org/show_bug.cgi?id=60737.
NOTE: This is a candidate for stable branches.
Reviewed-by: Eric Anholt <eric@anholt.net>
