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
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
https://bugs.freedesktop.org/show_bug.cgi?id=106980
Bas Nieuwenhuizen changed:
What|Removed |Added
CC|chadvers...@chromium.org, |
|dan...@fooishba
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
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
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
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:
>
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
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
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
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
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
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 +
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
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
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,
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.
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
22 matches
Mail list logo
