| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
u_vbuf_upload_buffers modifies the buffer offsets. If they are not
restored, and any of the vertex formats is not supported natively, the
next u_vbuf_mgr_draw_begin call will translate the vertex buffers with
incorrect buffer offsets.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ES 2.0.25 page 127 says:
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
querying any other pname will generate INVALID_ENUM.
See also:
b9e9df78a03edb35472c2e231aef4747e09db792
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Reviewed-by: Ian Romanick <[email protected]>
|
| |
| |
| |
| |
| | |
This doesn't include nvfx since its context struct is not derived
from common nouveau_context (yet).
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The GLSL 1.20 and later specs say:
"Recursion is not allowed, not even statically. Static recursion is
present if the static function call graph of the program contains
cycles."
Recursion is detected and rejected both a compile-time and at
link-time. The complie-time check happens to detect some cases that
may be removed by various optimization passes. The spec doesn't seem
to allow this, but other vendors (e.g., NVIDIA) appear to only check
at link-time after all optimizations.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33885
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Also clarify the documentation for one of the parameters.
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
| |
| |
| | |
See also comments in the code.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The behavior of flushes in the hardware is a maze of twisty passages,
and strangely the VS constants appear to be loaded during a pipeline
flush instead of at the time of the packet emit according to the
simulator. On moving the STATE_BASE_ADDRESS packet to where it really
needed to live (in order for data loads by other packets to be
correct), we sometimes no longer got a flush between those packets
where we apparently needed it. This replicates the flushes implied by
a STATE_BASE_ADDRESS update, fixing the GPU hangs in OGLC and the
"engine" demo.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36821
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39257
Tested-by: Keith Packard <[email protected]> (bzflag and etracer fixed)
Acked-by: Kenneth Graunke <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| | |
There's scary stuff going on in PIPE_CONTROL internals, and if the
BSpec says to do this to make PIPE_CONTROL work, I'll go ahead and do
it because we'll probably never be able to debug it after the fact.
v2: Use stall at scoreboard instead of depth stall, as noted by Ken.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For this and occlusion queries, we're trying to avoid setting
I915_GEM_DOMAIN_RENDER for the write domain, because the data written
is definitely not going through the render cache, but we do need to
tell the kernel that the object has been written. However, with using
I915_GEM_DOMAIN_GTT, the kernel on retiring the batchbuffer sees that
the w/a BO has a write domain of GTT, and puts it on the flushing
list. If something tries to wait for that BO to finish rendering
(such as the AUB dumper reading the contents of BOs), we get into
wait_request (since obj->active) but with a 0 seqno (since the object
is on the flushing list, not actually on a ringbuffer), and BUG_ONs.
To avoid the kernel bug (which I'm hoping to delete soon anyway), just
use I915_GEM_DOMAIN_INSTRUCTION like occlusion queries do. This
doesn't result in more flushing, because we invalidate INSTRUCTION on
every batchbuffer now that we're state streaming, anyway.
Reviewed-by: Kenneth Graunke <[email protected]>
Tested-by: Kenneth Graunke <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
Improves firefox-talos-gfx performance under GL when 3D clears are
enabled:
[ 0] gl-before firefox-talos-gfx 20.193 20.251 0.27% 3/3
[ 0] gl-after firefox-talos-gfx 18.013 18.040 0.19% 3/3
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This cuts out a large portion of the overhead of glClear() from
resetting the texenv state and recomputing the fixed function
programs. It also means less use of fixed function internally in our
GLES2 drivers, which is rather bogus.
Reviewed-by: Brian Paul <[email protected]>
|
| |
| |
| |
| | |
Fixes xvmc-softpipe MC entrypoint, amongst others.
|
| |
| |
| |
| | |
Fixes VDPAU CSC-only mode.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When parsing S-Expressions, we need to store nul-terminated strings for
Symbol nodes. Prior to this patch, we called ralloc_strndup each time
we constructed a new s_symbol. It turns out that this is obscenely
expensive.
Instead, copy the whole buffer before parsing and overwrite it to
contain \0 bytes at the appropriate locations. Since atoms are
separated by whitespace, (), or ;, we can safely overwrite the character
after a Symbol. While much of the buffer may be unused, copying the
whole buffer is simple and guaranteed to provide enough space.
Prior to this, running piglit-run.py -t glsl tests/quick.tests with GLSL
1.30 enabled took just over 10 minutes on my machine. Now it takes 5.
NOTE: This is a candidate for stable release branches (because it will
make running comparison tests so much less irritating.)
Signed-off-by: Kenneth Graunke <[email protected]>
|
| | |
|
| | |
|
|/
|
|
| |
NOTE: This is a candiate for 7.11
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 1a339b6c71ebab6e1a64f05b2e133022d3bbcd15 made
st_ChooseTextureFormat map GL_RGBA with type GL_UNSIGNED_BYTE
to PIPE_FORMAT_A8B8G8R8_UNORM.
The image format for ARGB pixmaps is PIPE_FORMAT_B8G8R8A8_UNORM
however. This mismatch caused the texture to be recreated in
st_finalize_texture.
NOTE: This is a candidate for the 7.11 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39209
Signed-off-by: Fredrik Höglund <[email protected]>
Reviewed-by: Stéphane Marchesin <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression introduced by commit
a26121f37530619610a78a5fbe5ef87e44047fda (fd.o bug #39219).
Since the __glXInitialize() call should be unnecessary anyway, this is
probably a nicer fix for the original problem too.
NOTE: This is a candidate for the 7.10 and 7.11 branches.
Signed-off-by: Henri Verbeet <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Tested-by: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, the stencil buffer was allocated as a Y tiled buffer, because
in several locations the PRM states that it is. However, it is actually
W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section
4.5.2.1 W-Major Format:
W-Major Tile Format is used for separate stencil.
The GTT is incapable of W fencing, so we allocate the stencil buffer with
I915_TILING_NONE and decode the tile's layout in software.
This fix touches the following portions of code:
- In intel_allocate_renderbuffer_storage(), allocate the stencil
buffer with I915_TILING_NONE.
- In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
not tiled.
- In the stencil buffer's span functions, the tile's layout must be
decoded in software.
This commit mutually depends on the xf86-video-intel commit
dri: Do not tile stencil buffer
Author: Chad Versace <[email protected]>
Date: Mon Jul 18 00:38:00 2011 -0700
On Gen6 with separate stencil enabled, fixes the following Piglit tests:
bugs/fdo23670-drawpix_stencil
general/stencil-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX16-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX1-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX4-readpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-copypixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-drawpixels
spec/EXT_framebuffer_object/fbo-stencil-GL_STENCIL_INDEX8-readpixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-copypixels
spec/EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels
spec/EXT_packed_depth_stencil/readpixels-24_8
Note: This is a candidate for the 7.11 branch.
Signed-off-by: Chad Versace <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
The previous define was the full 32-bit header, while the new define
was just the top 16 bits.
|
| |
|
|
|
|
|
|
|
|
|
| |
LLVM 3.0svn introduced a new type system. It defines a new way to create
named structs and removes the (now not needed) LLVMInvalidateStructLayout
function. See revision 134829 of LLVM.
Signed-off-by: Tobias Droste <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a rare case of building gallium only, we need to
check if the required packages are available
libdrm_[intel|nouveau] - gallium[i915 i965|nouveau]
v2: r300g and r600g do not need libdrm_radeon
Signed-off-by: Emil Velikov <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
this is added conditionally in Makefile.xmvc
Spotted by Chris Rankin.
|
|
|
|
|
|
|
|
|
|
| |
Including the full "3DSTATE_VF_STATISTICS" should make it easier to
cross-reference the code and documentation.
Also, move the 965/GM45 suffix to the beginning for consistency with
newer #defines.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
This makes our code use the same names as the documentation.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
The documentation uses 3DSTATE_DRAWING_RECTANGLE, and we already had it
defined in brw_defines.h; we were simply using an old #define from
intel_reg.h.
Signed-off-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
| |
Fixes piglit fragcoord_w test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34323
|
|
|
|
|
|
|
| |
This is useful for shadow map generation. Tested with glsl-bug-22603,
which rendered the depth textures with fallbacks before.
Acked-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
We were updating our new viewport using the old buffers' _WindowMap.m.
We can do less math and avoid using that deprecated matrix by just
folding the viewport calculation right in to the driver.
Fixes piglit fbo-depthtex.
|
|
|
|
|
|
| |
i915_update_draw_buffers() already handles the fallback bit for
missing stencil region, so here we just need to handle whether the GL
thinks we have stencil data or not (and disable the test if so).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were disabling it once at the moment we changed draw buffers, but
later enabling of depth test could turn it back on. Fixes
fbo-nodepth-test.
Note that ctx->DrawBuffer has to be checked because during context
create we get called while it's still unset. However, we know we'll
get an intel_draw_buffer() after that, so it's safe to make a silly
choice at this point.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30080
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
The 965 driver doesn't use these for deciding on fallbacks.
Reviewed-by: Chad Versace <[email protected]>
|