URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=8008bc8cba6b0de9345ac8d6f130ea61495a2ee7
Author: Daniel Stone <[email protected]>
Date: Mon May 15 22:22:32 2017 +0100
egl/wayland: Ensure we get a back buffer
Commit 9ca6711faa03 changed the Wayland winsys to only block for the
frame callback inside SwapBuffers, rather than get_back_bo. get_back_bo
would perform a single non-blocking Wayland event dispatch, to try to
find any release events which we had pulled off the wire but not
actually processed. The blocking dispatch was moved to SwapBuffers.
This removed a guarantee that we would've processed all events inside
get_back_bo(), and introduced a failure whereby the server could've sent
a buffer release event, but we wouldn't have read it. In clients
unconstrained by SwapInterval (rendering ~as fast as possible), which
were being displayed directly without composition (buffer release delayed),
this could lead to get_back_bo() failing because there were no free
buffers available to it.
The drawing rightly failed, but this was papered over because of the
path in eglSwapBuffers() which attempts to guarantee a BO, in order to
support calling SwapBuffers twice in a row with no rendering actually
having been performed.
Since eglSwapBuffers will perform a blocking dispatch of Wayland
events, a buffer release would have arrived by that point, and we
could then choose a buffer to post to the server. The effect was that
frames were displayed out-of-order, since we grabbed a frame with random
past content to display to the compositor.
Ideally get_back_bo() failing should store a failure flag inside the
surface and cause the next SwapBuffers to fail, but for the meantime,
restore the correct behaviour such that get_back_bo() no longer fails.
Signed-off-by: Daniel Stone <[email protected]>
Reported-by: Eero Tamminen <[email protected]>
Acked-by: Pekka Paalanen <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98833
Fixes: 9ca6711faa03 ("Revert "wayland: Block for the frame callback in
get_back_bo not dri2_swap_buffers"")
(cherry picked from commit 1f2d0093bf5084f65a923582881dc74153c804a4)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ff3aa6a877391ec6d28a58027048852a901bfb62
Author: Daniel Stone <[email protected]>
Date: Fri May 5 14:49:09 2017 +0100
egl/wayland: Use per-surface event queues
During display initialisation, we need a separate event queue to handle
the registry events, which is correctly handled. But we also need
separate per-surface event queues to handle swapchain-related events,
such as surface frame events and buffer release events. This avoids two
surfaces from the same EGLDisplay, both current on separate threads,
dispatching each other's events.
Create separate per-surface event queues, create wl_surface and wl_drm
proxy wrapper objects per surface, so we eliminate the race around
sending events to the wrong queue. swrast buffers do not need a
dedicated proxy wrapper, as the wl_shm_pool used to create the
wl_buffers, being transient, can itself be assigned to a queue.
Signed-off-by: Daniel Stone <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Fixes: 36b9976e1f99 ("egl/wayland: Avoid race conditions when on non-main
thread")
Cc: [email protected]
(cherry picked from commit 03dd9a88b0be17ff0ce91e92f6902a9a85ba584a)
Squashed with:
egl/wayland: verify event queue was allocated
We're already verified that 'window' wasn't NULL, I'm guessing this
allocation error is about the newly created queue.
CID: 1409754
Fixes: 03dd9a88b0b ("egl/wayland: Use per-surface event queues")
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
(cherry picked from commit 30dc56bb5b313ae67c6e8648e23bb38c8e737488)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=701a10b56ecccc4aaeb1356d5c465b6bf26fc68f
Author: Daniel Stone <[email protected]>
Date: Fri May 5 14:44:20 2017 +0100
egl/wayland: Don't open-code roundtrip
wl_display_roundtrip_queue() exists and can replace roundtrip(). The
API was introduced with wayland 1.6, while we currently require 1.11.
Signed-off-by: Daniel Stone <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Cc: [email protected]
(cherry picked from commit 8118bc269f39ea0b965752ea89b886b28094db42)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=afbe5bf434fb059c5e064bbbb90f2e275445c60a
Author: Daniel Stone <[email protected]>
Date: Tue May 2 10:06:32 2017 +0100
vulkan/wsi/wayland: Use proxy wrappers for swapchain
Though most swapchain operations used a queue, they were racy in that
the object was created with the queue only set later, meaning that its
event could potentially be dispatched from the default queue in between
these two steps.
Use proxy wrappers to avoid this race, also assigning wl_buffers created
for the swapchain to the event queue.
Signed-off-by: Daniel Stone <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Cc: [email protected]
(cherry picked from commit 5034c615582add2be9309dc1d7383fb0daba6dd3)
[Emil Velikov: wsi_wl_swapchain is missing surface_version, move
image_count]
Signed-off-by: Emil Velikov <[email protected]>
Conflicts:
src/vulkan/wsi/wsi_common_wayland.c
Squahed with:
vulkan/wsi/wayland: Fix proxy wrappers for swapchain recreation
Before the swapchain event queue is destroyed, all proxy objects that
reference
it must be dropped. Otherwise we risk a use-after-free if a frame callback
event
or buffer release events are received afterwards.
This happens when an application destroys and recreates a swapchain in FIFO
mode between two frames without using the
VkSwapchainCreateInfoKHR::oldSwapchain
mechanism to keep the old swapchain until after the next redraw.
Fixes: 5034c615582a ("vulkan/wsi/wayland: Use proxy wrappers for swapchain")
Signed-off-by: Philipp Zabel <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Cc: [email protected]
(cherry picked from commit 1586768e7475a2732650f0ec2738b4e8429e4b40)
[Emil Velikov: image_count is not in base]
Signed-off-by: Emil Velikov <[email protected]>
Conflicts:
src/vulkan/wsi/wsi_common_wayland.c
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=55e66999fc67063b5b5294193cc52a5ccaa6439f
Author: Daniel Stone <[email protected]>
Date: Tue May 2 10:04:33 2017 +0100
vulkan/wsi/wayland: Use per-display event queue
Calling random callbacks on the display's event queue is hostile, as
we may call into client code when it least expects it. Create our own
event queue, one per wsi_wl_display, and use that for the registry.
Signed-off-by: Daniel Stone <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Cc: [email protected]
(cherry picked from commit c902a1957d079941823006d56b6810e1e85be4b0)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f7cc55dce2aac2b5f7d2b40ddbdfcdeca716a526
Author: Daniel Stone <[email protected]>
Date: Tue May 2 09:51:40 2017 +0100
vulkan/wsi/wayland: Remove roundtrip when creating image
There's no need to call wl_display_roundtrip() after trying to create a
buffer through wl_drm; if it succeeds then everything is fine, and if it
fails, then we get a fatal protocol error so can't recover anyway.
Additionally, doing a roundtrip on the default / main application queue,
is destructive anyway, so would need to be its own queue.
Signed-off-by: Daniel Stone <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Cc: [email protected]
(cherry picked from commit afe8c8a2997950cd63076b7c9eba39e1858fee43)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b4a82e7f47f3ef6309cd18dbbb1c34e9daa217c7
Author: Daniel Stone <[email protected]>
Date: Fri Apr 28 16:49:47 2017 +0200
vulkan: Fix Wayland uninitialised registry
Untangle the exit cleanup paths so we don't try to use the registry
variable before it's been initialised.
Signed-off-by: Daniel Stone <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Cc: [email protected]
(cherry picked from commit d9a8bba7f44f7042f0bbd659d0ed342236423dd3)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=6dd570fa5709090384ced4d3bd68c06ece06c9aa
Author: Ilia Mirkin <[email protected]>
Date: Sat May 20 03:11:12 2017 -0400
nvc0/ir: SHLADD's middle source must be an immediate
The instruction encodings only allow for immediates. Don't try to
replace a zero (which is dumb to have in that op in any case) with RZ.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
(cherry picked from commit 82e77d4e4484b5d4f6a7b4751a17c882e6d2ad69)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=33f3ae1df2fd88db971dcb84e252a3f9bfe0730d
Author: Emil Velikov <[email protected]>
Date: Fri Nov 25 17:55:52 2016 +0000
st/va: fix misplaced closing bracket
It's been like this since the code was introduced.
Fixes: 86eb4131a90 (st/va: add headless support, i.e. VA_DISPLAY_DRM)
Cc: <[email protected]>
Cc: Julien Isorce <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Nayan Deshmukh <[email protected]>
Reviewed-by: Christian König <[email protected]>
(cherry picked from commit aaea53c2c02e4d5352ce3d08dfd43b2676d32000)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=87d16afa6ff11e7c72870bdba4a514858b31f1ab
Author: Nanley Chery <[email protected]>
Date: Thu May 11 15:57:59 2017 -0700
i965/formats: Update the three-channel DXT1 mappings
The procedure for decompressing an opaque DXT1 OpenGL format is
dependant on the comparison of two colors stored in the first 32 bits of
the compressed block. Here's the specified OpenGL behavior for
reference:
The RGB color for a texel at location (x,y) in the block is given by:
RGB0, if color0 > color1 and code(x,y) == 0
RGB1, if color0 > color1 and code(x,y) == 1
(2*RGB0+RGB1)/3, if color0 > color1 and code(x,y) == 2
(RGB0+2*RGB1)/3, if color0 > color1 and code(x,y) == 3
RGB0, if color0 <= color1 and code(x,y) == 0
RGB1, if color0 <= color1 and code(x,y) == 1
(RGB0+RGB1)/2, if color0 <= color1 and code(x,y) == 2
BLACK, if color0 <= color1 and code(x,y) == 3
The sampling operation performed on an opaque DXT1 Intel format essentially
hard-codes the comparison result of the two colors as color0 > color1.
This means that the behavior is incompatible with OpenGL. This is stated
in the SKL PRM, Vol 5: Memory Views:
Opaque Textures (DXT1_RGB)
Texture format DXT1_RGB is identical to DXT1, with the exception that
the
One-bit Alpha encoding is removed. Color 0 and Color 1 are not
compared, and
the resulting texel color is derived strictly from the Opaque Color
Encoding.
The alpha channel defaults to 1.0.
Programming Note
Context: Opaque Textures (DXT1_RGB)
The behavior of this format is not compliant with the OGL spec.
The opaque and non-opaque DXT1 OpenGL formats are specified to be
decoded in exactly the same way except the BLACK value must have a
transparent alpha channel in the latter. Use the four-channel BC1 Intel
formats with the alpha set to 1 to provide the behavior required by the
spec. Note that the alpha is already set to 1 for RGB formats in
brw_get_texture_swizzle().
v2: Provide a more detailed commit message (Kenneth Graunke).
v3: Ensure the alpha channel is set to 1 for DXT1 formats.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100925
Cc: <[email protected]>
Acked-by: Tapani Pälli <[email protected]> (v1)
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Nanley Chery <[email protected]>
(cherry picked from commit 688ddb85c8c3357d8e1e9d360c74cd728b128d98)
[Emil Velikov: attribute for BRW to ISL format rename]
Signed-off-by: Emil Velikov <[email protected]>
Conflicts:
src/mesa/drivers/dri/i965/brw_surface_formats.c
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cbd4721621accbb501ced207f78657c626cdb4f3
Author: Nanley Chery <[email protected]>
Date: Thu May 11 15:57:59 2017 -0700
anv/formats: Update the three-channel BC1 mappings
The procedure for decompressing an opaque BC1 Vulkan format is dependant on
the
comparison of two colors stored in the first 32 bits of the compressed
block.
Here's the specified OpenGL (and Vulkan) behavior for reference:
The RGB color for a texel at location (x,y) in the block is given by:
RGB0, if color0 > color1 and code(x,y) == 0
RGB1, if color0 > color1 and code(x,y) == 1
(2*RGB0+RGB1)/3, if color0 > color1 and code(x,y) == 2
(RGB0+2*RGB1)/3, if color0 > color1 and code(x,y) == 3
RGB0, if color0 <= color1 and code(x,y) == 0
RGB1, if color0 <= color1 and code(x,y) == 1
(RGB0+RGB1)/2, if color0 <= color1 and code(x,y) == 2
BLACK, if color0 <= color1 and code(x,y) == 3
The sampling operation performed on an opaque DXT1 Intel format essentially
hard-codes the comparison result of the two colors as color0 > color1. This
means that the behavior is incompatible with OpenGL and Vulkan. This is
stated
in the SKL PRM, Vol 5: Memory Views:
Opaque Textures (DXT1_RGB)
Texture format DXT1_RGB is identical to DXT1, with the exception that
the
One-bit Alpha encoding is removed. Color 0 and Color 1 are not
compared, and
the resulting texel color is derived strictly from the Opaque Color
Encoding.
The alpha channel defaults to 1.0.
Programming Note
Context: Opaque Textures (DXT1_RGB)
The behavior of this format is not compliant with the OGL spec.
The opaque and non-opaque BC1 Vulkan formats are specified to be decoded in
exactly the same way except the BLACK value must have a transparent alpha
channel in the latter. Use the four-channel BC1 Intel formats with the alpha
set to 1 to provide the behavior required by the spec.
v2 (Kenneth Graunke):
- Provide a more detailed commit message.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100925
Cc: <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Signed-off-by: Nanley Chery <[email protected]>
(cherry picked from commit 56458cb168bf79ae51ba1efc3acec15874cc34a9)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=ca697dda60b7307adc5c9e16ad49a9b6e10ed5f0
Author: Tom Stellard <[email protected]>
Date: Fri May 5 01:07:00 2017 +0000
gallivm: Make sure module has the correct data layout when pass manager runs
The datalayout for modules was purposely not being set in order to work
around
the fact that the ExecutionEngine requires that the module's datalayout
matches the datalayout of the TargetMachine that the ExecutionEngine is
using.
When the pass manager runs on a module with no datalayout, it uses
the default datalayout which is little-endian. This causes problems
on big-endian targets, because some optimizations that are legal on
little-endian or illegal on big-endian.
To resolve this, we set the datalayout prior to running the pass
manager, and then clear it before creating the ExectionEngine.
This patch fixes a lot of piglit tests on big-endian ppc64.
Cc: [email protected]
(cherry picked from commit 14e525a4d70649eb10185bebd2aef9dc339fb5e6)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b6ad01c7a2aa92b9c456e63068eda21ba905b8f1
Author: Chad Versace <[email protected]>
Date: Thu May 11 21:49:14 2017 -0700
egl: Partially revert 23c86c74, fix eglMakeCurrent
Fixes regressions in Android CtsVerifier.apk on Intel Chrome OS devices
due to incorrect error handling in eglMakeCurrent. See below on how to
confirm the regression is fixed.
This partially reverts
commit 23c86c74cc450a23848b85cfe914376caede1cdf
Author: Chad Versace <[email protected]>
Subject: egl: Emit error when EGLSurface is lost
The problem with commit 23c86c74 is that, once an EGLSurface became
lost, the app could never unbind the bad surface. Each attempt to unbind
the bad surface with eglMakeCurrent failed with EGL_BAD_CURRENT_SURFACE.
Specificaly, the bad commit added the error handling below. #2 and #3
were right, but #1 was wrong.
1. eglMakeCurrent emits EGL_BAD_CURRENT_SURFACE if the calling
thread has unflushed commands and either previous surface is no
longer valid.
2. eglMakeCurrent emits EGL_BAD_NATIVE_WINDOW if either new surface
is no longer valid.
3. eglSwapBuffers emits EGL_BAD_NATIVE_WINDOW if the swapped surface
is no longer valid.
Whe I wrote the bad commit, I misunderstood the EGL spec language
for #1. The correct behavior is, if I understand correctly now, is
below. This patch doesn't implement the correct behavior, though, it
just reverts the broken behavior.
- Assume a bound EGLSurface is no longer valid.
- Assume the bound EGLContext has unflushed commands.
- The app calls eglMakeCurrent. The spec requires eglMakeCurrent to
implicitly flush. After flushing, eglMakeCurrent emits
EGL_BAD_CURRENT_SURFACE and does *not* alter the thread's
current bindings.
- If the app calls eglMakeCurrent again, and the app inserts no
commands into the GL command stream between the two eglMakeCurrent
calls, then this second eglMakeCurrent succeeds without emitting an
error.
How to confirm this fixes the regression:
Download android-cts-verifier-7.1_r5-linux_x86-x86.zip from
source.android.com, unpack, and `adb install CtsVerifier.apk`.
Run test "Projection Cube". Click the Pass button (a
green checkmark). Then run test "Projection Widget". Confirm that
widgets are visible and that logcat does not complain about
eglMakeCurrent failure.
Then confirm there are no regressions in the cts-traded module that
commit 263243b1 fixed:
cts-tf > run cts --skip-preconditions --skip-device-info \
-m CtsCameraTestCases \
-t android.hardware.camera2.cts.RobustnessTest
Tested with Chrome OS board "reef".
Fixes: 23c86c74 (egl: Emit error when EGLSurface is lost)
Acked-by: Tapani Pälli <[email protected]>
Cc: "17.1" <[email protected]>
Cc: Tomasz Figa <[email protected]>
Cc: Nicolas Boichat <[email protected]>
Cc: Emil Velikov <[email protected]>
(cherry picked from commit 8f62d21bd72059d723f4626f76de6fec4a569616)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=8be7de22353217571a6be9e59e28257545433c29
Author: Samuel Iglesias Gonsálvez <[email protected]>
Date: Wed Apr 19 11:18:35 2017 +0200
i965/vec4: load dvec3/4 uniforms first in the push constant buffer
Reorder the uniforms to load first the dvec4-aligned variables in the
push constant buffer and then push the vec4-aligned ones. It takes
into account that the relocated uniforms should be aligned to their
channel size.
This fixes a bug were the dvec3/4 might be loaded one part on a GRF and
the rest in next GRF, so the region parameters to read that could break
the HW rules.
v2:
- Fix broken logic.
- Add a comment to explain what should be needed to optimise the usage
of the push constant buffer slots, as this patch does not pack the
uniforms.
v3:
- Implemented the push constant buffer usage optimization.
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Cc: "17.1" <[email protected]>
Acked-by: Francisco Jerez <[email protected]>
(cherry picked from commit e69e5c7006da80af62c9ef08dec215b3b4b30946)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b79233537ca35c24c101091ecc8c2e83025a4605
Author: Samuel Iglesias Gonsálvez <[email protected]>
Date: Wed Apr 19 10:35:07 2017 +0200
i965/vec4: fix swizzle and writemask when loading an uniform with constant
offset
It was setting XYWZ swizzle and writemask to all uniforms, no matter if they
were a vector or scalar, so this can lead to problems when loading them
to the push constant buffer.
Moreover, 'shift' calculation was designed to calculate the offset in
DWORDS, but it doesn't take into account DFs, so the calculated swizzle
for the later ones was wrong.
The indirect case is not changed because MOV INDIRECT will write
to all components. Added an assert to verify that these uniforms
are aligned.
v2:
- Fix 'shift' calculation (Curro)
- Set both swizzle and writemask.
- Add assert(shift == 0) for the indirect case.
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Cc: "17.1" <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
(cherry picked from commit 8aa6ada8384a961b37dfefec7f9e40e5a4e27ce7)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=98f30c71175d66d0c2e5f208cb9ee904bb23ee22
Author: Samuel Iglesias Gonsálvez <[email protected]>
Date: Fri May 5 10:42:15 2017 +0200
i965/vec4/gs: restore the uniform values which was overwritten by failed
vec4_gs_visitor execution
We are going to add a packing feature to reduce the usage of the push
constant buffer. One of the consequences is that 'nr_params' would be
modified by vec4_visitor's run call, so we need to restore it if one of
them failed before executing the fallback ones. Same thing happens to the
uniforms values that would be reordered afterwards.
Fixes GL45-CTS.arrays_of_arrays_gl.InteractionFunctionCalls2 when
the dvec4 alignment and packing patch is applied.
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Cc: "17.1" <[email protected]>
Acked-by: Francisco Jerez <[email protected]>
(cherry picked from commit 354f7f2cb9c7206e12646c79d8ff5becbaffa61b)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b50e9022bde70b6f381bf2a717ef7ac77138a9bf
Author: Eric Anholt <[email protected]>
Date: Wed May 17 13:22:39 2017 -0700
vc4: Don't allocate new BOs to avoid synchronization when they're shared.
If X11 did a software fallback to the entire screen, we would throw out
the BO the screen is scanning out from and allocate a new one.
Cc: [email protected]
(cherry picked from commit e8ea42d245cb6adc7f16ee4e96fd89d905d2163a)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=356b0b2ba1e2b6e43604a5a249e39bf881976ee2
Author: Hans de Goede <[email protected]>
Date: Mon Mar 20 08:41:26 2017 +0100
glxglvnddispatch: Add missing dispatch for GetDriverConfig
Together with some fixes to xdriinfo this fixes xdriinfo not working
with glvnd.
Since apps (xdriinfo) expect GetDriverConfig to work without going to
need through the dance to setup a glxcontext (which is a reasonable
expectation IMHO), the dispatch for this ends up significantly different
then any other dispatch function.
This patch gets the job done, but I'm not really happy with how this
patch turned out, suggestions for a better fix are welcome.
Cc: Kyle Brenneman <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Cc: [email protected]
(cherry picked from commit 84f764a7591715104b28c035c837ce9fd86157ad)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=968f0c657439131e8c0e3158e53f1f409618f999
Author: Pohjolainen, Topi <[email protected]>
Date: Wed May 3 12:22:50 2017 +0300
intel/isl/gen7: Use stencil vertical alignment of 8 instead of 4
The reasoning Chad gave in the comment for choosing a valign of 4 is
entirely bunk. The fact that you have to multiply pitch by 2 is
completely unrelated to the halign/valign parameters used for texture
layout. (Not completely unrelated. W-tiling is just Y-tiling with a
bit of extra swizzling which turns 8x8 W-tiled chunks into 16x4 y-tiled
chunks so it makes everything easier if miplevels are always aligned to
8x8.) The fact that RENDER_SURFACE_STATE::SurfaceVerticalAlignmet
doesn't have a VALIGN_8 option doesn't matter since this is gen7 and you
can't do stencil texturing anyway.
v2 (Jason Ekstrand):
- Delete most of Chad's comment and add a more descriptive commit
message.
Signed-off-by: Topi Pohjolainen <[email protected]>
Cc: "17.0 17.1" <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
(cherry picked from commit 236f17a9f73935db6cddafd91e53a5fae34aae6e)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cebba270fa6d6d9099c1074ccfd777c4132bee06
Author: Lucas Stach <[email protected]>
Date: Wed May 10 18:01:04 2017 +0200
etnaviv: stop oversizing buffer resources
PIPE_BUFFER is a target enum, not a binding. This caused the driver to
up-align the height of buffer resources, leading to largely oversizing
those resources. This is especially bad, as the buffer resources used
by the upload manager are already 1MB in size. Height alignment meant
that those would result in 4 to 8MB big BOs.
Fixes: c9e8b49b885 ("etnaviv: gallium driver for Vivante GPUs")
Cc: [email protected]
Signed-off-by: Lucas Stach <[email protected]>
Reviewed-By: Wladimir J. van der Laan <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
(cherry picked from commit 8173d7d9e8b40cc9415811ad13924daa04a73646)
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cb8a159e22ee550ebcdb50b13d9e9b77c47810b0
Author: Eric Anholt <[email protected]>
Date: Tue May 9 11:24:21 2017 -0700
renderonly: Initialize fields of struct winsys_handle.
vc4 was rejecting renderonly's import, because the offset field was
nonzero.
Fixes: 848b49b288f ("gallium: add renderonly library")
Cc: [email protected]
Signed-off-by: Eric Anholt <[email protected]>
Reviewed-by: Christian Gmeiner <[email protected]>
(cherry picked from commit c98f03c6ebaca82c265b2f3242aed5c6a3c5dcd8)
_______________________________________________
mesa-commit mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-commit
