width, height parameter in glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size for target texture type + 2 * border.
i.e. 1 << (ctx->Const.MaxTextureLevels - 1) + 2 * border
Texture border is anyway stripped out before it is given to intel
or gallium drivers.
This patch fixes Intel oglconform test case:
max_values negative.textureSize.textureCube
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
Note: This is a candidate for mesa 8.0 branch.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit ea228d97f8)
Specifially, this being present works around a bug in Unigine
Sanctuary on i965 which previously resulted in bad rendering.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit ff2497dca3)
NOTE: Compared to ff2497d this does not install the default drirc.
The pre-automake build system is sufficiently braindamaged to make
this exceptionally difficult.
Fixes piglit switch-case-duplicated.vert.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 57e44371a5)
The error message I chose matches gcc's error. Fixes piglit
switch-case-duplicated.vert.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 140632190c)
Otherwise, the upcoming error messages said the location was 0:0(0).
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 663dcbbffe)
It's not quite spelled out in the spec text, but the grammar indicates
that only constant values are allowed as switch() case labels (and
only constant values make sense, anyway).
Fixes piglit glsl-1.30/compiler/switch-statement/switch-case-uniform-int.vert.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 2c3e10e719)
This stuffs them all in a struct for sanity. Fixes piglit
glsl-1.30/execution/switch/fs-uniform-nested.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 22d81f154f)
For all the extension entrypoints using the get_buffer() helper, they
wanted the same error handling. In some cases, the error was doing
the same error return whether target was a bad enum, or a user buffer
wasn't bound.
(Actually, GL_ARB_map_buffer_range doesn't specify the error for a zero
buffer being bound for MapBufferRange, though it does for
FlushMappedBufferRange. This appears to be an oversight).
Fixes piglit GL_ARB_copy_buffer/negative-bound-zero.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit f20fb80a91)
In commit 6ecee54a9a a call to
talloc_reference was replaced with a call to talloc_steal. This was in
preparation for moving to ralloc which doesn't support reference
counting.
The justification for talloc_steal within token_list_append in that
commit is that the tokens are being copied already. But the copies are
shallow, so this does not work.
Fortunately, the lifetime of these tokens is easy to understand. A
token list for "replacements" is created and stored in a hash table
when a function-like macro is defined. This list will live until the
macro is #undefed (if ever).
Meanwhile, a shallow copy of the list is created when the macro is
used and the list expanded. This copy is short-lived, so is unsuitable
as a new parent.
So we can just let the original, longer-lived owner continue to own
the underlying objects and things will work.
This fixes bug #45082:
"ralloc.c:78: get_header: Assertion `info->canary == 0x5A1106'
failed." when using a macro in GLSL
https://bugs.freedesktop.org/show_bug.cgi?id=45082
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable release branches.
(cherry picked from commit cd2e2187cb)
This fixes a dangling texture object pointer bug hit via wglShareLists().
When we push the GL_TEXTURE_BIT state we may push references to the default
texture objects which are owned by the gl_shared_state object. We don't
want to accidentally delete that shared state while the attribute stack
references shared objects. So keep a reference to it.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit a1471e4877)
This cleans up the reference counting of shared context state.
The next patch will use this to fix an actual bug.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit 361cd53a77)
This can be used to work around broken application behavior, like in
Unigine where it attempts to use texture arrays without declaring
either "#extension GL_EXT_texture_array : enable" or "#version 130".
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 642247883f)
This is the corresponding fix to the previous one for the FS, but I
don't have a particular test for it.
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 9195191e50)
On i965, _mesa_ir_link_shader is never called. As a consequence, the
current fragment program (ctx->FragmentProgram->_Current) exists but is
invalid because it has no instructions. Yet swrast continued to attempt to
use the empty program.
To avoid using the empty program, this patch 1) defines a new function,
_swrast_use_fragment_program, which checks if the current fragment program
exists and differs from the fixed function fragment program, and, when
appropriate, 2) replaces checks of the form
if (ctx->FragmentProgram->_Current == NULL)
with
if (_swrast_use_fragment_program(ctx))
Fixes the following oglconform regressions on i965/gen6:
api-fogcoord(basic.allCases.log)
api-mtexcoord(basic.allCases.log)
api-seccolor(basic.allCases.log)
api-texcoord(basic.allCases.log)
blend-separate(basic.allCases)
colorsum(basic.allCases.log)
The tests were ran with the GLXFBConfig:
visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat
----------------------------------------------------------------------------
0x021 24 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0 0 0 0 None
(Note: I originally believed that the hunk in
_swrast_update_fragment_program was unnecessary. But it is required to fix
blend-separate.)
Note: This is a candidate for the 8.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327
Reveiwed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 1c0f1dd42a)
This was losing bits of precision. Fixes (with the previous commits):
piglit EXT_texture_integer/getteximage-clamping
piglit EXT_texture_integer/getteximage-clamping GL_ARB_texture_rg
oglc advanced.mipmap.upload
Regresses oglc negative.typeFormatMismatch.teximage from fail to
abort, because it's been hitting texstore for a format/type combo that
shouldn't happen.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 5f65598cc7)
In the core, we always treat spans of int/uint data as uint, so this
extract function was truncating storage of integer pixel data to a n
int texture to (0, max_int) instead of (min_int, max_int). There is
probably missing code for handling truncation on conversion between
pixel formats, still, but this does improve things.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit dadbec1e90)
Mostly fixes piglit EXT_texture_integer/getteximage-clamping. The
remaining failure involves precision loss on storing of int32 texture
data (something I knew was an issue, but wasn't trying to test).
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 8b97bb02fb)
This cut and paste is pretty awful. I'm tempted to do a lot of this
using preprocessor tricks for customizing the parameter type from a
template function, but that's just a different sort of hideous.
Fixes 8 Intel oglconform int-textures cases.
NOTE: This is a candidate for the 8.0 branch.
v2: Add alpha formats, too.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit de24ccabd6)
Otherwise, when you asked for the _BaseFormat of an rb wrapping a
GL_RGB texture, you got GL_RGBA because that's what we were storing
the texture data as.
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 7cac88679b)
Most of this function was just calling
intel_renderbuffer_update_wrapper(), which was called immediately
afterwards in the only caller.
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 74484c5d41)
When rendering to FBO, rendering is inverted. At the same time, we would
also make sure the point sprite origin is inverted. Or, we will get an
inverted result correspoinding to rendering to the default winsys FBO.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44613
NOTE: This is a candidate for stable release branches.
v2: add the simliar logic to ivb, too (comments from Ian)
simplify the logic operation (comments from Brian)
v3: pick a better comment from Eric
use != for the logic instead of ^ (comments from Ian)
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit eaf360e5bf)
We were allocating registers into the MRF hack region, resulting in
sparkly renering in a few of the scenes. We could do better
allocation by making an MRF class, having MRFs conflict with the
corresponding GRFs, and tracking the live intervals of the "MRF"s and
setting up the conflicts. But this is way easier for the moment.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit e910241e97)
If size is small (such as 1),
pitch = ROUND_DOWN_TO(MIN2(size, (1 << 15) - 1), 4);
makes pitch = 0. Then
height = size / pitch;
causes a division-by-zero exception. If pitch is zero, set height to
1 and avoid the division.
This fixes piglit's bin/getteximage-formats test and glean's
bufferObject test.
NOTE: This is a candidate for the 8.0 release branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44971
(cherry picked from commit d59466279e)
There are cases where a buffer can be mapped while another buffer is
flushed. This can happen in the CopyPixels meta-op path for piglit's
fbo-mipmap-copypix. After some discussion with Eric, it seems this
assertion is no longer necessary, and it has always been too strict.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43328
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 65b096aedd)
FBOs differ from textures in a significant way. With textures, we can
strip the border and get correct rendering except when the application
fetches texels outside [0,1].
With an FBO, the pixel at (0,0) is in the border. The
ARB_framebuffer_object spec says:
"If the attached image is a texture image, then the window
coordinates (x[w], y[w]) correspond to the texel (i, j, k), from
figure 3.10 as follows:
i = (x[w] - b)
j = (y[w] - b)
k = (layer - b)
where <b> is the texture image's border width..."
Since the border doesn't exist, we can never render any pixels in the
correct location. Just mark these FBOs FRAMEBUFFER_UNSUPPORTED.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42336
(cherry picked from commit 87b4c9b322)
The trick here is that flex always chooses the rule that matches the most
text. So with a input text of "two:" which we want to be lexed as an
IDENTIFIER token "two" followed by an OTHER token ":" the previous OTHER
rule would match longer as a single token of "two:" which we don't want.
We prevent this by forcing the OTHER pattern to never match any
characters that appear in other constructs, (no letters, numbers, #,
_, whitespace, nor any punctuation that appear in CPP operators).
Fixes bug #44764:
GLSL preprocessor doesn't replace defines ending with ":"
https://bugs.freedesktop.org/show_bug.cgi?id=44764
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable release branches.
(cherry picked from commit 7ab1c7f792)
Ever since xserver commit 531869448d07e00ae241120b59f3aaaa5709d59c,
the server no longer sends invalidate events to clients, unless they
have performed a GetBuffers request since the drawable was last
invalidated.
If the drawable gets invalidated immediately after the GetBuffers
request was processed by the X server, it's possible that Xlib
will process the invalidate event while waiting for the GetBuffers
reply. So the server, thinking the client knows that the buffers
are invalid, is waiting for another GetBuffers request before
sending any more invalidate events. The client, on the other hand,
believes the buffers to be valid, and thus is expecting to receive
another invalidate event before it has to send another GetBuffers
request. The end result is that the client never again sends
a GetBuffers request.
To avoid this problem, take a snapshot of the lastStamp before
doing GetBuffers, and retry if the snapshot and the current
lastStamp no longer match after the GetBuffers reply has been
processed.
Signed-off-by: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 0fcc518964)
Even though it should be safe to use them for one frame, better be sure.
Suggested by Michael Dänzer.
NOTE: This is a candidate for the 8.0 stable branch.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
(cherry picked from commit 81938d2137)
This prevents a possible lapse of the depth buffer - the situation where
the app and pp have different depth buffers.
NOTE: This is a candidate for the 8.0 stable branch.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
(cherry picked from commit c5976017e3)
When storing data in a buffer of type DYNAMIC_DRAW, we don't create a
drm_intel_bo for it; instead we store the data in system memory and
defer allocation of the GPU buffer until it is needed. Therefore, in
brw_update_sol_surface(), we can't just consult the "buffer" field of
the intel_buffer_object structure; we need to call
intel_bufferobj_buffer() to ensure that the deferred allocation
occurs.
This parallels a similar fix for gen7 (see commit ba6f4c9).
Fixes piglit test EXT_transform_feedback/buffer-usage on gen6.
This is a candidate for the 8.0 release branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 6bc08ee569)
i965 processes assignments of whole structures using
vec4_visitor::emit_block_move, a recursive function which visits each
element of a structure or array (to arbitrary nesting depth) and
copies it from the source to the destination. Then it increments the
source and destination register numbers so that further recursive
invocations will copy the rest of the structure. In addition, it sets
the swizzle field for the source register to an appropriate value of
swizzle_for_size(...) for the size of each element being copied, so
that later optimization passes won't be fooled into thinking that
unused vector elements are live.
This all works fine. However, emit_block_move also contains an
assertion to verify, before setting the swizzle field for the source
register, that the source register doesn't already contain a
nontrivial swizzle. The intention is to make sure that the caller of
emit_block_move hasn't already done some swizzling of the data before
the call, which emit_block_move would then counteract when it
overwrites the swizzle field. But the assertion is at the lowest
level of nesting of emit_block_move, which means that after the first
element is copied, instead of checking the swizzle field set by the
caller, it checks the swizzle field used when moving the previous
element. That means that if the structure contains elements of
different vector sizes (which therefore require different swizzles),
the assertion will erroneously fire.
This patch moves the assertion from emit_block_move to the calling
function, vec4_visitor::visit(ir_assignment *). Since the caller is
non-recursive, the assertion will only happen once, and won't be
fooled by emit_block_move's modification of the swizzle field.
This patch also reverts commit fe006a7 (i965/vs: Fix swizzle related
assertion), which attempted to fix the bug by making the assertion
more lenient, but only worked properly for structures, arrays, and
matrices in which each constituent vector is the same size.
This fixes the problem described in comment 9 of
https://bugs.freedesktop.org/show_bug.cgi?id=40865. Unfortunately, it
doesn't fix the whole bug, since the test in question is also failing
due to lack of register spilling support in the VS.
Fixes piglit test vs-assign-varied-struct. No piglit regressions on
Sandy Bridge.
This is a candidate for the 8.0 release branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40865#c9
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit e2274aa739)
From the extension spec:
Added to section 5.4, as part of the discussion of which commands
are not compiled into display lists:
"Certain commands, when called while compiling a display list, are
not compiled into the display list but are executed immediately.
These are: ..., RenderbufferStorageMultisampleEXT..."
Fixes piglit EXT_framebuffer_multisample/dlist.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 3d8c27f882)
Noticed when handling a similar problem in EXT_framebuffer_multisample.
From the EXT_framebuffer_object spec:
Added to section 5.4, as part of the discussion of which commands
are not compiled into display lists:
"Certain commands, when called while compiling a display list, are
not compiled into the display list but are executed immediately.
These are: ..., GenFramebuffersEXT, BindFramebufferEXT,
DeleteFramebuffersEXT, CheckFramebufferStatusEXT,
GenRenderbuffersEXT, BindRenderbufferEXT, DeleteRenderbuffersEXT,
RenderbufferStorageEXT, FramebufferTexture1DEXT,
FramebufferTexture2DEXT, FramebufferTexture3DEXT,
FramebufferRenderbufferEXT, GenerateMipmapEXT..."
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 25dd80555d)
width, height parameter in glTexImage2D() includes: texture image
width + 2 * border (if any). So when doing the texture size check
in _mesa_test_proxy_teximage() width and height should not exceed
maximum supported size for target texture type.
i.e. 1 << (ctx->Const.MaxTextureLevels - 1)
Texture border is anyway stripped out before it is given to intel
or gallium drivers.
This patch fixes Intel oglconform test case: max_values
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44970
Note: This is a candidate for mesa 8.0 branch.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
(cherry picked from commit 15986d21eb)
Color clamping should be enabled in glGetTexImage if texture dataType is
GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA
Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
https://bugs.freedesktop.org/show_bug.cgi?id=40864
NOTE: This is a candidate for the 8.0 branch
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 5665b5cc31)
GL_RG_INTEGER only has two components, not three. I'll be surprised
if anyone ever tries to glReadPixels(..., GL_SHORT, GL_RG_INTEGER,
...). This was found by inspection.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 2e8f8cb383)
With 0963990 the flag was only set when Bind created the object. In
all cases where ::ARBsemantics could be true, this path never
happened. Instead, add a _Used flag to track whether a VAO has ever
been bound. On the first Bind, set the _Used flag, and set the
ARBsemantics flag to the correct value.
NOTE: This is a candidate for release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45423
(cherry picked from commit e06b1c65bc)
This is a hack, and it will result in incorrect rendering. However,
it does eliminate spurious warnings in several piglit CopyPixels tests
that involve floating-point depth buffers.
The real solution is to add a zf field to SWspan to store float Z
values. When a float depth buffer is involved, swrast should also
populate the zf field. I'll consider this post-8.0 work.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit af1477b088)
When GLAPIENTRY is __stdcall (ie Windows), the stack is popped by the
callee making the number/type of arguments significant, therefore
using a generic no-op causes stack corruption for many entry-points.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
in the clear-accum test. Just look at the swrast renderbuffer pointer
for handling swrast rbs.
(cherry picked from commit 42e9936ce6)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45428
Fixes these GCC warnings.
osmesa.c: In function ‘osmesa_renderbuffer_storage’:
osmesa.c:417: warning: comparison is always false due to limited range of data type
osmesa.c:423: warning: comparison is always false due to limited range of data type
osmesa.c:431: warning: comparison is always false due to limited range of data type
osmesa.c:437: warning: comparison is always false due to limited range of data type
osmesa.c:447: warning: comparison is always false due to limited range of data type
osmesa.c:453: warning: comparison is always false due to limited range of data type
osmesa.c:463: warning: comparison is always false due to limited range of data type
osmesa.c:466: warning: comparison is always false due to limited range of data type
osmesa.c:476: warning: comparison is always false due to limited range of data type
osmesa.c:479: warning: comparison is always false due to limited range of data type
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Signed-off-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 136791ebc1)
Fix this GCC warning with non-LLVM builds.
sp_screen.c: In function ‘softpipe_get_shader_param’:
sp_screen.c:141:28: warning: unused variable ‘sp_screen’ [-Wunused-variable]
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 8e543cc098)
Prior commit 576161289d,
the parameter format was bpp, thus both 24bit and 32bit formats were
requested with format set to 32. Handle 24bit seperately now.
Fixes RGBX formats in wayland platform for egl_dri2 (EGL_ALPHA_SIZE=0).
Note: This is a candidate for the 8.0 branch.
(cherry picked from commit c72d7df168)
Fixing a circular build dependency.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Christian König <deathsimple@vodafone.de>
(cherry picked from commit c2e2b58a58)
Substantially increases performance in GLBenchmark PRO:
- 320x240 => 3.28x
- 1920x1080 => 1.47x
- 2560x1440 => 1.27x
The LD message ignores the sampler unit index and SAMPLER_STATE pointer,
instead relying on hard-wired default state. Thus, there's no need to
worry about running out of sampler units or providing SAMPLER_STATE;
this small patch should be all that's required.
NOTE: This is a candidate for release branches.
(It requires the preceding commit to compile.)
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 259b65e2e7)
brw_SAMPLE is full of complex workarounds for original Broadwater
hardware, and I'd rather avoid all that for my next Ivybridge patch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 5f4575d42f)
We always access pull constant buffers using the message types "OWord
Block Read" or "OWord Dual Block Read". According to the Sandy Bridge
PRM, Vol 4 Part 1, pages 214 and 218, when using these messages:
"the surface pitch is ignored, the surface is treated as a
1-dimensional surface. An element size (pitch) of 16 bytes is
used to determine the size of the buffer for out-of-bounds
checking if using the surface state model."
Previously we were setting the pitch for pull constant buffers to the
size of the whole constant buffer--this made no sense and would have
led to incorrect behavior if it were not for the fact that the pitch
is ignored.
For clarity, this patch sets the pitch for pull constant buffers to 16
bytes, consistent with the hardware's behavior.
v2: Clarify the meaning of the ignored values by writing them as (16 - 1).
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit fcd5af4a91)
When ARB VAOs are used, glPopClientAttrib does not resurrect a deleted
VAO or VBO. This difference between the two spec is, unfortunately,
not very well spelled out in the specs.
Fixes oglc vao(advanced.pushPop.deleteVAO) and
vao(advanced.pushPop.deleteVBO) tests.
NOTE: This is a candidate for release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 34c353ce46)
There are more differences between Apple and ARB than just requiring
that all arrays be stored in VBOs. Additional uses will be added in
following commits.
Also, set the flag at Bind time instead of Gen time. The ARB_vao spec
specifies that behavior.
NOTE: This is a candidate for release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 0963990153)
This is a hack to work around drivers such as i965 that:
- Set _MaintainTexEnvProgram to generate GLSL IR for
fixed-function fragment processing.
- Don't call _mesa_ir_link_shader to generate Mesa IR from the
GLSL IR.
- May use swrast to handle glDrawPixels.
Since _mesa_ir_link_shader is never called, there is no Mesa IR to
execute. Instead do regular fixed-function processing.
Even on platforms that don't need this, the software fixed-function
code is much faster than the software shader code.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44749
(cherry picked from commit 9be3be3c66)
At least one place, the _mesa_need_secondary_color function in
state.h, uses this to make decisions. The next patch in this series
will add another dependency. Ideally, this field would go away and be
replace by a flag or something.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 34db7a8c1e)
When we're actually rendering into a texture, map the texture image
instead of the corresponding renderbuffer. Before, we just copied
a pointer from the texture image to the renderbuffer. This change
will make the code usable by hardware drivers.
(cherry picked from commit 1caf698191)
ctx->Driver.MapTexture() always points to _swrast_map_texture().
We're already reaching into swrast from t_vb_program.c anyway.
This will let us remove the ctx->Driver.Map/UnmapTexture() functions.
(cherry picked from commit 4bbab2275f)
This is a squash of:
dri/swrast: remove obsolete GetRow/PutRow code
(cherry picked from commit cb5fa9ea62)
and
dri/swrast: remove obsolete swrast_span.c file from source list
(cherry picked from commit a9bf149e7f)
Conflicts:
src/mesa/drivers/dri/swrast/Makefile.sources
All color buffer rendering is now done by accessing mapped renderbuffer
memory. We're now able to get rid of all the GetRow/PutRow stuff.
(cherry picked from commit 0ff817f200)
Instead of using the obsolete gl_renderbuffer::Data field.
Color buffer are still accessed through GetRow/PutRow().
(cherry picked from commit 7d1ddec921)
These are temporary, actually, but they'll make follow-on work easier to
implement in a step-by-step manner. Eventually the Map and RowStrideBytes
fields will go into a new swrast_renderbuffer type, but adding that type
now would involve touching a _lot_ of code that'll eventually be removed.
The fields marked as obsolete will go away completely at some point.
(cherry picked from commit 827c1d66f6)
That field is only used by swrast code so there's no reason to mess
with it in the gallium state tracker.
This also lets us remove the unused st_format_data() type function and
related code.
(cherry picked from commit ca6d86d26b)
When rowstride was negatie, unsigned promotion caused a segfault here:
299│ if (rb->Format == MESA_FORMAT_S8) {
300│ const GLuint rowStride = rb->RowStride;
301│ for (i = 0; i < count; i++) {
302│ if (x[i] >= 0 && y[i] >= 0 && x[i] < w && y[i] < h) {
303├> stencil[i] = *(map + y[i] * rowStride + x[i]);
304│ }
305│ }
306│ }
Fixes segfault in oglconform
separatestencil-neu(NonPolygon.BothFacesBitmapCoreAPI),
though test still fails.
Note: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit aed5c8299f)
Fixes Intel oglconform negative.typeFormatMismatch.copyteximage.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 422b18794e)
This is part of fixing Intel oglconform
negative.typeFormatMismatch.copyteximage.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit ee9804af14)
This code is unprepared for handling integer (particularly, the
baseFormat of the TexFormat comes out as GL_RGBA, not GL_RGBA_INTEGER,
so the direct call of Driver.ReadPixels crashes due to the int vs
non-int error checking not having happened). I'm frankly tempted to
convert this code to MapRenderbuffer/MapTexImage rather than doing it
as meta ops, now that we have that support.
Improves the remaining crash in Intel oglconform for int-textures to
just a rendering failure.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 6bf0f6ae86)
This aborts and crashes in intel oglconform's int-textures into being
just rendering failures. Clamping isn't handled yet.
v2: Add missing "break".
v3: Drop the int/uint distinction, since they don't need different clamping.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com> (v2)
(cherry picked from commit d6c58545a1)
Similarly to how we handle this in texstore, we have to remap height
to depth so that we MapTextureImage each image layer individually.
Fixes part of Intel oglconform's int-textures advanced.fbo.rtt
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 08acd4bd61)
This is a step toward fixing Intel oglconform's
int-textures advanced.fbo.rtt.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 9f1e64d085)
This doesn't result in correct rendering -- GL requires that logic ops
work, while the hardware specs say it doesn't do them. I'm not sure
how we would want to handle this.
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit f6e82cd2a1)
Fixes GPU hangs and some rendering failures in piglit
EXT_texture_integer/fbo-blending
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 04b4880d7c)
We just prefix the $CLANG environment variable in configure.ac with acv_mesa_
Found by: tinderbox
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit b728eefb06)
A current incomplete framebuffer was incorrectly used as a
st_framebuffer. When accessing st_framebuffer childs bad things happen:
e.g. st_framebuffer::iface was used to check whether its an incomplete
fb, instead we need to compare st_framebuffer::Base against
mesa_get_incomplete_framebuffer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44919
Note: This is a candidate for the 8.0 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 36fb83e4a8)
While reading through the simulator, I found some interesting code that
looks like it checks the sampler default color pointer against the bound
set in STATE_BASE_ADDRESS. On failure, it appears to program it to the
base address itself.
So I decided to try programming a legitimate bound, and lo and behold,
border color worked.
+92 piglits on Sandybridge. Also fixes Lightsmark on Ivybridge.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28924
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38868
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit c25e5300cb)
Fix this GCC warning on non-debug builds.
glsl_types.cpp: In member function 'gl_texture_index
glsl_type::sampler_index() const':
glsl_types.cpp:157: warning: control reaches end of non-void function
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit e9bcf4d56b)
This loosens the format validation in glBlitFramebuffer. When blitting
depth bits, don't require an exact match between the depth formats; only
require that the two formats have the same number of depth bits and the
same depth datatype (float vs uint). Ditto for stencil.
Between S8_Z24 buffers, the EXT_framebuffer_blit spec allows
glBlitFramebuffer to blit the depth and stencil bits separately. So I see
no reason to prevent blitting the depth bits between X8_Z24 and S8_Z24 or
the stencil bits between S8 and S8_Z24. However, we of course don't want
to allow blitting from Z32 to Z32_FLOAT.
Fixes Piglit fbo/fbo-blit-d24s8 on Intel drivers with separate stencil
enabled.
The problem was that, on Intel drivers with separate stencil, the default
framebuffer has separate depth and stencil buffers with formats X8_Z24 and
S8. The test attempts to blit the depth bits from a S8_Z24 buffer into the
default framebuffer.
v2: Check that depth datatypes match.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44665
Note: This is a candidate for the 8.0 branch.
Reported-by: Xunx Fang <xunx.fang@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit f74d8aacbf)
Commit ede60bc467 (glsl: Add isinf() and
isnan() builtins) uses "+INF" in the .ir file to represent infinity.
This worked on C99-compliant compilers, since the s-expression reader
uses strtod() to read numbers, and C99 requires strtod() to understand
"+INF". However, it didn't work on non-C99-compliant compilers such
as MSVC.
This patch modifies the s-expression reader to explicitly check for
"+INF" rather than relying on strtod() to support it.
This is a candidate for the 8.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44767
Tested-by: Morgan Armand <morgan.devel@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 4f82fed493)
The default access flags for OpenGL ES (via GL_OES_map_buffer) and
desktop OpenGL are different. The code previously tried to handle
this, but the decision was made at compile time. Since the same
driver binary can be used for both OpenGL ES and desktop OpenGL, the
decision must be made at run-time.
This should fix bug #44433. It appears that the test case does
various map and unmap operations and inspects the state of the buffer
object around each. When it sees that GL_BUFFER_ACCESS does not match
its expectations, it fails.
NOTE: This is a candidate for release branches.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44433
(cherry picked from commit f0ea46790f)
msg_type moved by a bit, so the message type was being disassembled
incorrectly. In particular, render target writes were showing up as
"OWORD block write".
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit dcdfd1905c)
Compared to sampler_gen5, simd_mode shifted by a bit and msg_type grew
by a bit. So we were printing slightly incorrect numbers.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit a608be5d33)
Both the VF and VS share space in the URB. First, the VF stores
attributes (shader inputs) there. The VS then reads the attributes,
executes, and reuses the space to store varyings (shader outputs).
Thus, we need to calculate the amount of URB space necessary for inputs,
outputs, and pick whichever is greater.
The old VS backend correctly did this (brw_vs_emit.c:408), but the new
VS backend only considered outputs.
Fixes vertex scrambling in GLBenchmark PRO on Ivybridge.
NOTE: This is a candidate for the 8.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41318
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 2e712e41db)
This is a squash of the following two commits. The first caused a
regression on SNB systems without a HiZ capable DDX, and the second
fixes that regression.
i965: Add support for Z16 depth formats.
v2: Don't flag the format as being HiZ ready (there's DRI2 handshake
pain to go through).
Fixes piglit gl-3.0-required-sized-texture-formats
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 2f868f1ddd)
intel/gen6: Some framebuffers having separate depthstencil should be unsupported
When the framebuffer has separate depth and stencil buffers, and HiZ is
not enabled on the depth buffer, mark the framebuffer as unsupported. This
happens when trying to create a framebuffer with Z16/S8 because we haven't
enabled HiZ on Z16 yet.
Fixes gles2conform test stencil8.
Note: This is a candiate for the 8.0 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44948
Reviewed-and-tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed--by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit ba5252e590)
This is required for Z16 support for texturing, which is the first
thing to have a horizontal alignment of 8. Renderbuffers don't need
it, since they're always set up as the only mip level, but do it for
completeness anyway.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit f0d5c92a4c)
This field is actually set up above.
NOTE: This is a candidate for the 8.0 branch, to avoid conflicts.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit fc767ff590)
I copy-and-pasted the thing I was allocating for as the context, so
the first time it would be NULL (root of a ralloc context) and they'd
chain off each other from then on.
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 5a0f395bcf)
This statement got duplicated above, probably in a rebase resolution,
so we never freed the extra one.
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 7f278e15ad)
Fixes a leak of almost 200kb on a minimal shader_runner program
(algebraic-add-add-1).
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit b2be486962)
Update the dd.h docs to indicate that GL_MAP_INVALIDATE_RANGE_BIT
can be used with GL_MAP_WRITE_BIT when mapping renderbuffers and
texture images.
Pass the flag when mapping texture images for glTexImage, glTexSubImage,
etc. It's up to drivers whether to actually make use of the flag.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 64fdfefb9d)
To try to use less tex memory and maybe get better performance.
Spotted by Roland Scheidegger.
NOTE: This is a candidate for the 8.0 and 7.11 branches.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit 1d7048f12e)
The i965 driver advertises GL_ARB_texture_float and GL_ARB_texture_rg
support but the ctx->TextureFormatSupported[] table entries for
MESA_FORMAT_R_FLOAT32 and MESA_FORMAT_RGBA_FLOAT32 are false on gen 4
hardware. So the case for GL_R32F would fail and we'd print an
implementation error.
This patch adds more Mesa tex format options for GL_R32F and other R/G
formats so we fall back to 16-bit formats when 32-bit formats aren't
available.
Eric made the same fix in commit 6216a5b4 for the non R/G formats.
v2: try 16-bit formats before 32-bit formats and try RG formats before
RGBA where possible.
This should fix https://bugs.freedesktop.org/show_bug.cgi?id=44039
NOTE: This is a candidate for the 8.0 and 7.11 branches.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
(cherry picked from commit 7628696004)
When I originally implemented the hack to use GRFs 111+ as fake MRFs, I
did so purely to avoid rewriting all the code that dealt with MRFs.
However, it turns out that a similar hack is actually required.
Newly discovered language in the BSpec indicates that SEND instructions
with EOT set "should" use g112-g127 as their source registers. Based on
assertions in the simulator, this is actually a requirement on certain
platforms.
Since we're faking MRFs already, we may as well use the officially
sanctioned range. My guess is that we avoided this issue because we
seldom use m0: URB writes in the new VS backend start at m1, and RT
writes in the new FS backend start at m2.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 5acc7f38d4)
Make the comments precise. Explain why each branch is needed and correct.
Document the potential pitfall in the true-branch.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit e13c99a004)
The nvc0 gallium driver is advertising 128 MAX_INTERLEAVED_COMPS
which made it always assert in the linker when TFB was used since
the Outputs array was smaller than that maximum.
v2: added assertions
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
(cherry picked from commit d540af554a)
Flat SHADE_MODEL still overrides any non-flat interpolation
qualifier, but pulling that state out of the rasterizer cso
isn't really worth the effort, is it ?
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit af0ce1dba8)
Due to the changes for multiple kcache banks support, now we are assigning
final SRCx_SEL values for kcache access at the later stage, when building the
bytecode. So we need to take into account kcache banks to distinguish
the constants with the same address but different bank index.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 840a342cd0)
Clip planes are uploaded as a constant buffer and used by the vertex
shader to produce corresponding clip distances for hw clipping.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 54e8dcaad6)
Conflicts:
src/gallium/drivers/r600/r600_state_common.c
Add support for multiple kcache banks (constant buffers).
Lock the required lines only.
Allow up to 4 kcache line sets in the alu clause by using ALU_EXTENDED on eg+.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit d649bf51ec)
v2: select the colors in the pixel shader
v3: fix rs state creation for pre-evergreen
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 725a820b92)
"If set, forces degamma on XYZ if format is
FMT_8_8_8_8, FMT_BC1, FMT_BC2, or FMT_BC3"
Don't claim support for sRGB on any other formts.
This fixes glean texture_srgb.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit a9d8809f16)
So it appears R600s (except rv670) do AR handling different using a different
opcode. This patch fixes up r600g to work properly on r600.
This fixes ~100 piglit tests here (in GLSL1.30 mode) on rv610.
v3: add index_mode as per the docs.
This still fails any dst relative tests for some reason I can't quite see yet,
but it passes a lot more tests than without.
v4: add a nop after dst.rel this could be improved using a second pass,
where we only insert nops if two instructions are sure to collide.
The docs say r600, rv610, rv630 needs this, and not rv670, rs780, rs880,
need AMD to confirm rv620, rv635.
v5: add is_nop_inst.
NOTE: This is a candidate for stable branches.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit c96b983403)
The original R600 requires the UNCACHED_FIRST_INST bit
to be set in the PS.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Note: this is candidate for the stable branches.
(cherry picked from commit 46ce25722b)
Now that we no longer generate Mesa IR from GLSL IR, it's impossible to
use the old vertex shader backend for GLSL programs. There's simply no
Mesa IR to codegen from.
Any attempt to do so would result in immediate GPU hangs, presumably due
to the driver uploading an empty program with no EOT message.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
(cherry picked from commit bdedd03b70)
According to Table 6.8 (Page 348) in the OpenGL 3.0 specification,
glGetVertexAttribiv supports GL_VERTEX_ATTRIB_ARRAY_INTEGER.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit d56ad273c0)
Fixes the following OGLConform tests on gen5:
depth-stencil(misc.state_on.depth_int)
fbo_db_ARBfp(basic.OnlyDepthBuffDrawBufferRender)
The problem was that, if the depth buffer's Mesa format was X8_Z24, then
we emitted the hardware format D24_UNORM_X8. But, on gen5, D24_UNORM_S8
must be emitted.
This bug was introduced by:
commit d84a180417
Author: Eric Anholt <eric@anholt.net>
i965: Base HW depth format setup based on MESA_FORMAT, not bpp.
v2: Deref 'intel' directly. Move the branch for newer chipset to top.
Quote the PRM. As requested by Ken.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43408
Note: This is a candidate for the 8.0 branch.
Reported-by: Xunx Fang <xunx.fang@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit a6dd4bf5fc)
TestMipMaps() function in src/OGLconform/textureNPOT.c calls glTexImage2D()
with width = 0. Texture with zero size skips miptree allocation due to a
condition in function _mesa_store_teximage3d(). While calling glGetTexImage()
it results in assertion failure in intel_map_texture_image() due to null mt
pointer.
This patch fixes the issue by detecting the zero size texture early in
glGetTexImage and glGetCompressedTexImage functions. In such a case function
simply returns doing nothing.
Verified that below mentioned bug is fixed by this patch.
https://bugs.freedesktop.org/show_bug.cgi?id=42334
NOTE: This is a candidate for stable branches
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit f1a9a9bcd1)
Nothing works if HiZ is enabled and the DDX is incapable of HiZ (that is,
the DDX version is < 2.16).
The problem is that the refactoring that eliminated
intel_renderbuffer::stencil_rb broke the recovery path in
intel_verify_dri2_has_hiz(). Specifically, it broke line
intel_context.c:1445, which allocates the region for
DRI_BUFFER_DEPTH_STENCIL. That allocation was creating a separate stencil
miptree, despite the buffer being a packed depthstencil buffer. Havoc
ensued.
This patch introduces a bool flag that prevents allocation of that stencil
miptree.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44103
Tested-by: Ian Romanick <idr@freedesktop.org>
Note: This is a candidate for the 8.0 branch.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 7e08bf08d1)
Calling glXSwapBuffers with no bound context causes segmentation
fault in function intelDRI2Flush. All the gl calls should be
ignored after setting the current context to null. So the contents
of framebuffer stay unchanged. But the driver should not seg fault.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44614
Reported-by: Yi Sun <yi.sun@intel.com>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Yi Sun <yi.sun@intel.com>
(cherry picked from commit dd7220652e)
only check ARB_fbo, add shader_texture_lod as a requirement
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 5596db7411)
Commit 9bdc44a528 (i965: Replace struct
with bit shifting for WM pull constant surfaces) accidentally
introduced off-by-one errors into the calculation of the surface
width, height, and depth. This patch restores the correct
computation.
The reason this wasn't noticed by Piglit tests is that the size of our
constant surfaces is always less than 2^20, therefore the off-by-one
error was causing the "depth" field of the surface to be set to all
1's. The hardware interpreted this as an extremely large surface, so
overflow checking was effectively disabled.
No Piglit regressions on Sandy Bridge.
NOTE: This is a candidate for the 7.11 and 8.0 branches.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit f6f43bd5a2)
Fixes piglit EXT_framebuffer_multisample/negative-copypixels.
Reviewed-by: Brian Paul <brianp@vmware.com>
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 9be6654c1f)
Fixes piglit EXT_framebuffer_multisample/negative-copyteximage.
Reviewed-by: Brian Paul <brianp@vmware.com>
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 6950a4faf6)
Fixes piglit EXT_framebuffer_multisample-negative-readpixels.
Reviewed-by: Brian Paul <brianp@vmware.com>
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 86b7c6707f)
Fixes piglit EXT_framebuffer_multisample/renderbuffer-samples.
Reviewed-by: Brian Paul <brianp@vmware.com>
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 0e8d156c3c)
Fixes some _mesa_problem()s in oglconform.
Reviewed-by: Brian Paul <brianp@vmware.com>
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit f83756f80f)
Previously, we were saying that everything from the starting tile to
region width+height was part of the limits of our depthbuffer, even if
the tile was near the bottom of the depthbuffer. This mean that our
range was not clipping to buffer buonds if the start tile was anything
but the start of the buffer.
In bebc91f0f3, this was changed to
saying that we're just rendering to a region of the size of the
renderbuffer. This is great -- we get a range that should actually
match what we want. However, the hardware's range checking occurs
after the X/Y offset addition, so we were clipping out rendering to
small depth mip levels when an X/Y offset was present. Just add
tile_x/y to the width in that case -- the WM won't produce negative
x/y values pre-offset, so we just need to get the left/bottom sides of
the region to cover our buffer.
Fixes the following Piglit regressions on gen7:
spec/ARB_depth_buffer_float/fbo-clear-formats
spec/ARB_depth_texture/fbo-clear-formats
spec/EXT_packed_depth_stencil/fbo-clear-formats
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit e6d6a10c5a)
When using Mesa with a GLES API, calling _mesa_FramebufferRenderbuffer
with GL_DRAW_FRAMEBUFFER will report a 'user error' because
get_framebuffer_target validates that this enum from the framebuffer
blit extension is only used on GL. To work around it this patch makes
it use the GL_FRAMEBUFFER enum instead in that case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43418
Note: This is a candidate for the 8.0 branch.
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 9462b84478)
The AL44 format occupies one byte, not two.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit b0af16abf1)
The gl_renderbuffer::Format field wasn't always set properly. This
didn't matter much in the past but with the recent swrast/renderbuffer
mapping changes, core Mesa will be directly touching OSMesa colorbuffers
so using the right MESA_FORMAT_x value is important.
Unfortunately, there aren't MESA_FORMATs for all the possible OSmesa
format/type combinations, such as GL_FLOAT / OSMESA_ARGB. If anyone
runs into these we can add new Mesa formats.
v2: add warnings for unsupported formats, fix ARGB_REV mix-up.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit 540a8b2cfd)
This fixes accum buffer operations. The accumulation buffer is the
only malloc-based renderbuffer for the intel drivers.
v2: apply x/y offset to returned pointer
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 6dbdc03956)
The array holds GLuint values so remove the float cast.
Note, however, that to compute the average of four GLuints we really
want to do (a+b+c+d)/4 but that could overflow. This change doesn't
address that for now.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit 003dd8adf3)
ir_variable is a class, not a struct.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit decd018b99)
In the first case, the newImage[] array contains GLuint values.
In the second case, the parameter type is GLuint, but the maxDepth
value is never used in this case (GL_FLOAT_32_UNSIGNED_INT_24_8_REV).
Pass ~OU just to be safe.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit a240c998ac)
And pass integer width, height values.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
(cherry picked from commit 2f0fa456e3)
glsl_to_tgsi_visitor is earlier defined as a class, not a struct.
Fixes MSVC warning.
NOTE: This is a candidate for the 8.0 branch.
(cherry picked from commit 9f2963b631)
Still some work to be done before this is finished.
This is a candidate for 8.0 branch.
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 3e044bcc4b)
# Work around aliasing bugs - developers should comment this out
CFLAGS += -fno-strict-aliasing
CXXFLAGS += -fno-strict-aliasing
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
