There's a serious trap for drivers: RenderTexture() does not indicate
that the texture is currently bound to the draw buffer, despite
FinishRenderTexture() signaling that the texture is just now being
unbound from the draw buffer.
We were acting as if RenderTexture() *was* the start of rendering and
that we could make texturing incoherent with the current contents of
the renderbuffer. This caused intel oglconform sRGB
Mipmap.1D_textures to fail, because we got a call to TexImage() and
thus RenderTexture() on a texture bound to a framebuffer that wasn't
the draw buffer, so we skipped validating the new image into the
texture object used for rendering.
We can't (easily) make RenderTexture() indicate the start of drawing,
because both our driver and gallium are using it as the moment to set
up the renderbuffer wrapper used for things like MapRenderbuffer().
Instead, postpone the setup of the workaround render target miptree
until update_renderbuffer time, so that we no longer need to skip
validation of miptrees used as render targets. As a bonus, this
should make GL_NV_texture_barrier possible.
(This also fixes a regression in the gen4 small-mipmap rendering since
3b38b33c16, which switched
set_draw_offset from image->mt to irb->mt but didn't move the irb->mt
replacement up before set_draw_offset).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961
NOTE: This is a candidate for the 8.0 branch.
Infer from the operand the type of value to store.
MOV is untyped but we use the float store path.
v2: make MOV use float store path.
I've had to squash merge the ARL fix to be stored
as an integer in here to avoid regressions in a number
of piglit tests.
From now on ARL stores to an integer just like HW does.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The infers the type of data required using the opcode,
and casts the input to the appropriate type.
So far this only handles non-indirect constant and temporaries.
v2: as per Jose suggestion, fetch immediates via floats
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are used inside the action handlers for the integer opcodes.
v2: use uint_bld/int_bld, drop higher level uint_bld.
Signed-off-by: Dave Airlie <airlied@redhat.com>
For now just pass the current context, but when we want to
store int or unsigned we need to pass those later.
Signed-off-by: Dave Airlie <airlied@redhat.com>
These two functions produce the src/dst types for an opcode.
MOV is special since it can be used to mov float->float and int->int,
so just return VOID.
v2: use a new enum for the opcode type as per Jose's suggestion.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the texture format is integer, the incoming user data must also be
integer (and similarly for non-integer textures).
NOTE: This is a candidate for the stable branches.
Reviewed-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
I recently discovered this text in the BSpec. It seems wise to comply,
though I haven't observed it to fix anything yet.
Fixes a regression in glean/fbo since 28cfa1fa21.
NOTE: This is a candidate for stable release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45221
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes (with the previous commit) piglit GL_ARB_multisample/pushpop.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
In the table of of push/pop attributes, this one doesn't fall under
the enable group.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
If the generated shader for _TexEnvProgram is empty, force the use of
the fixed-function code. Otherwise, go ahead and use the shader.
This works around a mysterious issue on i915 where fixed-function
software fallbacks are not working correctly.
This isn't really the fix we want, but it works around the issue.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45872
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45876
This fixes build errors like
In file included from glapi_dispatch.c:91:
../../../src/mapi/glapi/glapitemp.h:4641: error: no previous prototype for
'glDrawBuffersNV'
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Lucas Stach <dev@lynxeye.de>
Similar to the previous commit. Also fix incorrect setting of the
sampler view's state after it's created. We need to specify the
first/last_level fields in the template instead.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Rather than the one in st_texture_object. This sampler view really has
no connection to the one used for rendering.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
And remove needless & 0xff in _mesa_pack_uint_24_8_depth_stencil_row().
As suggested by José.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Previously, this function only handled 2D textures.
The fallback texture is used when we try to sample from an incomplete
texture object. GLSL says sampling an incomplete texture should return
(0,0,0,1).
v2: use a 1-texel texture image, per José.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Added in _mesa_pack_uint_24_8_depth_stencil_row(). This could be hit
by something like glDrawPixels(GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8)
into a MESA_FORMAT_Z32_FLOAT_X24S8 buffer.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
The st_renderbuffer_alloc_storage() function is used to allocate both
window-system buffers and user-created renderbuffers. The later kind
are never directly displayed so don't set PIPE_BIND_DISPLAY_TARGET for
those surfaces.
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Commit dc7f449d1a introduced a new method
for avoiding MOVs: try to rewrite the destination of the instruction
that produced the RHS so it writes into the LHS.
Unfortunately, this is not safe for swizzled texturing operations, as
they return a set of four contiguous registers. Consider the following:
(assign (x)
(var_ref vec_ctor_x)
(swiz x (tex vec4 (var_ref m_sampY) (var_ref m_cordY) 0 1 ())))
In this case, the source and destination registers are equal, since
reg_offset is 0 for both. Yet, this is only a partial move: the texture
operation generates four registers, and the LHS only covers one.
Fixes color distortion in XBMC when using GLSL shaders.
NOTE: This is a candidate for the 8.0 branch (with the previous commit).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44333
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Certain instructions write more than one register. Texturing, for
example, returns 4 registers. (We set rlen to 4 even for TXS and float
shadow sampling.) Some math functions return 2. Most return 1.
The next commit introduces a use of this function.
NOTE: This is a candidate for the 8.0 branch (dependency of a fix).
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
