| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
| |
It was only used by the old tdfx driver, IIRC.
|
|
|
|
| |
Was only used by some older/removed DRI drivers.
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements proper support for gl_ClipVertex by causing the
new VS backend to populate the clip distance VUE slots using
VERT_RESULT_CLIP_VERTEX when appropriate, and by using the
untransformed clip planes in ctx->Transform.EyeUserPlane rather than
the transformed clip planes in ctx->Transform._ClipUserPlane when a
GLSL-based vertex shader is in use.
When not using a GLSL-based vertex shader, we use
ctx->Transform._ClipUserPlane (which is what we used prior to this
patch). This ensures that clipping is still performed correctly for
fixed function and ARB vertex programs. A new function,
brw_select_clip_planes() is used to determine whether to use
_ClipUserPlane or EyeUserPlane, so that the logic for making this
decision is shared between the new and old vertex shaders.
Fixes the following Piglit tests on i965 Gen6:
- vs-clip-vertex-const-accept
- vs-clip-vertex-const-reject
- vs-clip-vertex-different-from-position
- vs-clip-vertex-equal-to-position
- vs-clip-vertex-homogeneity
- vs-clip-based-on-position
- vs-clip-based-on-position-homogeneity
- clip-plane-transformation clipvert_pos
- clip-plane-transformation pos_clipvert
- clip-plane-transformation pos
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, clip planes didn't work properly in Mesa when using
vertex shaders, because Mesa assigned both gl_ClipVertex and
gl_Position to the same gl_vert_result (VERT_RESULT_HPOS). As a
result, backends couldn't distinguish between the two variables, so
any shader that wrote different values to them would fail to work
properly.
This patch paves the way for proper support of gl_ClipVertex by
creating a new enumerated value in gl_vert_result for it
(VERT_RESULT_CLIP_VERTEX). After this patch, a back-end may add
support for gl_ClipVertex using the following algorithm:
- If using a user-supplied GLSL vertex shader:
- If the bit corresponding to VERT_RESULT_CLIP_VERTEX is set in
gl_program::OutputsWritten:
- Clip using the vertex shader output VERT_RESULT_CLIP_VERTEX and
the clip planes defined in gl_context::Transform.EyeUserPlane.
- Else:
- Clip using the vertex shader output VERT_RESULT_HPOS and the
clip planes defined in gl_context::Transform.EyeUserPlane.
- Else (either using fixed function or an ARB vertex program):
- Clip using the vertex shader output VERT_RESULT_HPOS and the clip
planes defined in gl_context::Transform._ClipUserPlane (*)
where (*) represents the normal Mesa behavior before this patch.
An example of implementing the above algorithm can be found in the
patch that follows this one, which implements gl_ClipVertex in i965
Gen6.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
This updates the fbo format table for the integer types.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This just adds the entries to the table and fixes the asserts up.
The int32 one is definitely wrong, since it uses a float temp
which will lose precision, but its no worse than now.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
This adds the integer types to the tex format chooser.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is taken from reading EXT_texture_integer + EXT_texture_rg in combination,
Comments on necessity of each format, naming of formats and bugs in the
formats tables please.
Is there any formats I've missed?
Eric looked over this to make sure its consistent at least.
As I've changed the ordering of things in the format table, the follow
patches are required to avoid regression.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
As per Brian's suggestion we can generate this table at first start
to make sure its correct. This is a sad workaround for compilers which
don't support named initialiser. (its 2011).
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Instead of relying on the mirror in the Mesa IR assembly shader, just
use the variables actually stored in the GLSL IR. This will be a bit
slower, but nobody cares about the performance of glGetActiveAttrib.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This just folds get_active_attrib into _mesa_GetActiveAttribARB
and moves the resulting function function to the other source file.
More changes are coming soon.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This currently mirrors the state tracking
gl_shader_program::Attributes, but I'm working towards eliminating
that.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This just folds bind_attrib_location into _mesa_BindAttribLocationARB
and moves the resulting function function to the other source file.
More changes are coming soon.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This allows querying the linked shader itself rather than the Mesa IR.
This is the first step towards removing gl_program::Attributes.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers in Mesa have supported this extension for eons. This
extension is an optional features in desktop OpenGL (via
GL_ARB_draw_buffers) and OpenGL ES 2.x (via GL_NV_draw_buffers).
The extension is not usable in OpenGL ES 1.x. There is no
glDrawBuffers* entry point in OpenGL ES 1.x contexts, and glGet*v
generate errors when MAX_DRAW_BUFFERS or DRAW_BUFFERi is queried.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
This also fixes what was probably a bug in 1D arrays with border.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we can zero-copy generate the mipmaps into brand new
glTexImage()-generated storage using MapTextureImage(), we no longer
need to allocate image->Data in mipmap generate. This requires
deleting the drivers' old overrides of the miptree tracking after
calling _mesa_generate_mipmap at the same time, or the drivers
promptly lose our newly-generated data.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the EXT_transform_feedback spec:
Primitives can be optionally discarded before rasterization by calling
Enable and Disable with RASTERIZER_DISCARD_EXT. When enabled, primitives
are discared right before the rasterization stage, but after the optional
transform feedback stage. When disabled, primitives are passed through to
the rasterization stage to be processed normally. RASTERIZER_DISCARD_EXT
applies to the DrawPixels, CopyPixels, Bitmap, Clear and Accum commands as
well.
And the GL 3.2 spec says it applies to ClearBuffer* as well.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
Fixes piglit ARB_color_buffer_float/api-get
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
If GL_NV_texture_env_combine4 is not supported, setting the fourth
combiner term would generate a GL error.
Of course, I noticed this right after committing the previous patch
to use a loop in the first place. <sigh>
Note that GL_EXT_texture_env_combine is always supported so the first
three combiner terms are always accepted.
|
|
|
|
|
|
|
| |
INLINE is still seen in some files (some generated files, etc) but this
is a good start.
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
There's four combiner terms (not 3) with GL_NV_texture_env_combine4.
Use a loop to make the code a little more compact.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Lots of things set and copy this field around, but nothing uses it.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Remove NeedValidate and ValidateTnlModule.
Reviewed-by: Eric Anholt <[email protected]>
Signed-off-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
| |
The GL spec says that luminance values are returned as (l, 0, 0, 1),
L/A values as (l, 0, 0, a) and intensity values as (i, 0, 0, 1).
Use the pixel transfer scale controls to implement that.
This fixes a few failures in the new piglit getteximage-formats
test when getting a compressed L or L/A image.
|
|
|
|
|
|
|
| |
The target, level and texObj can be obtained through the texImage
parameter. We could make similar changes for the TexImage() hooks too.
Reviewed-by: Eric Anholt <[email protected]>
|