| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
In dd_function_table, close the Doxygen group beginning with
\name Support for multiple T&L engines
|
| |
|
| |
|
|
|
|
| |
Unimplemented and not so useful for this driver.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
i915 and i830 hardware doesn't have HiZ, so remove all HiZ related
assertions from *update_draw_buffer().
I've removed the dead format checks completely rather than replace them
with more appropriate checks. This doesn't reduce "assertion coverage",
however, because when I added these HiZ related assertions in c8fdf66
there were no pre-existing checks there.
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
We need to allocate all the output vectors.
Fixes a regression from commit f7f678331d5e95d2266fe6b3ea1cfa47d6421065
Fixes fd.o bugs 41441 and 41492.
|
|
|
|
|
|
|
| |
Silences a warning about comparing to an unsigned variable. It looks like
the result of swizzle_for_size() is always assigned to unsigned vars.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=32458
Reviewed-by: Chad Versace <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
We only use the float-valued function now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes failures found with the new piglit texsubimage test.
Two things were broken:
1. The dxt code doesn't handle sources images where width != row stride.
Check for that and take the _mesa_make_temp_ubyte_image() path to get
an image where width = rowstride.
2. If we don't take the _mesa_make_temp_ubyte_image() path we need to
take the source image unpacking parameters into account in order to
get the proper starting memory address of the source texels.
Note: This is a candidate for the 7.11 branch.
|
|
|
|
| |
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
... with the right value.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
|
|
| |
Do it in two passes in that case.
v2: Don't forget to handle stencil clears.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
Docs say this is obeyed.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
4bit palette ftw!
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Docs say that default shader input color input need to be spec
as ARGB8888. And a clear rect prim essentially uses this value
instead of default diffuse. Depth on the other hands is an ieee
32 bit float. Clear stencil is U8.
Completely different are the clear values for zone init prims.
These are speced in the actual output pixel layout (and need
to be repeated for 16 bit formats).
Clear up the confusion by adding some comments.
v2: Retain the target swizzling support added by Stephan Marchesin.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
|
|
| |
This way it can be reused in the fastclear path.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
We leave the debug code in place to troubleshoot issues while we complete the transition. That code might be removed after that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if the user enabled a non-consecutive set of clip planes
(e.g. 0, 1, and 3), the driver would compact them down to a
consecutive set starting at 0. This optimization was of dubious
value, and complicated the implementation of gl_ClipDistance.
This patch changes the driver so that with Gen6 and later chipsets, we
no longer compact the clip planes. However, we still discard any clip
planes beyond the highest number that is in use, so performance should
not be affected for applications that use clip planes consecutively
from 0.
With chipsets previous to Gen6, we still compact the clip planes,
since the pre-Gen6 clipper thread relies on this behavior.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The only remaining uses of brw_vs_prog_key::nr_userclip only occurred
when using clip planes (as opposed to gl_ClipDistance). This patch
renames the value to nr_userclip_planes and sets it to zero when
gl_ClipDistance is in use. This avoids unnecessary VS recompiles.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, brw_compute_vue_map required an argument indicating the
number of clip planes in use, but all it did with it was check if it
was nonzero.
This patch changes brw_compute_vue_map to take a boolean instead.
This allows us to avoid some unnecessary recompilation of the Gen4/5
GS and SF threads.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous to this patch, setup_uniform_clipplane_values() was setting
up clip plane uniforms based on ctx->Transform.ClipPlanesEnabled, a
piece of state not stored in the vertex shader cache key. As a
result, a change to this piece of state might not trigger a necessary
vertex shader recompile.
The patch adds a field to the vertex shader cache key,
userclip_planes_enabled, to store the current value of
ctx->Transform.ClipPlanesEnabled. Also, it changes
setup_uniform_clipplane_values() to read from this new field, so that
it's manifestly clear that the vertex shader isn't depending on state
not stored in the cache key.
Note: when the vertex shader uses gl_ClipDistance, the VS backend
doesn't need to know which clip planes are in use, so we leave the
field as zero in that case to avoid unnecessary recompiles.
Fixes Piglit test vs-clip-vertex-enables.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
No functional change. This patch rearranges the struct
brw_vs_prog_key so that the two fields related to clipping are
together, and documents those fields. This should make the patches
that follow easier to comprehend, since they add additional
clipping-related fields to this structure.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The i965 driver already had a function to count bits in a 64-bit uint
(brw_count_bits()), but it was buggy (it only counted the bottom 32
bits) and it was clumsy (it had a strange and broken fallback for
non-GCC-like compilers, which fortunately was never used). Since Mesa
already has a _mesa_bitcount() function, it seems better to just
create a _mesa_bitcount_64() function rather than special-case this in
the i965 driver.
This patch creates the new _mesa_bitcount_64() function and rewrites
all of the old brw_count_bits() calls to refer to it.
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Fixes the ES1 conformance 'userclip' test, which broke when we increased
MAX_CLIP_PLANES to 8. Core Mesa already validates incoming values
against MAX_CLIP_PLANES; we just need the ES wrapper to pass everything
through.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
It's required for ES 1.0 and 1.1, and isn't specified for ES 2.
While the comment says Mesa depends on it internally, removing it from
ES2 doesn't seem to regress any Piglit or ES2 conformance tests.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
In particular, drivers don't enable this in ES 1.1 contexts.
Prior to this, none of the OpenGL ES 1.1 conformance tests passed.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
We still need to investigate LIS7 though.
|
| |
|
| |
|
| |
|
|
|
|
| |
It was only used by the old tdfx driver, IIRC.
|
|
|
|
| |
Was only used by some older/removed DRI drivers.
|
|
|
|
| |
It's always the same as the texture width.
|
|
|
|
|
| |
Instead, use the new st_texture_image::TexData field to hold texture
images that don't fit the parent object's mipmap buffer.
|
|
|
|
|
|
|
| |
Since core Mesa no longer depends on gl_texture_image::Data pointing to
mapped texture buffers we don't have to mess with it all over the place
in the state tracker. Now Data is only used to point to malloc'd memory
that holds images which don't fit in the texture object's mipmap buffer.
|
|
|
|
|
|
|
|
|
|
|
| |
These were used to find the start of a 3D image slice (or 2D array texture
slice) given a base address. Instead, use a simple array of address of
image slices instead.
This is a step toward getting rid of the gl_texture_image::ImageOffsets
field.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
If you want to access it, you should use the Drawable in xlib_drawable instead.
|
|
|
|
|
|
| |
Fixes double-underscore-*.frag.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
This only adds dummy entries to the table to fix failed assertions.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41491
|