The DO instruction doesn't exist on Gen6+. Since before this commit, DO
always ended a basic block, if it also happened to start one (e.g., a
while loop inside an if statement) the block containing only the DO
would actually contain no hardware instructions.
Pre-Gen6's WHILE instructions jumps to the instruction following the DO,
so strictly speaking we won't be modeling that properly, but I claim
there is actually no functional difference.
This will simplify an upcoming change where we want to mark the first
hardware instruction in the loop as beginning a block, and the last
instruction before the loop as ending one.
Reviewed-by: Eric Anholt <eric@anholt.net>
Note that predicated instructions with defs are still not supported
because transformation to SSA doesn't handle them yet.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
[imirkin: add logic to also clear the "regular" scissors]
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
The glGetGraphicsResetStatusARB from ARB_robustness extension always
returns GUILTY_CONTEXT_RESET_ARB and never returns NO_ERROR for guilty
context with LOSE_CONTEXT_ON_RESET_ARB strategy. This is because Mesa
returns GUILTY_CONTEXT_RESET_ARB if batch_active !=0 whereas kernel
driver never reset batch_active and this variable always > 0 for guilty
context. The same behaviour also can be observed for batch_pending and
INNOCENT_CONTEXT_RESET_ARB.
But ARB_robustness spec says:
If a reset status other than NO_ERROR is returned and subsequent calls
return NO_ERROR, the context reset was encountered and completed. If a
reset status is repeatedly returned, the context may be in the process
of resetting.
8. How should the application react to a reset context event?
RESOLVED: For this extension, the application is expected to query the
reset status until NO_ERROR is returned. If a reset is encountered, at
least one *RESET* status will be returned. Once NO_ERROR is
encountered, the application can safely destroy the old context and
create a new one.
The main problem is the context may be in the process of resetting and
in this case a reset status should be repeatedly returned. But looks
like the kernel driver returns nonzero active/pending only if the
context reset has already been encountered and completed. For this
reason the *RESET* status cannot be repeatedly returned and should be
returned only once.
The reset_count and brw->reset_count variables can be used to control
that glGetGraphicsResetStatusARB returns *RESET* status only once for
each context. Note the i915 triggers reset_count twice which allows to
return correct reset count immediately after active/pending have been
incremented.
v2 (idr): Trivial reformatting of comments.
Signed-off-by: Pavel Popov <pavel.e.popov@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Define GLX_USE_APPLEGL, as config/darwin used to, to turn on specific code to
use the applegl direct renderer
Convert src/glx/apple/Makefile to automake
Since the applegl libGL is now built by linking libappleglx into libGL, rather
than by linking selected files into a special libGL:
- Remove duplicate code in apple/glxreply.c and apple/apple_glx.c. This makes
apple/glxreply.c empty, so remove it
- Some indirect rendering code is already guarded by !GLX_USE_APPLEGL, but we
need to add those guards to indirect_glx.c, indirect_init.c (via it's
generator), render2.c and vertarr.c so they don't generate anything
Fix and update various includes
glapi_gentable.c (which is only used on darwin), should be included in shared
glapi as well, to provide _glapi_create_table_from_handle()
Note that neither swrast nor indirect is supported in the APPLEGL path at the
moment, which makes things more complex than they need to be. More untangling
is needed to allow that
v2: Correct apple/Makefile.am for srcdir != builddir
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
- Don't require xcb-dri[23] etc. if we aren't building for a target with DRM, as
we won't be using dri[23]
- Enable a more fine-grained control of what DRI code is built, so that a libGL
using direct swrast can be built on targets which don't have DRM.
The HAVE_DRI automake conditional is retired in favour of a number of other
conditionals:
HAVE_DRI2 enables building of code using the DRI2 interface (and possibly DRI3
with HAVE_DRI3)
HAVE_DRISW enables building of DRI swrast
HAVE_DRICOMMON enables building of target-independent DRI code, and also enables
some makefile cases where a more detailled decision is made at a lower level.
HAVE_APPLEDRI enables building of an Apple-specific direct rendering interface,
still which requires additional fixing up to build properly.
v2:
Place xfont.c and drisw_glx.c into correct categories.
Update 'make check' as well
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Fix build for darwin, when ./configured --disable-driglx-direct
- darwin ld doesn't support -Bsymbolic or --version-script, so check if ld
supports those options before using them
- define GLX_ALIAS_UNSUPPORTED as config/darwin used to, as aliasing of non-weak
symbols isn't supported
- default to -with-dri-drivers=swrast
v2:
Use -Wl,-Bsymbolic, as before, not -Bsymbolic
Test that ld --version-script works, rather than just looking for it in ld --help
Don't use -Wl,--no-undefined on darwin, either
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
glFramebufferRender(..., GL_DEPTH_STENCIL_ATTACHMENT, ..., 0) only
detached the depth buffer and not the stencil buffer.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=79115
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
It works fine, though it requires using ELF objects.
With this change there is nothing preventing us to switch exclusively
to MCJIT, everywhere. It's still off though.
If the source renderbuffer has a depth > 0, then send a Z texcoord
which is set to the source attachment Z offset.
This fixes piglit's gl-3.2-layered-rendering-gl-layer-render with the
GL_TEXTURE_2D_MULTISAMPLE_ARRAY case test on i965/gen8.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
brw_color_buffer_write_enabled depends on brw->fragment_program, which
means we have to listen to BRW_NEW_FRAGMENT_PROGRAM.
On most generations, this was only called from a function that already
subscribed. However, on Broadwell, we failed to listen to the necessary
event in the atom that emits 3DSTATE_PS_BLEND.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
I forgot to disable writemasking on the OR and MOV which set the render
target index and "source 0 alpha present to render target" bit.
Using get_element_ud is equivalent and avoids a line-wrap.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Commit a2fb71e23 introduced 32-bit code for SSE4.1. Fix compilation, and
make sure to check ecx for the SSE4.1 bit.
[imirkin: switch sse4.1 to look at ecx]
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This fixes MinGW x64 builds. We don't use assembly on any of the
Windows builds, to avoid divergence between MSVC and MinGW when testing.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This patch fixes this build error on Mac OS X.
CCLD libglapi.la
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
ld: unknown option: --no-undefined
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
-fstack-protector-strong is not supported by clang.
This patch fixes this build error on Fedora 20 with clang.
CXX gallivm/lp_bld_debug.lo
clang: error: unknown argument: '-fstack-protector-strong'
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75010
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Seems the opcodes are slightly different from a2xx. Resync headers and
move blend_func() helper into hw generation specific code.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
For most drivers this if statement is always going to fail so check the constant value first.
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Brian Paul <brianp@vmware.com>
We already multiply by bytes per pixel for this, so f3ba7611 broke
mem2gmem for depth/stencil. Drop the now-redundant mutiply by cpp.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Note that this covers the Begin/End rendering path, but not user vertex
arrays (so we can't drop copy_array_to_vbo_array() code). Improves
performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934%
(n=20). No difference on openarena (n=10), which was why this was reverted
back in cbde276580.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
