| Age | Commit message (Collapse) | Author |
|---|
|
With core mesa doing runtime API checks, GLES overlay is no longer
needed. Make --enable-gles-overlay equivalent to --enable-gles[12].
There may still be places where compile-time checks are done. They
could be fixed case by case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Include mfeatures.h for feature tests.
|
|
|
|
There really shouldn't be any difference between the two for us.
Fixes a bug where Z16 renderbuffers would be untiled on gen6, likely
leading to hangs.
|
|
|
|
|
|
Fixes an abort in fbo-generatemipmap-formats.
|
|
By relying on just intel_span_supports_format, some formats that
aren't supported pre-gen4 were not reporting FBO incomplete. And we
also complained in stderr when it happened on i915 because draw_region
gets called before framebuffer completeness validation.
|
|
ARB_fbo no longer disallows mismatched width/height on attachments
(shouldn't be any problem), mixed format color attachments (we only
support 1), and L/A/LA/I color attachments (we already reject them on
965 too). It requires Gen'ed names (driver doesn't care), and adds
FramebufferTextureLayer (we don't do texture arrays). So it looks
like we're already in the position we need to be for this extension.
Bug #27468, #32381.
|
|
In general, we have to negate in immediate values we pass in because
the src1 negate field in the register description is in the bits3 slot
that the 32-bit value is loaded into, so it's ignored by the hardware.
However, the src0 negate field is in bits1, so after we'd negated the
immediate value loaded in, it would also get negated through the
register description. This broke this VP instruction in the position
calculation in civ4:
MAD TEMP[1], TEMP[1], CONST[256].zzzz, CONST[256].-y-y-y-y;
Bug #30156
|
|
Fix the error in uniform row calculating, it may alloc one line
more which may cause out of range on memory usage, sometimes program
aborted when free the memory.
NOTE: This is a candidate for 7.9 and 7.10 branches.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
|
|
|
|
This should make it easier to cross-reference the code and hardware
documentation, as well as clear up any confusion on whether constants
like CMD_3D_WM_STATE mean WM_STATE (pre-gen6) or 3DSTATE_WM (gen6+).
This does not rename any pre-gen6 defines.
|
|
It's called in vbo_exec_invalidate_state too.
|
|
What were these for?
|
|
The overhead of resource_create, transfer_inline_write, and resource_destroy
to upload constant data is very visible with some apps in sysprof, and
as such should be eliminated.
My approach uses a user buffer to pass a pointer to a driver. This gives
the driver the freedom it needs to take the fast path, which may differ
for each driver.
This commit addresses the same issue as Jakob's one that suballocates out
of a big constant buffer, but it also eliminates the copy to the buffer.
|
|
|
|
See http://bugs.freedesktop.org/show_bug.cgi?id=32859
NOTE: This is a candidate for the 7.9 and 7.10 branches.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
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.
|
