| Age | Commit message (Collapse) | Author |
|---|
|
We were calling this from the CI span function, but not the RGBA
span function.
I don't know of a test program for the GL_EXT_depth_bounds_test
extension...
|
|
The integer Z clamping range depends on the number of bits
in the Z buffer because that's the scale factor used when we
transform NDC coords by the viewport/depth range.
Fixes fd.o bug #25972 but only for Z buffers up to a depth
of 30 bits. Beyond that we get into messy integer overflow
issues and things fall apart.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When using multiple color drawbuffers with blending/logicop/masking we
were overwriting color values which we still needed.
|
|
Conflicts:
src/gallium/drivers/softpipe/sp_quad_blend.c
|
|
|
|
|
|
Add a GLbitfield64 type and several macros to operate on 64-bit
fields. The OutputsWritten field of gl_program is changed to use that
type. This results in a fair amount of fallout in drivers that use
programs.
No changes are strictly necessary at this point as all bits used are
below the 32-bit boundary. Fairly soon several bits will be added for
clip distances written by a vertex shader. This will cause several
bits used for varyings to be pushed above the 32-bit boundary. This
will affect any drivers that support GLSL.
At this point, only the i965 driver has been modified to support this
eventuality.
I did this as a "squash" merge. There were several places through the
outputswritten64 branch where things were broken. I foresee this
causing difficulties later for bisecting. The history is still
available in the branch.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm.h
|
|
|
|
|
|
I'd written a testcase for the hard part of the extension enablement, so
naturally the easy stuff was completely broken. There are still issues,
as I'm seeing FLOAT_TO_UINT(max_f) == 0x0 when max_f == 1.0, but it gets
piglit depth-clamp-range closer to success.
|
|
|
|
Conflicts:
src/mesa/drivers/dri/radeon/radeon_fbo.c
src/mesa/drivers/dri/s3v/s3v_tex.c
src/mesa/drivers/dri/s3v/s3v_xmesa.c
src/mesa/drivers/dri/trident/trident_context.c
src/mesa/main/debug.c
src/mesa/main/mipmap.c
src/mesa/main/texformat.c
src/mesa/main/texgetimage.c
|
|
Fix backward component ordering for RGB textures.
Only optimize RGBA texture case if running little endian. This restriction
could be lifted with a little work.
|
|
|
|
|
|
|
|
_ActualFormat is replaced by Format (MESA_FORMAT_x).
ColorEncoding, ComponentType, RedBits, GreenBits, BlueBits, etc. are
all replaced by MESA_FORMAT_x queries.
|
|
|
|
|
|
|
|
This ensures the driver won't map the wrong set of textures.
|
|
Need to be careful with component ordering for MESA_FORMAT_RGB888
and MESA_FORMAT_RGBA8888.
|
|
Removed: MESA_FORMAT_RGBA, RGB, ALPHA, LUMINANCE, LUMINANCE_ALPHA, INTENSITY.
|
|
Now gl_texture_image::TexFormat is a simple MESA_FORMAT_x enum.
ctx->Driver.ChooseTexture format also returns a MESA_FORMAT_x.
gl_texture_format will go away next.
|
|
It merges FEATURE_ARB_occlusion_query and FEATURE_EXT_timer_query, and
follows the feature conventions.
|
|
Conflicts:
src/mesa/drivers/dri/r600/r700_assembler.c
src/mesa/drivers/dri/r600/r700_chip.c
src/mesa/drivers/dri/r600/r700_render.c
src/mesa/drivers/dri/r600/r700_vertprog.c
src/mesa/drivers/dri/r600/r700_vertprog.h
src/mesa/drivers/dri/radeon/radeon_span.c
|
|
|
|
Mostly fixes progs/demos/lodbias when MESA_TEX_PROG=1. But the LOD still
seems off by -1 or so.
May be an issue with the params passed to _swrast_compute_lambda()
|
|
|
|
Conflicts:
progs/demos/cubemap.c
src/gallium/drivers/softpipe/sp_tex_sample.c
src/gallium/drivers/softpipe/sp_texture.c
|
|
If arx and ary are equal, we still want to choose from one of them,
and not arz.
This is the same as Michal's softpipe fix.
|
|
|
|
If arx and ary are equal, we still want to choose from one of them,
and not arz.
This is the same as Michal's softpipe fix.
|
|
|
|
|
|
|
|
Replaced by new, simpler meta functions.
|
|
|
