... in intel_alloc_renderbuffer_storage(). The stencil buffer has quirky
pitch requirements, so its region allocation is a special case.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad@chad-versace.us>
The _mesa_base_fbo_format variant doesn't handle some texture
internalformats, such as "3".
Fixes:
fbo-blending-formats.
fbo-alphatest-formats
EXT_texture_sRGB/fbo-alphatest-formats
Reviewed-by: Brian Paul <brianp@vmware.com>
In the case where glBlitFramebuffer is being used to copy to a texture
without scaling it is faster if we can use the hardware to do a blit
rather than having to do a texture render. In most of the drivers
glCopyTexSubImage2D will use a blit so this patch makes it check for
when glBlitFramebuffer is doing a simple copy and then divert to
glCopyTexSubImage2D.
This was originally proposed as an extension to the common meta-ops.
However, it was rejected as using the BLT is only advantageous for Intel
hardware.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33934
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It's faster. Not only is the memcpy more efficiently performed in the
kernel (making up for the system call overhead), but by not using mmap
we remove the greater overhead of tracking the vma of every batch.
And it means we can read back from the batch buffer without incurring
the cost of a uncached read through the GTT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.
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.
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.
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
It turns out that computing a 56 byte key to look up a 20-byte object
out of a hash table was some sort of a bad idea. Whoops.
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] gl firefox-talos-gfx 37.799 38.203 0.39% 6/6
after:
[ 0] gl firefox-talos-gfx 34.761 34.784 0.17% 5/6
This prevents memory usage explosion in blender due to the state cache
hanging on to old fake frontbuffer regions. Sigh at blender still
using frontbuffer rendering.
Bug #24119.
The pitch is not really an inherent part of the miptree, since it's
not part of any of the layout calculations, and it's dictated by the
libdrm-allocated region pitch now.
Shaves 60k off the driver from removing the broken spans code. This
means we now require 2.6.29, which seems fair given that it's a year
old and we've removed support for non-KMS already in the last release
of 2D.
The wine d3d9 visual.c testcase was tripping over this and failing.
Presumably it's binding a packed depth/stencil texture to both
stencil and depth attachment points, and we make a new renderbuffer
wrapper for each in that case.
Wine's d3d9 visual.c testcase tries this a lot, so I've added some
piglit tests (fbo-nodepth-test, fbo-nostencil-test, fbo-stencil-only)
and enabled it.
Back when we were flushing the entire batch at BindFramebuffer, the kernel
would notice the domain transition when someone went to texture from it and
flush for us. We no longer do the batch flushing every time, so we get to
do aggressive flushing until we move batchbuffer handling to libdrm.
Fixes piglit fbo-flushing. Bug #25377. No noticeable performance loss
on cairo-gl (so this is better than batch flushing).
