| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit d1fda903 (radeon: Drop mapping we were doing around
glGetTexImage()) removed the common Radeon source file
radeon_tex_getimage.c, and pulled it out of the r200, r300, r600, and
radeon makefiles. But it left behind the symlinks that were being
used to share that file among the four directories.
This patch removes the dangling symlinks.
Reviewed-by: Brian Paul <[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]>
|
|
|
|
|
|
|
| |
Us poor souls who cross compile mesa want to be able to specify which pkg-config to pick, or at least just change one place.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Guillem Jover <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
So easy to screw up with the crazy way GL manages them.
|
| |
|
|
|
|
|
| |
With 1D array textures, we no longer agree between the GL information
about width/height/depth of a texture and how we lay out a miptree.
|
|
|
|
| |
This is just moving the code out with s/6/slices/.
|
|
|
|
|
|
|
|
| |
The path for ->Data was failing to be called for the FBO draw offset
fallback, and also had mismatched compressed texture support code.
This drops the intel_prepare_render() in the blit path. We aren't
copying to/from a GL_FRONT buffer, so it doesn't matter.
|
|
|
|
|
|
| |
Too many separate functions each called from one location (in
different files). This code should all die soon when swrast starts
using MapTextureImage.
|
|
|
|
|
| |
Now that whole block that also lives in AllocTextureImageBuffer can go
away.
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Before, we were only allocating these from our TexImage, so if the
texture image was set up in any other way (non-accelerated
glGenerateMipmaps()), they'd be missing or wrong.
|
|
|
|
|
| |
Now we can rely on Mesa core for uploads of data without introducing
an extra copy at validate time.
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Apparently on Gen4 and 5, the denominator comes first.
Signed-off-by: Kenneth Graunke <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
| |
It never mattered before since we only did floating point math.
Signed-off-by: Kenneth Graunke <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both POW and INT DIV need a message length of 2; previously, we only
checked for POW.
Also, BRW_MATH_FUNCTION_INT_DIV_QUOTIENT_AND_REMAINDER has a response
length of 2; previously, we only checked for SINCOS. We don't use this
message, but in case we ever decide to, we may as well fix it now.
While we're at it, just move these computations into
brw_set_math_message, since they're entirely based on the function.
This fixes it for both brw_math and the old backend's brw_math_16.
Signed-off-by: Kenneth Graunke <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
BRW_MATH_FUNCTION_REMAINDER was missing. Also, it seems worthwhile to
assert that INT DIV's arguments are signed/unsigned integers.
Signed-off-by: Kenneth Graunke <[email protected]>
Tested-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
Commit d631c19db47181129811080bfa772b210d762d4d avoided this problem
by forcing the driver to get the min/max index, but that commit was
broken, so just fix the driver problem (confusion between "do I need
to upload any data?" and "do I need the index bounds in order to
upload any data?").
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As innocuous as it seemed, ebca47a basically broke the world (e.g.,
>200 piglit regressions). In vec4_visitor::emit_block_move,
src->swizzle was expected to be BRW_SWIZZLE_NOOP before setting it to
a swizzle that would replicate the existing channels of the source
type to a vec4 (e.g., .xyyy for a vec2).
The original assertion seems to have been a little bogus. In addition
to being BRW_SWIZZLE_NOOP, src->swizzle might already be a swizzle
that would replicate the existing channels of the source type to a
vec4. In other words, it might already have the value that we're
about to assign to it.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From a Coverity defect report.
src/mesa/drivers/dri/i915/i915_fragprog.c
301 /*
302 * TODO: consider moving this into core
303 */
304 static bool calc_live_regs( struct i915_fragment_program *p )
305 {
306 const struct gl_fragment_program *program = &p->FragProg;
307 GLuint regsUsed = 0xffff0000;
-> 308 uint8_t live_components[16] = { 0, };
309 GLint i;
310
311 for (i = program->Base.NumInstructions - 1; i >= 0; i--) {
312 struct prog_instruction *inst =
&program->Base.Instructions[i];
313 int opArgs = _mesa_num_inst_src_regs(inst->Opcode);
314 int a;
315
316 /* Register is written to: unmark as live for this and
preceeding ops */
317 if (inst->DstReg.File == PROGRAM_TEMPORARY) {
-> 318 if (inst->DstReg.Index > 16)
319 return false;
320
-> 321 live_components[inst->DstReg.Index] &= ~inst->DstReg.WriteMask;
322 if (live_components[inst->DstReg.Index] == 0)
323 regsUsed &= ~(1 << inst->DstReg.Index);
324 }
325
326 for (a = 0; a < opArgs; a++) {
327 /* Register is read from: mark as live for this and preceeding ops */
328 if (inst->SrcReg[a].File == PROGRAM_TEMPORARY) {
329 unsigned c;
330
331 if (inst->SrcReg[a].Index > 16)
332 return false;
333
334 regsUsed |= 1 << inst->SrcReg[a].Index;
335
336 for (c = 0; c < 4; c++) {
337 const unsigned field = GET_SWZ(inst->SrcReg[a].Swizzle, c);
338
339 if (field <= SWIZZLE_W)
340 live_components[inst->SrcReg[a].Index] |= (1U << field);
341 }
342 }
343 }
344
345 p->usedRegs[i] = regsUsed;
346 }
Reported-by: Vinson Lee <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40022
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is from a Coverity defect report.
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
1314 void
1315 vec4_visitor::emit_block_move(dst_reg *dst, src_reg *src,
1316 const struct glsl_type *type, bool
predicated)
...
1351 /* Do we need to worry about swizzling a swizzle? */
->1352 assert(src->swizzle = BRW_SWIZZLE_NOOP);
1353 src->swizzle = swizzle_for_size(type->vector_elements);
Reported-by: Vinson Lee <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40158
Signed-off-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is from a Coverity defect report.
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
268 static void
269 check_gen6_math_src_arg(struct brw_reg src)
270 {
271 /* Source swizzles are ignored. */
272 assert(!src.abs);
273 assert(!src.negate);
-> 274 assert(src.dw1.bits.swizzle = BRW_SWIZZLE_XYZW);
275 }
Reported-by: Vinson Lee <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40214
Signed-off-by: Chris Wilson <[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]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on mach64, mga, and savage
(Savage3D and other pre-Savage4).
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on i810, mach64, mga,
savage, sis, and tdfx (Voodoo Banshee and Voodoo3).
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on mach64.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on mach64, mga, or r128.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x. The existing support is already partially
broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x).
This patch does not change the situation in any way.
It looks like the only hardware supported by Mesa that cannot do
ARB_texture_env_combine is pre-NV10 NVIDA chips. It appears that
these chips cannot do the GL_SUBTRACT mode. Based on looking at older
copies of nvOpenGLspecs.pdf found on the net, NVIDIA never supported
ARB_texture_env_combine on those chips either.
This extension was previously not supported on mach64, mga (G200),
r128, savage, sis, and tdfx (Voodoo Banshee and Voodoo3).
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x. The existing support is already partially
broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x).
This patch does not change the situation in any way.
This extension was previously not supported on mach64, mga (G200),
savage (Savage3D and other pre-Savage4), sis, and tdfx (Voodoo
Banshee).
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x. The existing support is already partially
broken in Mesa (e.g., querying GL_CLIENT_ACTIVE_TEXTURE in OpenGL ES
2.x). This patch does not change the situation in any way.
This extension was previously not supported on i810, mga (G200), or
tdfx (Voodoo Banshee).
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On pre-GEN6 chips, the VUE slots set aside for clip distance aren't
actually used, so there is no reason for the clipper to waste time
interpolating them.
When commit 62bad54727690bff5ed42a74272e7822fd36cdb6 changed the enum
value used to represent these VUE slots, that caused the clipper to
start interpolating them as an accidental side effect. This patch
reverts to the old clipper behavior.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corrects two errors in the computation of the psiz/flags
VUE slot on pre-GEN5 when using the new VS backend:
- The clip flags (which should be stored in the w component of the
first VUE slot) were being accidentally duplicated in all other
components of that VUE slot, causing partially clipped triangles to
sometimes disappear completely.
- The OR instruction wasn't being stored in "inst", causing the
BRW_PREDICATE_NORMAL flag to be applied to the wrong instruction.
This patch fixes regressions in clipping behavior when using shaders
on GEN4-5.
Reviewed-by: Kenneth Graunke <[email protected]>
|