Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
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.
|
|
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!)
|
|
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.
|
|
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.
|
|
We now share the type/format -> MESA_FORMAT_* mappings with software
mesa, and the core supports most of the fallbacks hardware drivers
will want.
|
|
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
|
|
Bug #32207. Fixes ARB_texture_rg/fbo-clear-formats (see my
fbo-clear-formats piglit branch currently)
|
|
Fixes a potential segfault on a non-native depthbuffer, and possible
accidental swrast fallback on extra color buffers.
|
|
Hopefully should fix bug #32520.
|
|
This is the hack for input interactivity of frontbuffer rendering
(like we do for backbuffer at intelDRI2Flush()) by waiting for the n-2
frame to complete before starting a new one. However, for an
application doing multiple contexts or regular rebinding of a single
context, this would end up lockstepping the CPU to the GPU because
every unbind was considered the end of a frame.
Improves WOW performance on my Ironlake by 48.8% (+/- 2.3%, n=5)
|
|
|
|
Old MI_FLUSH command is deprecated on sandybridge blt.
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32541
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The only mismatch between the two is that we have to clear the
destination's alpha to 1.0. Fixes WOW performance on my Ironlake,
from a few frames a second to almost playable.
|
|
Before, we were going off of a couple of known (hopeful) matches
between internalFormats and the cpp of the read buffer. Instead, we
can now just look at the gl_format of the two to see if they match.
We should avoid bad blits that might have been possible before, but
also allow different internalFormats to work without having to
enumerate each one.
|
|
The blit that follows appears in the command stream so it's serialized
with previous rendering. Any queued vertices in the tnl layer were
already flushed up in mesa/main/.
|
|
Not fixing a particular bug, just noticed by code inspection.
|
|
|
|
This requires shuffling the driconf XML macros around, since they use
true and false tokens expecting them to not get expanded to anything.
|
|
One less place to forget to put your new MESA_FORMAT support in.
|
|
|
|
This starts spantmp2.h down the path of using MESA_FORMAT_* for
specifying the format instead of the crazy GL format/type combo.
|
|
Fixes texture-rg.
|
|
|
|
Sometimes I'm on the train and want to just read what's generated
under INTEL_DEBUG=vs,wm for some code on another generation. Or, for
the next gen enablement we'll want to dump aub files before we have
the actual hardware. This will let us do that.
|
|
Fixes bugzilla #31832
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
This should prevent the field going unset in the future. See bug
http://bugs.freedesktop.org/show_bug.cgi?id=31544 for background.
Also remove unneeded calls to clear_teximage_fields().
Finally, call _mesa_set_fetch_functions() from the
_mesa_init_teximage_fields() function so callers have one less
thing to worry about.
|
|
Signed-off-by: Robert Hooker <robert.hooker@canonical.com>
|
|
Also fixup code comment to reflect that the GPU requires DWORD
alignment, but in this case does not actually pass the value "in
DWORDs" as I previously stated.
|
|
This reverts commit 76360d6abc9e0195bc5c373101ae616e68b2e6e6. On
second thought, it turned out that sync objects also used the
wait_rendering API like this, and would need the same treatment, and
so wait_rendering itself is fixed in libdrm now.
|
|
We were asking for a wait to GTT read (all GPU rendering to it
complete), instead of asking for all GPU reading from it to be
complete. Prevents swapbuffers-based apps from running away with
rendering, and produces a better input experience.
|
|
The width of the 2D blits used to copy the data is defined as a 16-bit
signed integer, but the pitch must be DWORD aligned. Limit to an integral
number of DWORDs, (1 << 15 - 4) rather than (1 << 15 -1).
Fixes corruption to data uploaded with glBufferSubData.
Signed-off-by: Peter Clifton <pcjc2@cam.ac.uk>
|
|
|
|
intel_finalize_mipmap_tree() does this optimization too, just more
aggressively.
|
|
logbase2(max(width, height, depth)) ==
max(logbase2(width), logbase2(height), logbase2(depth)), but in 60
bytes less code.
|
|
In testing on Ironlake, the histogram of clocks/pixel results for the
system memcpy and magic unaligned memcpy show no noticeable difference
(and no statistically significant difference with the 5510 samples
taken, though the stddev is large due to what looks like the cache
effects from the different texture sizes used).
|
|
This provides the optimizer with hints about code hotness, which we're
quite certain about for debug printouts (or, rather, while we
developers often hit the checks for debug printouts, we don't care
about performance while doing so).
|
|
No measurable performance difference on cairo-perf-trace, but
simplifies the code and should have cache benefit in general.
|