This allows individual headers to be included without warnings.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
A header that is included by all internal source files. It replaces
vkr_object.h.
No functional change.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The below are tracked:
- CREATE_OBJECT
- DESTROY_OBJECT
- CREATE_PIPELINE_ARRAY
- vkAllocateMemory
- vkFreeMemory
- vkCreateRenderPass2
The descriptor sets and command buffers are tracked by the pools.
The queues are not tracked as device objects.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
The same call cannot be reused in physical device enumeration error,
because apps can still normally destroy objects without mistake.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
This is also to prepare for destroying device level objects here.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
This doesn't do much. It would be more ideal if it could do 32-bit
builds as well.
To run deqp-vk, while there is lavapipe, lavapipe lacks external memory
that vkr requires. Some efforts will be needed to make the combination
work.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Wrap the below:
vkCreateGraphicsPipelines
vkCreateComputePipelines
The difference between pipeline creation and pool objects allocation is
too much to share macro.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Although anisotropic filtering uses a float value, most hw doesn't
care below integer levels, so just transmit 1-16 for the sampler value
not the full float.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Previously, virgl generated invalid GLSL for atomicCompSwap leading
to compile errors.
Signed-off-by: John Bates <jbates@chromium.org>
Reviewed-by: Lepton Wu <lepton@chromium.org>
Detected by fuzzer.
glDebugMessageInsert() expects either a char buffer and non-negative
length, or a null-terminated c-string and negative length. If a
non-null-terminated buffer is passed with a negative length, mesa
attempts to determine the length with strlen() and accesses out of
bounds memory.
This patch drops support for negative length, and consequently for
null-terminated debug messages from virglrenderer.
v2: explicitly disallow negative string lengths and null-terminated
strings.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
We do not want to call vn_dispatch_command on the first command, which
checks the decoder status after decoding. But the main motivation is to
silence all but the first "vkFoo resulted in CS error".
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
VkResult errors are regular runtime errors. The logging is for debug
only.
Add vn_dispatch_should_log_result to decide whether a VkResult error
should be logged. It will greatly reduce the diff size in the future.
Silence VK_ERROR_FRAGMENTED_POOL and VK_ERROR_OUT_OF_POOL_MEMORY.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Resources imported from dma-bufs as EGL images are given internal format
GL_RGB8 (24bpp) by host mesa. When placing srgb texture views on such
resources, the appropriate view format would be GL_SRGB8, but this is
not color-renderable for GL or GLES and results in an incomplete
framebuffer. Instead, GL_RGB8 must be used as the attachment format and
linear->srgb colorspace conversions must be applied manually in the frag
shader and for calls to glClearColor() involving these surfaces.
This resolves a
dEQP-EGL.functional.wide_color.window_888_colorspace_srgb test failure
for GBM-enabled hosts with newer host mesa, which imports
B8G8R8X8_UNORM and R8G8B8X8_UNORM as 24bpp instead of the more
compatible 32bpp.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: John Bates <jbates@chromium.org>
For fragment ARB programs, the fog co-ordinate input
can be requested independently of any other part of the
graphics pipeline. Through the use of an OPTION declaration.
This can lead to a case where a fragment shader expects
a fog co-ordinate input, but it is not being supplied
by the preceding shader stage.
This patch will fix it by forcing it to 0 when it detects
the case, which should neutralize the fog color.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
These variables don't support swizzling, but are accessed as
arrays.
v2: Fix copy-paste error (David Riley)
Closes: #230
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: David Riley <davidriley@chromium.org>
__lsan_default_suppressions is only defined if -fsanitize=address, but
leak suppression is still needed when the LeakSanitizer is used without
the AddressSanitizer (-fsanitize=fuzzer for example, since LeakSanitizer
is enabled by default on linux).
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: David Riley davidriley@chromium.org
Compute shader don't have in- or outputs, so don't try to
sync the interfaces with the shaders that are still bound.
This fixes a state leak where non-compute shaders are still
bound when a compute shader is compiled.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
As suggested by Lepton
Fixes 57a4e9498a
vrend: get rid of glShaderStorageBlockBinding
Closes: #229
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
align expects 32-bit integers while size_t can be 64-bit. Also move
aligning to after size is checked against
VKR_CS_DECODER_TEMP_POOL_MAX_SIZE.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>