Many thanks!
24.06.2018, 04:50, "Jason Ekstrand" :
> Yes, we already have support for VK_EXT_shader_viewport_index_layer. For
> VK_EXT_vertex_attribute_divisor, it should be trivial and I'm happy to do so
> but there are currently no tests for it and, up until this email, we haven't
> had any
Yes, we already have support for VK_EXT_shader_viewport_index_layer. For
VK_EXT_vertex_attribute_divisor, it should be trivial and I'm happy to do
so but there are currently no tests for it and, up until this email, we
haven't had any call for that. We'll try to bump it up the priority list.
I have latest available version of Mesa - 18.1.2, Vulkan - 1.1.0.Can I check available extensions VK for my version? 24.06.2018, 03:35, "Bas Nieuwenhuizen" :Not sure about the other extension, but the latest version of theintel driver should support VK_EXT_shader_viewport_index_layeralready.On Sun,
Not sure about the other extension, but the latest version of the
intel driver should support VK_EXT_shader_viewport_index_layer
already.
On Sun, Jun 24, 2018 at 1:13 AM, Александр Бесчасный wrote:
> Hello, can I ask if it is planned to implement VK extensions for i965:
> - VK_EXT_shader_viewport
Hello, can I ask if it is planned to implement VK extensions for i965:- VK_EXT_shader_viewport_index_layer- VK_EXT_vertex_attribute_divisorThe new version of DXVK 0.60 requires their availability.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
h
We already guarded all OP_SULDP against out of bound accesses, but those
ended up just reusing whatever value was stored in the dest registers.
fixes CTS test shader_image_load_store.incomplete_textures
Signed-off-by: Karol Herbst
---
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 30 +
I haven't thought through this comment all that hard but would it make
sense to have three timestamps, CPU, GPU, CPU so that you have error bars
on the GPU timestamp? At the very least, two timestamps would be better
than one so that, when we pull it into the kernel, it can provide something
m
https://bugs.freedesktop.org/show_bug.cgi?id=106980
--- Comment #4 from Jason Ekstrand ---
(In reply to Bas Nieuwenhuizen from comment #3)
> Seems like the validation issue was fixed by the deref rewrite, and that has
> been upstreamed now.
That makes me suspicious. If we were getting a validat
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.
v2: Adopt Jason Ekstrand's codi
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.
v2: Adopt Jason Ekstrand's codi
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.
Signed-off-by: Keith Packard
---
This extension fetches the current GPU timestamp from the hardware,
just like the OpenGL API glGetInteger64v(GL_TIMESTAMP, ×tamp)
function.
I need this to correlate GPU and CPU timestamps for the
GOOGLE_display_timing extension, but I think it will be useful for
applications as well.
I'm not sure
Bas Nieuwenhuizen writes:
> Reviewed-by: Bas Nieuwenhuizen
>
> Thanks!
Thanks to you as well; I've rebased and pushed to master.
Two down, two to go (extensions that is)
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
Reviewed-by: Bas Nieuwenhuizen
Thanks!
On Thu, Jun 21, 2018 at 12:52 AM, Keith Packard wrote:
> This extension provides fences and frame count information to direct
> display contexts. It uses new kernel ioctls to provide 64-bits of
> vblank sequence and nanosecond resolution.
>
> v2:
>
Reuse code shared with mesa/main/texcompress_bptc.
v2: Use block decompress function
Signed-off-by: Denis Pauk
CC: Nicolai Hähnle
CC: Marek Olšák
CC: Gert Wollny
---
src/gallium/auxiliary/Makefile.sources | 2 +
src/gallium/auxiliary/meson.build| 2 +
src/gallium/auxili
v2: none
Signed-off-by: Denis Pauk
CC: Marek Olšák
CC: Rhys Perry
CC: Matt Turner
---
src/gallium/drivers/llvmpipe/lp_screen.c | 3 +--
src/gallium/drivers/llvmpipe/lp_test_format.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_sc
Make functions public:
* fetch_rgba_unorm_from_block
* fetch_rgb_float_from_block
* compress_rgba_unorm
* compress_rgb_float
Create decompress functions:
* decompress_rgba_unorm
* decompress_rgb_float
Functions will be reused in gallium/auxiliary code.
v2: Add block decompress function
Signed-o
v2: none
Signed-off-by: Denis Pauk
CC: Marek Olšák
CC: Rhys Perry
---
src/gallium/drivers/softpipe/sp_screen.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_screen.c
b/src/gallium/drivers/softpipe/sp_screen.c
index 8fbcbc8bac..ed8f8d9112
This series add code for reuse in gallium bptc decode logic from
mesa/main/texcompress_bptc.c.
Checked on x86_64 by:
* LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER={llvmpipe,softpipe}
* piglit/bin/bptc-float-modes
* piglit/bin/bptc-modes
* piglit/bin/compressedteximage GL_COMPRESSED_RGBA_BPTC_UNORM
https://bugs.freedesktop.org/show_bug.cgi?id=106980
Bas Nieuwenhuizen changed:
What|Removed |Added
CC|chadvers...@chromium.org, |
|dan...@fooishba
https://bugs.freedesktop.org/show_bug.cgi?id=106980
Jan Ziak <0xe2.0x9a.0...@gmail.com> changed:
What|Removed |Added
CC||0xe2.0x9a.0...@gmai
Whoops please ignore this patch it was sent by mistake.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
22 matches
Mail list logo
