| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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.
|
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | |/
| |/| |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This ensures the driver won't map the wrong set of textures.
|
| |/
|/|
| |
| |
| | |
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()
|
| | | |
|
| |\| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | | |
This fixes a conform selection/feedback regression introduced by commit
8f4d66c5f893b49eb3973aa3b31a856314c045c7
|
| | |
| | |
| | |
| | |
| | |
| | | |
If the fragment program uses KIL, we have to execute it before z/stencil
testing. Otherwise, deferred texture/shading lets us skip shading for
pixels that fail z/stencil testing.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
progs/demos/cubemap.c
src/gallium/drivers/softpipe/sp_tex_sample.c
src/gallium/drivers/softpipe/sp_texture.c
|
| | | |
| | | |
| | | |
| | | | |
Same change as for softpipe
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | | |
|