This is a bit of a mega-commit, but unfortunately there's no great way
to break this up since a lot of different pieces have to match up. Here
we do the following:
- change surface layout to match swr's Load/StoreTile expectations
- fix sampler settings to respect all sampler view parameters
- fix stencil sampling to read from secondary resource
- respect pipe surface format, level, and layer settings
- fix resource map/unmap based on the new layout logic
- fix resource map/unmap to copy proper parts of stencil values in and
out of the matching depth texture
These fix a massive quantity of piglits, including all the
tex-miplevel-selection ones.
Note that the swr native miptree layout isn't extremely space-efficient,
and we end up using it for all textures, not just the renderable ones. A
back-of-the-envelope calculation suggests about 10%-25% increased memory
usage for miptrees, depending on the number of LODs. Single-LOD textures
should be unaffected.
There are a handful of regressions as a result of this change:
- Some textureGrad tests, these failures match llvmpipe. (There are
debug settings allowing improved gallivm sampling accurancy.)
- Some layered clearing tests as swr doesn't currently support that. It
was getting lucky before because enough other things were broken.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
Fixes tgsi error introduced in commit 3817a7a. The error complains missing
swizzle component in the conversion string "UMIN TEMP[0], TEMP[0], IMM[0].x".
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
My thought in having both arguments conditionally moved was that it should
theoretically save some power by not doing work in those channels.
However, it ends up costing us instructions because we can't
register-coalesce the first of the MOVs, and it also introduces extra
scheduling dependencies. The instruction cost would swamp whatever power
benefit I was hoping for.
shader-db results:
total instructions in shared programs: 100548 -> 99741 (-0.80%)
instructions in affected programs: 42450 -> 41643 (-1.90%)
With obvious outliers removed (I had an X11 emacs running over the network
in the "after" case), 3DMMES Taiji showed 1.07231% +/- 0.488241% fps
improvement (n=18, 30).
I screwed this up in fdad4d2402 which was
supposed to be making this code more maintainable. What's amazing is
multithreaded FS showed the wins it did despite this bug.
shader-db results:
total instructions in shared programs: 103535 -> 100548 (-2.89%)
instructions in affected programs: 83794 -> 80807 (-3.56%)
Gallium core just changed to start setting MSAA enabled in the rasterizer
state even with samples==1 buffers. This caused disagreements in our
driver between binning and rasterization state, which the simulator threw
assertion failures about. Keep the single-sampled samples==1 behavior for
now.
I dropped the first hunk of this change last minute when I decided it
wasn't actually needed, and apparently failed to piglit it in simulation.
The simulator threw an an assertion in gl-1.0-drawpixels-color-index,
which queued up 5 coordinates (3 before a switch, two after) before
loading the result.
This seems like it would conform better with the spec.
noticed while digging into fast clears.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It turns out that the flushing required around resolves is a bit more
extensive than I first thought. You actually need render cache flush
and a CS stall both before *and* after the resolve.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Otherwise, some pipe flushes may just never happen. This is unlikely to
cause problems depending on how the kernel schedules batches, but we
shouldn't count on it.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At vkCmdNextSubpass time, we have the actual framebuffer so we can use
regular blorp_clear for subpass clears. For fast clears, there is no
attachment version, so this will make fast clears a bit easier.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This commit adds the last remaining bits to support input attachments in
the Intel Vulkan driver. For color and depth attachments, we allocate an
input attachment surface state during vkCmdBeginRenderPass like we do for
the render target surface states. This is so that we can incorporate the
clear color and aux information as used in rendering. For stencil, we just
treat it like a regular texture because we don't there is no aux. Also,
only having to worry about at most one input attachment surface for each
attachment makes some of the vkCmdBeginRenderPass code simpler.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Input and resolve attachments can cause an implicit dependency in the
pipeline. It's our job to insert the needed flushes. Fortunately, we can
easily reuse the usage tracking that we use for CCS resolves.
This fixes 159 Vulkan CTS tests on Haswell because we're now flushing in
between drawing and MSAA resolves. I have no idea how they were passing
before on newer hardware.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We were using VK_IMAGE_ACCESS_COLOR_ATTACHMENT_READ_BIT to detect an input
attachment read. We should use VK_IMAGE_ACCESS_INPUT_ATTACHMENT_READ_BIT
instead.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
There are actually 6 of them according to the GL_KHR_vulkan_glsl spec.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The != VK_SUCCESS case is really only capable of handling the one error.
This assert makes things a bit safer if something else goes wrong.
Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
There is no version 2 of the DRI2_FENCE extension. So only a request
for version 1 has a chance to succeed.
Fixes: 74b1969d71 (gbm: wire up fence extension)
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This can happen even if the binding table isn't changed. For instance, you
could have dynamic offsets with your descriptor set. This fixes the new
stress.lots-of-surface-state.cs.dynamic cricible test.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
If we try to allocate a binding table and fail, we have to get a new
binding table block, re-emit STATE_BASE_ADDRESS, and then try again. We
already handle this correctly for 3D and blorp but it never got handled for
CS. This fixes the new stress.lots-of-surface-state.cs.static crucible test.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
The precision of our trig instructions appears to have been fixed on Kaby
Lake. Neither Ben nor I can find any documentation for this. However, the
dEQP precision tests now pass with INTEL_PRECISE_TRIG=0 where they fail on
Sky Lake.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Most of the 3-D engine Kaby Lake is identical to Sky Lake. However, there
are a few small differences that we need to be able to detect.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Since both pCreateInfo->strideInBytes and pCreateInfo->extent.height
are of uint32_t type 32-bit arithmetic will be used.
Fix unintentional integer overflow by casting to uint64_t before
multifying.
CID 1394321
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
[Emil Velikov: cast only of the arguments]
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We're missing the close() to the matching open().
CID 1373407
v2: Fixes from Emil Velikov's review
Update the teardown in reverse order of the setup/init.
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (v1)
Mention the script - why/how to use alongside a useful trick to make it
work interactively (thanks Rob!).
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Elie Tournier <tournier.elie@gmail.com>
v2: [Emil Velikov]
- Add the shorthand git send-email -vX
- Move to submittingpatches.html
- Add to the TOC.
v3: [Emil Velikov]
- Use @~8 instead of HEAD~8 (Nicolai)
Cc: Timothy Arceri <t_arceri@yahoo.com.au>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com> (v1)
Just fetch and store it once, rather than doing the
xcb_setup_roots_iterator + get_xcb_screen dance five times.
v2: Call xcb_disconnect() on error (Eric)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Identical throughout dri2, dri3 and drisw. Next patch will add more
common code, so rather than duplicating it factor out the function.
Note: this also sets eglError on failure. Something that's quite
inconsistent throughout the codebase.
v2: Call xcb_disconnect() on error (Eric)
Note: use xcb_disconnect() even in the xcb_connection_has_error() case
as per the manual:
... memory will not be freed until xcb_disconnect...
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
The old approach works fine, and this approach isn't necessarily better.
But it at least has the advantage that Vulkan and GL use the same
approach. I originally wrote it to gain additional testing for the
new paths.
shader-db statistics show 0 instruction count changes.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>