| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Include imports.h directly instead of indirectly through context.h.
version.c does use any symbols that are added by context.h.
|
|
|
|
|
|
Directly include mtypes.h if a file uses a gl_context struct. This
allows future removal of headers that are not strictly necessary but
indirectly include mtypes.h for a file.
|
|
this fixes doom3 crash.
|
|
|
|
BaseLevel/MaxLevel are mostly used for two things: clamping texture
access for FBO rendering, and limiting the used mipmap levels when
incrementally loading textures. By restricting our mipmap trees to
just the current BaseLevel/MaxLevel, we caused reallocation thrashing
in the common case, for a theoretical win if someone really did want
just levels 2..4 or whatever of their texture object.
Bug #30366
|
|
We're always making a single-level, 0-baselevel miptree.
|
|
Include mtypes.h for gl_context symbol.
|
|
Include mtypes.h for gl_context symbol.
|
|
This has always been ugly about our texture code -- object base/max
level vs intel object first/last level vs image level vs miptree
first/last level. We now get rid of intelObj->first_level which is
just tObj->BaseLevel, and make intelObj->_MaxLevel clearly based off
of tObj->_MaxLevel instead of duplicating its code (incorrectly, as
image->MaxLog2 only considers width/height and not depth!)
|
|
See section 3.8.10 of the GL 2.1 specification. There's no way to do
anything sane with that, and drivers would get all sorts of angry.
|
|
Fixes lodclamp-between and lodclamp-between-max.
|
|
This avoids 8xx-specific texture relayout for min/max lod changes.
One step closer to avoiding relayout for base/maxlevel changes!
|
|
It's already handled by our non-mipmapped MinFilter, since
TEXTURE_RECTANGLE is always NEAREST or LINEAR.
|
|
It's always BaseLevel (since TEXTURE_RECTANGLE's baselevel can't be
changed from 0), except for 8xx minlod hilarity.
|
|
The SGIS_texture4D extension was thankfully never completed, so we
couldn't implement it if we wanted to.
|
|
|
|
It was quite a mess by trying to do NULL renderbuffers and real
renderbuffers in the same function. This clarifies the common case of
real renderbuffers.
|
|
|
|
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=32713
|
|
This makes
fbo-generatemipmap-formats GL_EXT_texture_sRGB-s3tc
match
fbo-generatemipmap-formats GL_EXT_texture_compression_s3tc
and swrast in bad DXT1_RGBA alpha=0 handling, but it means we won't
unpack and repack someone's textures into uncompressed SARGB8 format.
|
|
|
|
It's just LUMINANCE, not LUMINANCE_ALPHA. Fixes
fbo-generatemipmap-formats GL_EXT_texture_sRGB-s3tc assertion failure
when it tries to pack the L8 channels into LUMINANCE_ALPHA and wonders
why it's trying to do that.
|
|
We now share the type/format -> MESA_FORMAT_* mappings with software
mesa, and the core supports most of the fallbacks hardware drivers
will want.
|
|
Right now this is just tweaking the current code to look at the table.
Choosing actually supported formats will come later.
|
|
|
|
Use make_temp_float_image instead of _make_temp_chan_image.
The latter converts the texture to 8 bits/component, losing 2 bits.
|
|
This extension doesn't appear to need any driver-specific parts.
|
|
This workaround fixes rendering of kwin thumbnails.
NOTE: This is a candidate for the 7.9 and 7.10 branches.
|
|
From the r600 ISA:
Each ALU clause can lock up to four sets of constants
into the constant cache. Each set (one cache line) is
16 128-bit constants. These are split into two groups.
Each group can be from a different constant buffer
(out of 16 buffers). Each group of two constants consists
of either [Line] and [Line+1] or [line + loop_ctr]
and [line + loop_ctr +1].
For supporting more than 64 constants, we need to
break the code into multiple ALU clauses based
on what sets of constants are needed in that clause.
Note: This is a candidate for the 7.10 branch.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
rc_inst_can_use_presub() wasn't checking for too many RGB sources in
Alpha instructions or too many Alpha sources in RGB instructions.
Note: This is a candidate for the 7.10 branch.
|
|
Perform this check in ast_declarator_list::hir().
From section 4.3.6 of the GLSL 1.30 spec:
"If a vertex output is a signed or unsigned integer or integer
vector, then it must be qualified with the interpolation
qualifier
flat."
|
|
Allow redeclaration of the following built-in variables with an
interpolation qualifier in language versions >= 1.30:
* gl_FrontColor
* gl_BackColor
* gl_FrontSecondaryColor
* gl_BackSecondaryColor
* gl_Color
* gl_SecondaryColor
See section 4.3.7 of the GLSL 1.30 spec.
|
|
|
|
We were looking at the current draw buffer instead to see whether the
depth/stencil combination matched. So you'd get told your framebuffer
was complete, until you bound it and went to draw and we decided that
it was incomplete.
|
|
The _ColorDrawBuffers is a piece of computed state that gets for the
current draw/read buffers at _mesa_update_state time. However, this
function actually gets used for non-current draw/read buffers when
checking if an FBO is complete from the driver's perspective. So,
instead of trying to just look at the attachment points that are
currently referenced by glDrawBuffers, look at all attachment points
to see if they're driver-supported formats. This appears to actually
be more in line with the intent of the spec, too.
Fixes a segfault in my upcoming fbo-clear-formats piglit test, and
hopefully bug #30278
|
|
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=32560
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Alternately, some search&replace could be used to replace all
occurances of GLint with int, etc. in the driver.
|
|
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=32814
|
