Age | Commit message (Collapse) | Author |
|
Rather than performing lots of little writes to update the common bo
upon each update, write those into a static buffer and flush that when
full (or at the end of the batch). Doing so gives a dramatic performance
improvement over and above using mmaped access.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rather than performing a blit to completely overwrite a busy bo, simply
discard it and create a new one with the fresh data.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reuse the new common upload buffer for uploading temporary indices and
rebuilt vertex arrays.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Dynamic arrays have the tendency to be small and so allocating a bo for
each one is overkill and we can exploit many efficiency gains by packing
them together.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Dynamic draw buffers are used by clients for temporary arrays and for
uploading normal vertex arrays. By keeping the data in memory, we can
avoid reusing active buffer objects and reallocate them as they are
changed. This is important for Sandybridge which can not issue blits
within a batch and so ends up flushing the batch upon every update, that
is each batch only contains a single draw operation (if using dynamic
arrays or regular arrays from system memory).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
Just add the gl_api parameter to _mesa_initialize_context().
|
|
|
|
This adds i965 support for GL_EXT_framebuffer_sRGB, it introduces a new
constant to say that the driver can support sRGB enabled FBOs since enabling
the extension doesn't mean the driver can actually support sRGB.
Also adds the suggested state flush in the core code suggested by Brian.
fix the ARB_fbo color encoding.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
We just choose the texture format depending on the srgb decode bit
for the sRGB formats.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
We don't have all of the features of this extension hooked up yet, but
the consensus yesterday was that since those features are things that
we should also be supporting in our ES2 implementation, claiming ES2
here too doesn't make anything worse and will make incremental
improvement through piglit easier.
|
|
|
|
OES_standard_derivatives must be manually disabled for i915 because Mesa
enables it by default.
|
|
When attaching a small mipmap level to an FBO, the original gen4
didn't have the bits to support rendering to it. Instead of falling
back, just blit it to a new little miptree just for it, and let it get
revalidated into the stack later just like any other new teximage.
Bug #30365.
|
|
It's been replaced by just setting texObj->mt to image->mt at TexImage
time.
|
|
This avoids relayouts in the common case of glGenerateMipmap() or
people doing similar things.
Bug #30366.
|
|
If we hit this path, we're level 1+ and the base level got allocated
as a single level instead of a full tree (so we don't match
intelObj->mt). This tries to recover from that so that we end up with
2 allocations and 1 validation blit (old -> new) instead of
allocations equal to number of levels and levels - 1 blits.
|
|
This reverts commit 7ce6517f3ac41bf770ab39aba4509d4f535ef663.
This reverts commit d60145d06d999c5c76000499e6fa9351e11d17fa.
I was wrong about which generations supported baselevel adjustment --
it's just gen4, nothing earlier. This meant that i915 would have
never used the mag filter when baselevel != 0. Not a severe bug, but
not an intentional regression. I think we can fix the performance
issue another way.
|
|
|
|
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.
|
|
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.
|
|
|