The swrast ReadPixels code has no dependencies on swrast since moving
to Map/UnmapRenderbuffer(). We'll be able to remove s_readpix.c and
remove the state tracker's glReadPixels code next.
Acked-by: Eric Anholt <eric@anholt.net>
This was only used by the xlib driver to add an alpha channel to the
front/window color buffer. This was no longer going to work well with
the move to direct mapping of renderbuffers.
Reviewed-by: Eric Anholt <eric@anholt.net>
Seldom used and this won't work when we move to using Map/UnmapRenderbuffer
everywhere. This will let us remove a bunch of core Mesa code too.
Reviewed-by: Eric Anholt <eric@anholt.net>
For a depthstencil buffer with separate stencil,
intel_renderbuffer::region is null. (The regions are kept in hidden depth
and stencil buffers). Since the region is null, intel_map_renderbuffer()
assumed there was no data and returned a null map pointer, which in turn
was dereferenced (!) by MapRenderbuffer's caller.
This patch fixes intel_map_renderbuffer() to map the hidden depth buffer
through the GTT and return that as the mapped pointer. Also, the stencil
bits are scattered and gathered when needed.
Fixes the following Piglit tests on gen7:
fbo/fbo-readpixels-depth-formats
hiz/hiz-depth-read-fbo-d24s8
hiz/hiz-stencil-read-fbo-d24s8
EXT_packed_depth_stencil/fbo-clear-formats
EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-blit
EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-drawpixels
EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-readpixels
EXT_packed_depth_stencil/fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-24_8
EXT_packed_depth_stencil/fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-FLOAT-and-USHORT
EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
If a window system stencil buffer had a region with odd height, then the
calculated y offset needed for software detiling was off by one. The bug
existed in intel_{map,unmap}_renderbuffer_s8() and in the intel_span.c
accessors.
Fixes the following Piglit tests on gen7:
general/depthstencil-default_fb-readpixels-24_8
general/depthstencil-default_fb-readpixels-FLOAT-and-USHORT
Fixes SIGABRT in the following Piglit tests on gen7:
general/depthstencil-default_fb-blit
general/depthstencil-default_fb-copypixels
general/depthstencil-default_fb-drawpixels-24_8
general/depthstencil-default_fb-drawpixels-FLOAT-and-USHORT
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
When gathering the temporary buffer's pixles into the gem buffer, we had
the two buffers juxtaposed. Oops.
Fixes the following Piglit tests on gen7:
general/GL_SELECT - alpha-test enabled
general/GL_SELECT - depth-test enabled
general/GL_SELECT - no test function
general/GL_SELECT - scissor-test enabled
general/GL_SELECT - stencil-test enabled
Fixes SIGABRT in Piglit tests EXT_framebuffer_object/fbo-stencil-* on
gen7.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
The function already implements 3 cases (map through GTT, blit to
a temporary, and detile stencil buffer to temporary), and a 4th will be
added soon: scatter/gather for depthstencil buffers using separate
stencil. For sanity's sake, this factors each case out into its own
function.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
Don't call set_unfiform_initializers if link failed, or it would trigger
a GL_INVALID_OPERATION error. That's not an expected behavior of
glLinkProgram function.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Previously, we would fail to compile the following shader due to a bug
in lazy built-in importing:
#version 130
void main() {
float f = abs(5.0);
int i = abs(5);
}
The first call, abs(5.0), would fail to find a local signature, look
through the built-ins, and import "float abs(float)".
The second call, abs(5), would find the newly imported float signature
in the local shader, and settle for that. Unfortunately, it failed to
search the built-ins for the correct/exact signature, "int abs(int)".
Thus, abs(5) ended up being a float, causing a bizarre type error when
we tried to assign it to an int.
Fixes piglit test builtin-overload-matching.frag.
This is /not/ a candidate for stable branches, as it should only be
possible to trigger this bug using GLSL 1.30's built-in functions that
take integer arguments. Plus, the changes are fairly invasive.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
match_function_by_name performs two fairly separate tasks:
1. Hunt down the appropriate ir_function_signature for the callee.
2. Generate the actual ir_call (assuming we found the callee).
Both of these are complicated. The first has to handle exact/inexact
matches, lazy importing of built-in prototypes, different scoping rules
for 1.10, 1.20+, and ES. Not to mention printing a user-friendly error
message with pretty-printed "maybe you meant this" candidate signatures.
The second has to deal with void/non-void functions, pre-call implicit
conversions for "in" parmeters, and post-call "out" call conversions.
Trying to do both in one function is just too unwieldy. Time to split.
This patch purely moves the code to generate an ir_call into a separate
function and reindents it. Otherwise, the code is identical.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
When matching function signatures across multiple linked shaders, we
often want to see if the current shader has _any_ match, but also know
whether or not it was exact. (If not, we may want to keep looking.)
This could be done via the existing mechanisms:
sig = f->exact_matching_signature(params);
if (sig != NULL) {
exact = true;
} else {
sig = f->matching_signature(params);
exact = false;
}
However, this requires walking the list of function signatures twice,
which also means walking each signature's formal parameter lists twice.
This could be rather expensive.
Since matching_signature already internally knows whether a match was
exact or not, we can just return it to get that information for free.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
We need something that looks like a compiler and not like some hacker
put some functions together. /rant
This is a band-aid for these two problems:
- The R600 and EG control-flow instructions appear in switch statements
next to each other, causing conflicts when adding new instructions.
- The ALU control-flow instructions are bitshifted by 3 (from CF_INST 26:29
to CF_INST 23:29, as is defined by r600 ISA) even for EG, where CF_INST
is 22:29.
To fix this mess, the 'inst' field is bitshifted to the left either by 22, 23,
or 26 (directly in the definitions), such that it can be just or'd when making
bytecode without any shifting. All switch statements have been divided into
two, one for R600 and the other for EG.
Of course, there is a better way to do this, but that is left for future
work.
Tested on RV730 and REDWOOD with no regressions.
v2: minor cleanup as per Alex's comment.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
These checks are now performed by the linker.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is also done in ir_to_mesa and st_glsl_to_tgsi, but that code
will be removed soon.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If they were disabled on entry, and we enabled one (like for
BlitFramebuffer), we wouldn't disable it on the way out. Retain the
attempted optimization here (don't keep calling to set each bit for
changes that won't matter) by just setting the bits directly with
appropriate flushing.
Fixes misrendering on the second draw of piglit fbo-blit.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It's unlikely that we changed the object but no other texture
parameter, but be correct anyway. Noticed by inspection.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Also, actually update const_storage_size, therefore avoiding to
unnecessarily reallocate aligned_constant_storage every single time
draw_vs_set_constants() is called.
Reviewed-by: Brian Paul <brianp@vmware.com>
