Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
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
|
|
_ActualFormat is replaced by Format (MESA_FORMAT_x).
ColorEncoding, ComponentType, RedBits, GreenBits, BlueBits, etc. are
all replaced by MESA_FORMAT_x queries.
|
|
|
|
|
|
|
|
This currently doesn't include fixing up the cliptests in the assembly
paths to support ARB_depth_clamp, so enabling depth_clamp forces the C path.
|
|
Fixes bug 17800.
|
|
This is another step toward removing a whole bunch of -I flags from
the cc commands. Still need to address driver code...
|
|
Was changed while debugging #7205. Broke the shadowtext demo. Revisit this
if the problem w/ bug 7205 returns...
|
|
|
|
|
|
|
|
|
|
This allows render to depth texture (we don't support floating pt. Z buffers).
Rename MESA_FORMAT_DEPTH_COMPONENT16/32 as MESA_FORMAT_Z16/32.
Software fallback for glCopyTexImage now uses integer temporary image instead
of float, eliminates a lot of float/int conversions.
|
|
|
|
|
|
Attachment[BUFFER_DEPTH/STENCIL].Renderbuffer. The former may be wrappers
around combined depth/stencil renderbuffers attached at the later points.
|
|
|
|
|
|
|
|
|
|
Use _swrast_get_values() which does clipping.
|
|
|
|
|
|
|
|
Main driver impacts:
- new code for creating the Mesa GLframebuffer
- new span/pixel read/write code
Some drivers not yet updated/tested.
|
|
|
|
|
|
|
|
|
|
|
|
1. Remove all.h and PC_HEADER junk.
2. Rolled mem.c and mem.h into imports.c and imports.h
3. Include imports.h instead of mem.h
Restore _mesa_create/initialize_context() to be like they were in 4.0.4
New wrappers for a few std C functions: _mesa_atoi(), _mesa_strstr(), etc.
|
|
data are broken out into a new struct span_arrays which is allocated
per-context (to avoid huge stack allocations - a problem on Windows).
This lets us use span.redStep instead of span->redStep (for example) to
hopefully get slightly better performance in the triangle functions.
|
|
|
|
|
|
type, width, interp mask and array mask.
|
|
memory. These can be overridden by applications which need to manage this
memory specially. Contributed by Gerk Huisma.
Also, new code for 8-bit -> 16-bit/channel texture image storage which
fills in the least-significant bits properly.
|
|
instead of passing a GLcontext* to ResizeBuffers(), pass a GLframebuffer*.
The idea is that a window can be resized without it being bound to a rendering
context. This makes for a nice clean-up in the XFree86 server-side GLX code.
Renamed ctx->Driver.ResizeBuffersMESA() to ctx->Driver.ResizeBuffers().
|
|
|
|
|
|
Big clean-up of line drawing code.
Removed many obsolete span processing functions.
|
|
ditch the pb (pixel buffer) code.
Converted point drawing, bitmaps and aa lines to use new span functions.
|
|
_mesa_rasterize_span() is gone, replaced by new _mesa_write_textured_span().
Removed some unneeded triangle functions - more simplification possible.
|
|
struct sw_span is used throughout span/fragment processing.
This is leading to less code and more chances for optimization.
|
|
|
|
|
|
|