| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
IB size: -1.6%
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
IB size: -0.4%
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
| |
Let's use the same user data SGPRs in all stages.
(for SPI_SHADER_USER_DATA_COMMON_0)
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
It shows the sum of all IBs per frame.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
This should decrease IB fetch latency.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
i.e. don't use |=
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
If there happened to be an ENOENT laying around, we would try using the
ioctls later and fail out resource allocation.
|
|
|
|
|
| |
It was calling down into i915 trying to label the BO, which is definitely
not the right thing.
|
|
|
|
| |
Fixes dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb5_a1
|
|
|
|
|
|
| |
Will use in VK_ANDROID_native_buffer.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow us to implement VK_ANDROID_native_buffer without dup'ing
the fd. We must close the fd in VK_KHR_external_memory_fd, but we should
not in VK_ANDROID_native_buffer.
v2:
- Add missing close(fd) for case
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR, subcase
ANV_SEMAPHORE_TYPE_BO.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If this flag is set, then the image and the bo have the same lifetime.
vkDestroyImage will release the bo.
We need this for VK_ANDROID_native_buffer, because that extension
creates the VkImage *and* imports its memory during the same
call, vkCreateImage.
v2: Rebase onto VK_KHR_bind_memory2.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In src/intel/vulkan/*, redirect all instances of printf, vk_error,
anv_loge, anv_debug, anv_finishme, anv_perf_warn, anv_assert, and their
many variants to the new intel_log functions. I believe I caught them
all.
The other subdirs of src/intel are left for a future exercise.
v2:
- Rebase onto Tapani's VK_EXT_debug_report changes.
- Drop unused #include <cutils/log.h>.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm bringing up Vulkan in the Android container of Chrome OS (ARC++).
On Android, stdio goes to /dev/null. On Android, remote gdb is even more
painful than the usual remote gdb. On Android, nothing works like you
expect and debugging is hell. I need logging.
This patch introduces a small, simple logging API that can easily wrap
Android's API. On non-Android platforms, this logger does nothing fancy.
It follows the time-honored Unix tradition of spewing everything to
stderr with minimal fuss.
My goal here is not perfection. My goal is to make a minimal, clean API,
that people hate merely a little instead of a lot, and that's good
enough to let me bring up Android Vulkan. And it needs to be fast,
which means it must be small. No one wants to their game to miss frames
while aiming a flaming bow into the jaws of an angry robot t-rex, and
thus become t-rex breakfast, because some fool had too much fun desiging
a bloated, ideal logging API.
If people like it, perhaps we should quickly promote it to src/util.
The API looks like this:
#define INTEL_LOG_TAG "intel-vulkan"
#define DEBUG
intel_logd("try hard thing with foo=%d", foo);
n = try_foo(...);
if (n < 0) {
intel_loge("%s:%d: foo failed bigtime", __FILE__, __LINE__);
return VK_ERROR_DEVICE_LOST;
}
And produces this on non-Android:
intel-vulkan: debug: try hard thing with foo=93
intel-vulkan: error: anv_device.c:182: foo failed bigtime
v2: Fix meson build. [for dcbaker]
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
chadv: I made this patch by extracting the hunk from Tapani's patch in
https://lists.freedesktop.org/archives/mesa-dev/2017-September/169602.html.
Signed-off-by: Chad Versace <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
A first step to supporting Vulkan on ARC++. Mesa on ARC++ uses
Autotools, not Android.mk.
Doing this now, even before VK_ANDROID_native_buffer is implemented,
allows us to incrementally add Android support to the Autotools build.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
| |
Suggested-by: Dylan Baker <[email protected]>
Signed-off-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
| |
Suggested-by: Andres Gomez <[email protected]>
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
Cc: [email protected]
Signed-off-by: Henri Verbeet <[email protected]>
Fixes: e73d136a023 ("vulkan/wsi/x11: Implement FIFO mode.")
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]
|
|
|
|
|
|
| |
Fixes: 17201a2eb0b1b8538713 "radv: port to using updated anv entrypoint/extension generator."
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Andres Gomez <[email protected]>
|
|
|
|
| |
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
| |
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Previously this would return the largest possible buffer size, which is
much larger than the codecs themselves support. This caused confusion
when client applications attempted to decode 8K video thinking it was
supported when it isn't.
Signed-off-by: Mark Thompson <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Consistently use it as a PIPE_VIDEO_ENTRYPOINT.
v2: Return an error if the entrypoint is not set (Christian).
Signed-off-by: Mark Thompson <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
|
|
|
|
|
| |
This is not in libva 2.0, so it shouldn't be enabled yet.
Signed-off-by: Mark Thompson <[email protected]>
Acked-by: Christian König <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So one of the CTS tests tries to allocate a 16384x1 2048 array
texture. This overflows a bunch of calculations when we want it
tiled as the heights goes to 128.
addrlib returns us the correct size (16GB or so), but we mangle
it in the htile calcs due to the 32-bit offset fields, then
userspace gives us the reduced number and we try to allocate
it on a heap and things blow up.
We really need to give the app back the correct size for the
image so we can blow up properly in memory allocation later.
This should fix hangs in
dEQP-VK.pipeline.render_to_image.core.1d_array.huge.width_layers.r8g8b8a8_unorm_d32_sfloat_s8_uint
since
Fixes: ad3d98da9f (radv: enable tc compatible htile for d32s8 also.)
Now there's an open question if we should be enabling tc-compat
htile at all for shallow textures like the above.
This might cause some other wierd side effects in CTS even
without the tc compat so:
Cc: "17.2" <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This ports radv to using the anv entrypoint/extension generator
code.
No differences on enabled extensions list in vulkaninfo.
Acked-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
This was in the wrong place.
Fixes: ba51ad2f2 (radv: Expose VK_KHX_multiview.)
Acked-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
This reverts commit 9d54025cd1eee3f42b80c062d1f644904bf2ba41.
It breaks KOTOR.
Cc: 17.1 17.2 <[email protected]>
|
|
|
|
|
|
|
|
| |
update_single_program_texture() never returns NULL.
Signed-off-by: Miklós Máté <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
| |
v2: - add dependency on dispatch.h generator (which this test needs)
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]> (v1)
|
|
|
|
|
| |
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This doesn't include llvmpipe.
v2: - Fix inconsistent use of with_gallium_swrast and
with_gallium_softpipe.
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Tested with a GK107.
v2: - Add target for nouveau standalone compiler. This target is not
built by default.
v3: - Add nouveau to list of drivers built by default
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <eric at anholt.net>
|
|
|
|
|
|
|
|
|
|
| |
This hooks up the bits necessary to build gallium dri drivers, with
radeonSI as the first example driver. This isn't tested yet.
v4: - drop radeonsi generated header from sources.
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <eric at anholt.net>
|
|
|
|
|
| |
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <eric at anholt.net>
|
|
|
|
|
|
|
|
| |
This builds the radeonsi (and radeon) window system bits and gallium
driver bits.
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <eric at anholt.net>
|
|
|
|
|
| |
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <eric at anholt.net>
|
|
|
|
|
|
|
| |
This builds ddebug, noop, rbug, and trace drivers.
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <eric at anholt.net>
|
|
|
|
| |
Signed-off-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than group dependencies in complex groups, use a flatter
structure with split dependencies to avoid checking for the same
dependencies twice.
v2: - Fix building vulkan drivers without gallium or dri drivers
v3: - Drop TODO comment that is done
- Fix typo in commit message
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
| |
v2: - guard gallivm files with "with_llvm" instead of "dep_llvm.found()"
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]> (v1)
|
|
|
|
|
| |
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
This confused the with_dri flag which is meant to control Direct
Rendering Infrastructure, not classic drivers
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d80cbbeaff9329fdc78ae3d97097c1e65dfcdd61.
It turns out that formats do matter - the framebuffer's miptree has an
sRGB format, and the one we created did not. This broke rendering when
using KWin compositing, GNOME Terminal Fedora (with a transparent
background), and Qt menu rendering in general, to name a few.
It's been a month and this hasn't been fixed, and I'm sick of reverting
this patch or applying NAK'd hacks and restarting various programs at
random times every day, multiple times a day, to keep my desktop
environment functional.
The only benefit of this patch was to prepare the way for modifiers,
which AFAIK aren't finished yet anyway, so there's really no downside
to reverting it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 32fcced7b479 ("meta: Unset the textures_used_by_txf bitfield.")
added a dependency in libmesa_dricore to NIR headers, but failed to add
libmesa_nir as a dependency resulting in a build error:
In file included from external/mesa3d/src/mesa/drivers/common/meta.c:90:
external/mesa3d/src/compiler/nir/nir.h:48:10: fatal error: 'nir_opcodes.h' file not found
Add libmesa_nir as a static library dependency to libmesa_dricore.
Fixes: 32fcced7b479 ("meta: Unset the textures_used_by_txf bitfield.")
Reviewed-by: Kenneth Graunke <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
|
|
|
|
|
|
|
|
| |
We know that we will only ever need to lookup an external handle and so
can defer adding a bo to the external ht until it is ever exported or
imported, keeping that hashtable compact.
Reviewed-by: Kenneth Graunke <[email protected]>
|