vg_manager_validate_framebuffer should mark the fb dirty and have
vg_validate_state call cso_set_framebuffer. Rename VIEWPORT_DIRTY to
FRAMEBUFFER_DIRTY.
The states are designated for polygon filling. Polygon filling is a
two-pass process utilizing the stencil buffer. polygon_fill and
polygon_array_fill functions are updated to make use of the state.
This state provides the ability to clear rectangles of the framebuffer
to the specified color, honoring scissoring. vegaClear is updated to
make use of the state.
This state provides glDrawTex-like function. It can be used for
vgSetPixels.
Rather than modifying every user of the renderer, this commit instead
modifies renderer_copy_surface to use DRAWTEX or COPY state internally
depending on whether the destination is the framebuffer.
Renderer states are high-level states to perform specific tasks. The
renderer is initially in INIT state. In that state, the renderer is
used for OpenVG pipeline.
This commit adds a new COPY state to the renderer. The state is used
for copying between two pipe resources using textured drawing. It can
be used for vgCopyImage, for example.
Rather than modifying every user of the renderer, this commit instead
modifies renderer_copy_texture to use the COPY state internally.
This branch defines a gallivm_state structure which contains the
LLVMBuilderRef, LLVMContextRef, etc. All data structures built with
this object can be periodically freed during a "garbage collection"
operation.
The gallivm_state object has to be passed to most of the builder
functions where LLVMBuilderRef used to be used.
Conflicts:
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
src/gallium/drivers/llvmpipe/lp_state_setup.c
I made the texwrap test be more thorough and realized that this driver code
had not been quite right. This commit fixes the border color for depth
textures, compressed textures, and 16-bits-per-channel textures
with up to 2 channels (R16, RG16).
NOTE: This is a candidate for the 7.9 branch.
Previously, IR for a linked shader was allocated directly out of the
gl_shader object - meaning all of it lived as long as the shader.
Now, IR is allocated out of a temporary context, and any -live- IR is
reparented/stolen to (effectively) the gl_shader. Any remaining IR can
be freed.
NOTE: This is a candidate for the 7.9 branch.
This makes a very simple 1.30 shader go from 196k of memory to 9k.
NOTE: This -may- be a candidate for the 7.9 branch, as the benefit is
substantial. However, it's not a simple change, so it may be wiser to
wait for 7.10.
We were trying to emit a single ir_expression to compare the whole
thing. The backends (ir_to_mesa.cpp and brw_fs.cpp so far) expected
ir_binop_any_nequal or ir_binop_all_equal to apply to at most a vector
(with matrices broken down by the lowering pass). Break them down to
a bunch of ORed or ANDed any_nequals/all_equals.
Fixes:
glsl-array-compare
glsl-array-compare-02
glsl-fs-struct-equal
glsl-fs-struct-notequal
Bug #31909
This doesn't cover all expressions or all operand types, but it will
complain if you overreach and it allows for much greater slack on the
programmer's part.
This code was for the old GLcore build of the software rasteriser. The
X server switched to a DRI driver for software indirect GLX long ago.
Signed-off-by: Adam Jackson <ajax@redhat.com>
There are also some u_simple_shaders changes.
On r300, the TGSI_SEMANTIC_COLOR varying is a fixed-point number clamped
to the range [0,1] and limited to 12 bits of precision. Therefore we can't
use it for passing through a clear color in order to clear high precision
texture formats.
This also makes u_blitter use only one vertex shader instead of two.
Since the viewport is not updated on RandR12 mode switches anymore,
clipping to viewport may incorrectly clip away the video.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
This may help paint the colorkey before overlay updates in some
situations where the app paints the color key (mainly xine).
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
The compiler seriously needs a cleanup as far as the arrangement of functions
is concerned. It's hard to know whether some function was implemented or not
because there are so many places to search in and it can be anywhere and
named anyhow.
