Add information for RGB565 to the table of image formats so that we can
create a __DRIimage for that format. This in turn enables RGB565
wayland clients.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
With this patch Wayland clients can now ask EGL for RGB 565 format buffers
and attach them to a Wayland compositor.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
* The rtti fix actually dug up a bug in the scons build scripts.
* Autotools took the LLVM cpp and cxx flags, while scons only took
the cpp flags.
* This grabs the cxx flags and applies them where needed. We may
want to make the same change for the llvm cpp flags in scons.
* The only linux platform I can find with LLVM no-rtti is Ubuntu.
* Fixes bug #70471
Tested-by: Vinson Lee <vlee@freedesktop.org>
The original intent of the variable was to prevent adding
libdrm dependency for non drm drivers (swrast). This is
already handled with __NOT_HAVE_DRM_H, and with the recent
merge of the dri_util and drisw_util code this variable has
started causing build issues.
Eg. the following will fail
$ ./autogen.sh --with-dri-drivers=swrast --with-gallium-drivers=
$ make
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Andreas Boll <andreas.boll.dev@gmail.com>
When a geometry shader is active, the transform feedback primitive
type ("mode") needs to be validated against the geometry shader output
primitive type, not the primitive type passed to the glDraw*()
function.
Fixes the following piglit tests:
- glsl-1.50-geometry-primitive-types GL_LINES
- glsl-1.50-geometry-primitive-types GL_LINES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLES
- glsl-1.50-geometry-primitive-types GL_TRIANGLES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLE_FAN
Exposes previously hidden failures in the following piglit tests:
- glsl-1.50-geometry-primitive-id-restart GL_LINES other
- glsl-1.50-geometry-primitive-id-restart GL_LINES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP ffs
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN ffs
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY other
(These failures were previously hidden due to a flaw in the test: it
doesn't check for GL errors. I'll fix the test shortly).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Ivy Bridge's "reorder enable" bit gives us a binary choice for the
order in which vertices from triangle strips are delivered to the
geometry shader. Neither choice follows the OpenGL spec, but setting
the bit is better, because it gets triangle orientation correct.
Haswell replaces the "reorder enable" bit with a new "reorder mode"
bit (which occupies the same location in the command packet). This
bit gives us a different binary choice, which affects both triangle
strips and triangle strips with adjacency. Setting the bit ("reorder
trailing") gives the proper order according to the OpenGL spec.
So in either case we want to set the bit.
On Ivy Bridge, fixes piglit test "triangle-strip-orientation".
On Haswell, fixes piglit tests "glsl-1.50-geometry-primitive-types
{GL_TRIANGLE_STRIP,GL_TRIANGLE_STRIP_ADJACENCY}" and
"glsl-1.50-geometry-tri-strip-ordering-with-prim-restart *".
v2: Rename the bit to "REORDER_TRAILING" for consistency with Haswell
docs.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Despite the name, this field wasn't being set to the dispatch width at
all; it was always 8. The only place it was used was that the
constant buffer read length was aligned to it, and as far as I can
tell from the docs, there is no need to align this value to the
dispatch width; aligning it to a multiple of 8 is sufficient. So I've
just replaced it with a hardcoded 8.
v2: In gen6_wm_state, use brw->wm.base.push_const_size for consistency
with VS and GS state upload.
Reviewed-by: Eric Anholt <eric@anholt.net>
This patch populates the following built-in GLSL 1.50 variables based
on constants stored in ctx->Const:
- gl_MaxVertexOutputComponents
- gl_MaxGeometryInputComponents
- gl_MaxGeometryOutputComponents
- gl_MaxFragmentInputComponents
- gl_MaxGeometryTextureImageUnits
- gl_MaxGeometryOutputVertices
- gl_MaxGeometryTotalOutputComponents
- gl_MaxGeometryUniformComponents
- gl_MaxGeometryVaryingComponents
On i965/gen7, fixes all Piglit tests in "spec/glsl-1.50/built-in
constants/*" except for gl_MaxCombinedTextureImageUnits and
gl_MaxGeometryUniformComponents.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Now that both vec4 and fs are dynamically assigning offsets, a lot of the
code is the same.
v2: Avoid passing around the next offset through the class. (Review by
Paul)
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Note that the dropped comment in brw_context.h is mostly (better written)
in brw_binding_table.c as well.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
It would be nice to be able to pack our binding table so that programs
that use 1 render target don't upload an extra BRW_MAX_DRAW_BUFFERS - 1
binding table entries. To do that, we need the compiled program to have
information on where its surfaces go.
v2: Rename size to size_bytes to be more explicit.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
* As discussed on the mailing list,
forced no-rtti breaks C++ public
API's such as the Haiku C++ libGL.so
* -fno-rtti *can* be still set however
instead of blindly forcing -fno-rtti,
we can rely on the llvm-config
--cppflags output.
If the system llvm is built without
rtti (default), the no-rtti flag will be
present in llvm-config --cppflags
(which we pick up on)
If llvm is built with rtti
(REQUIRES_RTTI=1), then -fno-rtti is
removed from llvm-config --cppflags.
* We could selectively add / remove rtti
from various components, however mixing
rtti and non-rtti code is tricky and
could introduce missing symbols.
* This needs impact tested.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Add simple plain C routines for NV12<->YV12 and YUYV<->UYVY
conversions. The NV12->YV12 conversion is commonly used, for instance
by VLC.
Reviewed-by: Christian König <christian.koenig@amd.com>
Textures that likely reside in VRAM, are mapped for reading and
don't require direct mapping should be staged into GTT, to avoid bad
performance. This fixes readback performance of VDPAU surfaces.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This new bind flag forces linear storage, but does not have other
side effects like R600_RESOURCE_FLAG_TRANSFER.
Reviewed-by: Christian König <christian.koenig@amd.com>
Currently it's hardcoded in the shader, so every change requires
compilation of the shader variant, killing the performance
in Serious Sam 3 and probably other apps.
This patch passes alpha_ref in the user sgpr and removes it from
the shader key.
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This fixes the issue when dst and src is the same reg and operation on one
channel overwrites the source for other channels, e.g.:
UMUL TEMP[2].xyz, TEMP[0].xyzz, TEMP[2].xxxx
In this example the result of the operation on channel x is written in
TEMP[2].x and then used as a second source operand for channels y and z
instead of original value in TEMP[2].x.
This patch stores the results in temp reg and moves them to
dst after performing operation on all channels.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=70327
Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
v2: Keep the random 32-bit only version of memcpy, since Ian says I
can't delete it without data proving it isn't useful.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
brw_context.h includes imports.h which includes compiler.h which already
defines these.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
These make it easy to convert a floating point value to a fixed point
numbers. The second parameter is the number of bits used for the
fractional part of the number.
It looks like core Mesa has similar functions already, but none that
allows an arbitrary number of fractional bits. The more generic version
is probably useful to everyone.
r600g apparently has an identical copy of the S_FIXED macro, but doesn't
include this file. I'm not sure what to do about that, so I'm just
going to leave it for now.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This seems generally useful, so it may as well live in core Mesa.
In fact, the comment for ALIGN() in macros.h actually says to "see also"
ROUND_DOWN_TO, which...was in a driver somewhere.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
intel_batchbuffer_init() sets up initial batchbuffer state; it seems
like a reasonable place to initialize this flag.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Configuring which dirty flags we want sounds like a job for
brw_init_state().
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It actually just wants generation checking, and brw->gen is the usual
way of doing that. In the future, we'll also want to check brw->hw_ctx,
which isn't available from the screen.
While we're changing the function signature, convert from camel case to
our usual naming conventions.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
There's no point in having two files for context functions. This patch
moves the code from intel_context.c into brw_context.c unmodified
(other than whitespace fixes).
Right now, this looks silly; future patches will merge functions and
tidy things up.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
brw_init_surface_formats already sets entries in TextureFormatsSupported
to true; it may as well take care of initializing it to false too.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This flag is only used in one place, and is only set on one platform.
Just check for original Gen4 in the relevant function.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This seems like a better place for it, and helps clean up
brwCreateContext (which is full of a lot of random stuff).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This was always set to false, and is only used for debugging.
To enable it, simply change the if (0) block and recompile.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Since each kind of device has its own brw_device_info structure, we can
simply store the URB and thread limits there. This eliminates all the
large if-ladders, and simplifies the context initialization code quite a
bit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
This option was useful during initial development, but it's been ages
since I've heard of anyone using it. Plus, Gen7+ mandates separate
stencil, so it was really only useful on Sandybridge anyway.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The idea is that struct brw_device_info should store statically-known
information about hardware features. Using the new family name in the
PCI ID table, we can easily grab the right structure.
This is basically the equivalent of intel_device_info in the kernel.
This patch also makes the new structure available from intel_screen, but
nothing uses it. Right now, it looks very redundant with existing
fields, but that will change.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
