The driver never work with real hardware and has
bitrotted for quite some time now, might as well
drop it. If somebody wants to look at it just use git.
So I didn't touch r300compiler, but r300g now compiles after having
declarations and code untangled. As nha so gently points out, we shouldn't
have to do this just to comply with MSVC compilers.
The previous behaviour was incorrect, and resulted in EXT_tfp being broken
for DDX drivers that implement the correct behaviour (intel/radeon/nouveau).
In the cases where a fake front buffer is required, the X server will
return one when requesting __DRI_BUFFER_FRONT_LEFT.
The Xorg state tracker (aka modesetting_drv) is likely broken now until
it's modified to match the other drivers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This ensures that an assertion like
assert(expensive_test());
won't have any penalty on release builds. It also implies that no vital
code should be in assert expressions.
This is just a temporary change until we code generate the tile read/write
functions in runtime. The new code avoids an extra memcpy that exists in
u_tile.c functions, from which lp_tile_soa.c was originally based.
This achieves up to 5% improvement, particularly in frames with
little geometry overlap.
Same as in src/gallium/winsys/drm/intel/xorg/Makefile
Thanks MrCooper for explanations on IRC
[ Summary amended by Michel Dänzer to clarify that this is related to the xorg
state tracker ]
Besides from being necessary to use that extension, it also fixes a crash
when deleting the currently bound vertex array object.
Signed-off-by: Nicolai Hähnle <nhaehnle@gmail.com>
Always test for PIPE_TRANSFER_READ/WRITE using the bit-wise and operator, and
add a pipe_transfer_buffer_flags() helper for getting the buffer usage flags
corresponding to them.
Interface is pipe_video_context::set_csc_matrix().
vl_csc.h defines some helpers to generate CSC matrices based on one of
the color standard and a user defined ProcAmp (brightness, contrast,
saturation, hue).
Since the various BSDs use some different features here,
define PIPE_OS_OPENBSD and PIPE_OS_NETBSD as well
Signed-off-by: Robert Noland <rnoland@2hip.net>
This was redundant as drivers can just keep track of whether they are
inside a begin/end query pair. We want to add more query types later
and also support nested queries, none of which map well onto a flag like
this. No driver appeared to be using the flag.
This fixes a NULL-pointer dereference when
eglMakeCurrent(dpy, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT)
is called.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
The combination of fptosi
and sitofp (necessary for trunc/floor/ceil/round implementation)
somehow becomes invalid code.
Skip the instruction combining pass when SSE4.1 is not available.
Nasty bug when the surface is freed and another is allocated right on
top of it. The next time we set the fb state SP thinks it's the same
surface and doesn't flush, and when the flush eventually happens the
surface belongs to a completely different texture.
(cherry picked from commit a77226071f)
Conflicts:
src/gallium/drivers/softpipe/sp_context.c
Note that llvmpipe still doesn't run on any processor yet: if you don't
have a recent processor with SSE4.1 you will still likely end up
hitting a code path for which a generic non-sse4 version is not
implemented yet.
I was waiting for the need to use this code to arise, and it finally came.
I've tested building this on Linux and Windows, both x86 and x64_64. But
it might break other platforms. Please bear with me and help me fix it.
Many thanks to Dennis Smit who submitted this, and Eric Anholt whose
work this was based on.
why there are two input position semantic tags is that ureg doesn't
set vs input semantic due to commit: 6d8dbd3d1e
so use vs input index instead of semantic name.
Not sure why we are getting a shader with two inputs with position semantic, but we don't know how to handle it correctly so it's better to stop the app than lock the machine.
Not 100% sure this is correct, but its more correct than what was here previous
however it may require changes in the input routing for the frag shader.
It is no longer needed since the new drm api code,
and it incorrectly checked if the buffer where there
for testing completeness when it should have checked
the texture instead.
Nasty bug when the surface is freed and another is allocated right on
top of it. The next time we set the fb state SP thinks it's the same
surface and doesn't flush, and when the flush eventually happens the
surface belongs to a completely different texture.