Reviewed-by: Samuel Pitoiset
On 02/23/2018 07:04 AM, Timothy Arceri wrote:
Lowering fpow in NIR rather than LLVM can be beneficial.
Polaris results:
Totals from affected shaders:
SGPRS: 124928 -> 124896 (-0.03 %)
VGPRS: 68616 -> 68332 (-0.41 %)
Spilled SGPRs: 394 -> 413 (4.82 %)
Spilled VGPRs
Normally, SIMD8 tessellation evaluation shaders operate on a single
patch, with each channel operating on a different vertex within the
patch. For patch primitives with fewer than 8 vertices, this means
that some of the channels are disabled, effectively wasting compute
power. This is a fairly co
This clones an existing CFG.
We can't properly copy the instruction lists from cfg_t itself, as
it's fs_inst/vec4_instruction agnostic, and we don't use templates.
To accomplish this, we pass in an instruction-list-copying function.
---
src/intel/compiler/brw_cfg.cpp | 41
alloc is about virtual registers, and grf_used is the number of actual
hardware registers used. alloc's information is not terribly useful
after register allocation, but there's no real use in conflating them.
I plan to generate two CFGs from a single fs_visitor invocation, each
representing a di
Less typing than ((uint64_t)1 << SYSTEM_VALUE_PRIMITIVE_ID).
---
src/compiler/shader_enums.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index ac83c65b30c..33a9d3d8a1d 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shad
https://bugs.freedesktop.org/show_bug.cgi?id=105207
--- Comment #4 from pritzl3...@gmail.com ---
I should note that I have not played Talos very often (since it hangs my
computer) so it might have worked fine at times. I just tried it now and then
and gave up for a month or 2 when I got a hang to
https://bugs.freedesktop.org/show_bug.cgi?id=104654
--- Comment #9 from Gert Wollny ---
@russianneuroman...@ya.ru
That's exactly the type of visual artefacts that I see when compute shaders are
disabled. In any case for this bug it is not important, I only wanted to see
whether this bug and [1]
Reviewed-by: Samuel Pitoiset
On 02/23/2018 06:42 AM, Timothy Arceri wrote:
---
src/amd/common/ac_nir_to_llvm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 50f3a4f69e..444107d14e 100644
--- a/
Reviewed-by: Samuel Pitoiset
On 02/23/2018 03:56 AM, Timothy Arceri wrote:
Seems to have not been used since 16be87c90429
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 6 --
src/gallium/auxiliary/tgsi/tgsi_scan.h | 1 -
2 files changed, 7 deletions(-)
diff --git a/src/gallium/auxiliary/
Kenneth Graunke writes:
> This clones an existing CFG.
>
> We can't properly copy the instruction lists from cfg_t itself, as
> it's fs_inst/vec4_instruction agnostic, and we don't use templates.
> To accomplish this, we pass in an instruction-list-copying function.
> ---
> src/intel/compiler/br
New features and changes:
- glxinfo now supports OpenGL 4.6
- glxinfo prints more OpenGL limits (GL 3.0 up to GL 4.6)
- glxinfo gained support for GL_ATI_meminfo and GL_NVX_gpu_memory_info
- eglinfo binary is now installed by `make install`
- Other misc changes (see below)
Bug fixes:
- es2gears_wa
On 22.02.2018 18:16, Thierry Reding wrote:
> On Thu, Feb 22, 2018 at 02:31:48PM +0100, Erik Faye-Lund wrote:
>> On Thu, Feb 22, 2018 at 2:23 PM, Thierry Reding
>> wrote:
>>> On Wed, Feb 21, 2018 at 05:01:02PM +, Emil Velikov wrote:
Hi Thierry,
On 21 February 2018 at 15:30, Thier
The surfaces that backup the GPU buffers have a boundary check that
considers that access to partial dwords are considered out-of-bounds.
For example is basic 16-bit cases of buffers with size 2 or 6 where the
last two bytes will always be read as 0 or its writting ignored.
The introduction of 16-
This series includes several fixes to allow enabling the VK_KHR_16bit_storage
features in ANV that have already landed but are currently disabled.
The series includes the following fixes:
* [1] Fixes issues in UBO/SSBO support when buffer size is not multiple
of 4. Patch adds a padding so
The introduction of 16-bit types with VK_KHR_16bit_storages implies that
push constant offsets could be multiple of 2-bytes. Some assertions are
relaxed so offsets can be multiple of 4-bytes or multiple of size of the
base type.
For 16-bit types, the push constant offset takes into account the
int
Restrict the use of untyped_surface_write with 16-bit pairs in
ssbo to the cases where we can guarantee that offset is multiple
of 4.
Taking into account that VK_KHR_relaxed_block_layout is available
in ANV we can only guarantee that when we have a constant offset
that is multiple of 4. For non co
Range in 16-bit push constants load was being calculated
wrongly using 4-bytes per element instead of 2-bytes as it
should be.
---
src/compiler/spirv/vtn_variables.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/spirv/vtn_variables.c
b/src/compiler/spirv/vtn_variables.c
ind
16-bit load_ubo/ssbo operations that call do_untyped_read_vector doesn't
guarantee that offsets are multiple of 4-bytes as required by untyped_read
message. This happens for example on 16-bit scalar arrays and in the case
of f16vec3 when then VK_KHR_relaxed_block_layoud is enabled.
Vectors reads w
Enables storageBuffer16BitAccess and uniformAndStorageBuffer16BitAccesss
features of VK_KHR_16bit_storage for Gen8+.
---
src/intel/vulkan/anv_device.c | 5 +++--
src/intel/vulkan/anv_extensions.py | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/anv_devi
Enables storagePushConstant16 features of VK_KHR_16bit_storage for Gen8+.
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index a7b586c79c..7c8b768c58 100644
--- a/src/intel/vulkan/a
Hi,
Could you also give dual & single shaders different names when dumping
them, e.g. something like the attached patch?
- Eero
On 23.02.2018 10:36, Kenneth Graunke wrote:
Normally, SIMD8 tessellation evaluation shaders operate on a single
patch, with each channel operating on a diffe
On Thu, 2018-02-22 at 11:22 -0800, Gustavo Lima Chaves wrote:
> v2:
> An attempt to support SpvExecutionModeStencilRefReplacingEXT's
> behavior
> also follows, with the interpretation to said mode being we prevent
> writes to the built-in FragStencilRefEXT variable when the execution
> mode isn't s
https://bugs.freedesktop.org/show_bug.cgi?id=104988
Andreas Boll changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105224
Bug ID: 105224
Summary: Webgl Pointclouds flickers
Product: Mesa
Version: 17.3
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: m
This still looks wrong, there's now two 4.3 sections:
4.3:
GL_MAX_ELEMENT_INDEX = 2147483647
GL_MAX_COMPUTE_UNIFORM_BLOCKS = 14
GL_MAX_COMPUTE_TEXTURE_IMAGE_UNITS = 32
GL_MAX_COMPUTE_IMAGE_UNIFORMS = 32
GL_MAX_COMPUTE_SHARED_MEMORY_SIZE = 65536
GL_MAX_COMPUTE_UNIFORM_COMP
https://bugs.freedesktop.org/show_bug.cgi?id=105224
--- Comment #1 from Augustin Trancart ---
I confirm downgrading to 17.2.8 solves the issue.
I should also mention that I'm on ubuntu using x-swat ppa, so the real version
numbers are 17.2.8-0ubuntu0~16.04.1 and 17.3.3-0ubuntu1~16.04.1
--
You
On 2018-02-22 — 10:41, Francisco Jerez wrote:
> Pierre Moreau writes:
>
> > Signed-off-by: Pierre Moreau
> > ---
> > src/gallium/state_trackers/clover/api/program.cpp | 39
> > +-
> > src/gallium/state_trackers/clover/core/program.cpp | 3 +-
> > 2 files changed, 25 inser
This is:
Reviewed-by: Andres Gomez
On Tue, 2018-02-20 at 18:03 +, Emil Velikov wrote:
> From: Emil Velikov
>
> LLVM requirement was bumped to 4.0.0 with earlier commit.
> Hence any code tailored for older versions is now unreachable.
>
> Cc: George Kyriazis
> Cc: Andres Gomez
> Signed-o
On 2018-02-22 — 11:00, Francisco Jerez wrote:
> Pierre Moreau writes:
>
> > Signed-off-by: Pierre Moreau
> > ---
> > .../state_trackers/clover/llvm/invocation.cpp | 26
> > ++
> > .../state_trackers/clover/llvm/invocation.hpp | 4
> > src/gallium/state_track
On 2018-02-22 — 11:04, Francisco Jerez wrote:
> Pierre Moreau writes:
>
> >> do we already have an upstream version of both dependencies we could
> >> just use? Or do we still need special branches?
> >
> > For both we can use the master branch of the upstream version. SPIRV-Tools
> > validator i
https://bugs.freedesktop.org/show_bug.cgi?id=105224
Michel Dänzer changed:
What|Removed |Added
Component|Mesa core |Drivers/DRI/i965
Assignee|mes
On Thu, 2018-02-22 at 22:48 +0100, Bas Nieuwenhuizen wrote:
> since IIRC the last change was also done due to Feral noticing and we
> are clearly lacking testcases in this area, can you check that that
> case still works for you? Thanks a lot!
I looked at an issue that was fixed with 5158603182fe7
In line with wayland-client and wayland-server, move the check for
wayland-protocols into the wayland platform branch.
Signed-off-by: Daniel Stone
Fixes: bfa22266cd4d ("vulkan/wsi/wayland: Add support for zwp_dmabuf")
Cc: Emil Velikov
Reported-by: Dieter Nützel
Bugzilla: https://bugs.freedeskto
autotools wants to have the BUILT_SOURCES ready as soon as it enters the
directory, even if they are not used. This meant the build failed if
wayland-protocols was not available on the system, even if it was not
enabled.
As BUILT_SOURCES cannot be used in a conditional (cf. 166852ee957f), do
the s
https://bugs.freedesktop.org/show_bug.cgi?id=105211
--- Comment #5 from Daniel Stone ---
Thanks both! Patches sent: https://patchwork.freedesktop.org/series/38853/
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev m
Also only check for wayland-scanner if building for the Wayland
platform.
Signed-off-by: Daniel Stone
Fixes: bfa22266cd4d ("vulkan/wsi/wayland: Add support for zwp_dmabuf")
Cc: Emil Velikov
Reported-by: Dieter Nützel
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105211
---
configure.a
https://bugs.freedesktop.org/show_bug.cgi?id=105208
--- Comment #3 from Marek Olšák ---
There is no need to disable 10bit support completely. We can add a workaround
into drirc for gnome-shell and mutter.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA C
Reviewed-by: Marek Olšák
Marek
On Fri, Feb 23, 2018 at 3:52 AM, Timothy Arceri wrote:
> Seems to have not been used since 16be87c90429
> ---
> src/gallium/auxiliary/tgsi/tgsi_scan.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.h
> b/src/gallium/
Reviewed-by: Marek Olšák
Marek
On Fri, Feb 23, 2018 at 7:04 AM, Timothy Arceri wrote:
> Lowering fpow in NIR rather than LLVM can be beneficial.
>
> Polaris results:
>
> Totals from affected shaders:
> SGPRS: 124928 -> 124896 (-0.03 %)
> VGPRS: 68616 -> 68332 (-0.41 %)
> Spilled SGPRs: 394 -> 4
Reviewed-by: Marek Olšák
Marek
On Fri, Feb 23, 2018 at 2:06 AM, Timothy Arceri wrote:
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c
> b/src/gallium/drivers/radeon
Reviewed-by: Marek Olšák
Marek
On Fri, Feb 23, 2018 at 2:06 AM, Timothy Arceri wrote:
> We were ignoring the channel offset.
> ---
> src/gallium/drivers/radeonsi/si_shader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c
> b/s
Please keep the extension exposed in GL compat. Eventually we want to
expose all extensions in GL compat.
st_init_limits is the proper place - please use that. While
st_init_limits doesn't have the API parameter, both of its call sites
have it, so it's just a matter of passing it to the function.
From: Daniel Schürmann
Signed-off-by: Daniel Schürmann
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_shader.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/src/amd/vulkan/radv_extensions.py
b/src/amd/vulkan/radv_extensions.py
index ac6ec8744e..c81f47d222 10064
From: Daniel Schürmann
Co-authored-by: Dave Airlie
Signed-off-by: Daniel Schürmann
---
src/amd/common/ac_nir_to_llvm.c | 28
1 file changed, 28 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 687157..1743c0bbe
From: Daniel Schürmann
Signed-off-by: Daniel Schürmann
---
src/compiler/nir/nir_lower_alu_to_scalar.c | 2 ++
src/compiler/nir/nir_opcodes.py| 28
2 files changed, 30 insertions(+)
diff --git a/src/compiler/nir/nir_lower_alu_to_scalar.c
b/src/compiler
From: Daniel Schürmann
Signed-off-by: Daniel Schürmann
---
src/compiler/spirv/GLSL.ext.AMD.h | 110 ++
1 file changed, 110 insertions(+)
create mode 100644 src/compiler/spirv/GLSL.ext.AMD.h
diff --git a/src/compiler/spirv/GLSL.ext.AMD.h
b/src/compiler/spir
From: Daniel Schürmann
Co-authored-by: Dave Airlie
Signed-off-by: Daniel Schürmann
---
src/compiler/nir/meson.build | 1 +
src/compiler/shader_info.h| 5
src/compiler/spirv/nir_spirv.h| 1 +
src/compiler/spirv/spirv_to_nir.c | 3 +++
src/compiler/spirv/vtn_amd.c
Hi,
Am Freitag, 23. Februar 2018, 10:10:41 CET schrieb Andreas Boll:
> New features and changes:
> - glxinfo now supports OpenGL 4.6
> - glxinfo prints more OpenGL limits (GL 3.0 up to GL 4.6)
> - glxinfo gained support for GL_ATI_meminfo and GL_NVX_gpu_memory_info
> - eglinfo binary is now instal
Reviewed-by: Bas Nieuwenhuizen
for the series.
On Fri, Feb 23, 2018 at 1:54 PM,
wrote:
> From: Daniel Schürmann
>
> Signed-off-by: Daniel Schürmann
> ---
> src/compiler/spirv/GLSL.ext.AMD.h | 110 ++
>
> 1 file changed, 110 insertions(+)
> create mode 1
---
src/intel/compiler/brw_disasm.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c
index 429ed78140..2def79f1d5 100644
--- a/src/intel/compiler/brw_disasm.c
+++ b/src/intel/compiler/brw_disasm.c
@@ -1676,6 +1676,10 @@ brw_d
New shader attribute to mark when a location has 16-bit
value. This patch includes support on mesa glsl and nir.
v2: Remove use of is_half_slot as is a duplicate of is_16bit
(Topi Pohjolainen)
Renamed half_inputs_read to inputs_read_16bit (Jason Ekstrand)
---
src/compiler/glsl_types.h
Hello,
This is a re-send with rebased V5 series with the implementation of
the storageInputOutput16 feature for VK_KHR_16bit_storage:
This serie including the related to SSBO/UBO/PushConstant
sent today is already available also at:
https://github.com/Igalia/mesa/tree/wip/VK_KHR_16bit_storage-rc
From: Alejandro Piñeiro
---
src/intel/compiler/brw_fs_visitor.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/intel/compiler/brw_fs_visitor.cpp
b/src/intel/compiler/brw_fs_visitor.cpp
index 7a5f6451f2..c3bc024095 100644
--- a/src/intel/compiler/brw_fs_visitor.cpp
+++ b/src/int
On SKL the render target write operations allow 16-bit format
output. This marks output registers as 16-bit using
BRW_REGISTER_TYPE_HF on the proper outputs target.
This allows to recognise when the data_format of 16-bit should be
enabled on render_target_write messages.
Signed-off-by: Jose Maria
Render Target Message's payloads for 16bit values fit in only one
register.
From Intel PRM vol07, page 249 "Render Target Messages" / "Message
Data Payloads"
"The half precision Render Target Write messages have data payloads
that can pack a full SIMD16 payload into 1 register instead of
From: Alejandro Piñeiro
From Vulkan 1.0.50 spec, Section 3.30.1. Format Definition:
VK_FORMAT_R16G16_SFLOAT
A two-component, 32-bit signed floating-point format that has a
16-bit R component in bytes 0..1, and a 16-bit G component in
bytes 2..3.
As vertex data and other inputs h
The VS load input for 16-bit values receives pairs of 16-bit values
packed in 32-bit values. Because of the adjusted format used at:
anv/pipeline: Use 32-bit surface formats for 16-bit formats
v2: Removed use of stride = 2 on 16-bit sources (Jason Ekstrand)
v3: Fix coding style and typo (Topi Po
From intel Skylake PRM, vol 07, section "EU Overview", subsection
"Send Message" (page 905):
"Bit 30: Data format. This field specifies the width of data read
from sampler or written to render target. Format = U1 0
Single Precision (32b), 1 Half Precision (16b)"
Also pr
Enables storageInputOutput16 feature of VK_KHR_16bit_storage
for Gen8+.
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 1756cf5324..c183ea8437 100644
--- a/src/intel/vulkan/anv
Includes the info about 16-bit vertex inputs coming from nir on brw VS
prog data, as we already do with 64-bit vertex input.
v2: Renamed half_inputs_read to inputs_read_16bit (Jason Ekstrand)
---
src/intel/compiler/brw_compiler.h | 1 +
src/intel/compiler/brw_vec4.cpp | 1 +
2 files changed, 2
Broadwell doesn't support half precisions data formats on render
target writes (RTW) messages. So the solution to write 16-bit outputs
is to use the conversion from 32-bit to 16-bit when writing 32-bit
values on a 16-bit format surface using formats like R16_FLOAT.
Half-precision outputs are conve
Enables the support of 16-bit types on load_input and
store_outputs intrinsics intra-stages.
The approach was based on re-using the 32-bit URB read
and writes between stages, shuffling pairs of 16-bit values into
32-bit values at load_store intrinsic and un-shuffling the values
at load_inputs.
v2
Once the infrastruture to support Render Target Messages with 16-bit
payload is available, this patch enables it on SKL and CHV platforms.
Enabling it allows 16-bit payload that use half of the register on
SIMD16 and avoids the spurious conversion from 16-bit to 32-bit needed
on BDW, just to be co
From: Alejandro Piñeiro
As we are using 32-bit surface formats with 16-bit elements we can be
on a situation where a vertex element can poke over the buffer by 2
bytes. To avoid that we add a padding when flushing the state.
This is similar to what the i965 drivers prior to Haswell do, as they
u
From: Thierry Reding
The disk cache implementation uses 64-bit atomic operations. For some
architectures, such as 32-bit ARM, GCC will not be able to translate
these operations into lock-free instructions and will instead rely on
the external atomics library to provide these operations.
Check at
Hi folks,
The following patch is from Timothy Arceri, I have just fixed the
not equal case locally. So, we are lucky this time because the fix was
already on the list :).
It fixes one important rendering issue [1], though we still have two
different issues to address. I have a local workaround fo
Original patch from Timothy Arceri, I have just fixed the
not equal case locally.
This fixes one important rendering issue in Wolfenstein 2
(the cutscene transition issue).
RadeonSI uses the same ordered comparisons, so I guess that
what we should do as well.
Bugzilla: https://bugs.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=104302
--- Comment #3 from Samuel Pitoiset ---
Hi,
This should fix the "cutscene" issue
https://patchwork.freedesktop.org/patch/206486/ .
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=104302
--- Comment #4 from Samuel Pitoiset ---
Created attachment 137556
--> https://bugs.freedesktop.org/attachment.cgi?id=137556&action=edit
workaround for the shoot issue
Also, if you want to get rid of the "shoot" issue temporarily, you might wa
On Thu, Feb 15, 2018 at 8:54 AM, Connor Abbott wrote:
> On Wed, Feb 14, 2018 at 11:53 PM, Timothy Arceri
> wrote:
> >
> >
> > On 15/02/18 04:39, Marek Olšák wrote:
> >>
> >> Reviewed-by: Marek Olšák
> >>
> >> Marek
> >>
> >> On Wed, Feb 14, 2018 at 7:29 AM, Timothy Arceri
> >> wrote:
> >>>
> >
Hi Dylan,
On 20 February 2018 at 18:36, Dylan Baker wrote:
> Currently meson will generate a pkg-config that links to EGL_mesa (or
> GLX_mesa), but this isn't correct, it should always link to EGL or GL.
> Probably the "right" solution is to have glvnd itself provide the pkg
> config files for GL
Hi Marc,
On 23 February 2018 at 12:58, Marc Dietrich wrote:
> my system has problems with linking xdemos:
> ...
> CCLD glsync
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
> glsync.o: undefined reference to symbol 'glXQueryExtensionsString'
> /usr/lib64/libGL.
On Thu, Feb 22, 2018 at 02:32:26PM +, Emil Velikov wrote:
> On 22 February 2018 at 13:23, Thierry Reding wrote:
[...]
> > Good point. Let me check what exactly we use in the closed-source driver
> > and then come up with a proposal.
> >
> > I think perhaps a good choice for the vendor would be
The series is:
Reviewed-by: Plamena Manolova
On Wed, Feb 14, 2018 at 9:18 PM, Francisco Jerez
wrote:
> ---
> docs/relnotes/18.1.0.html| 2 ++
> src/mesa/main/extensions_table.h | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/docs/relnotes/18.1.0.html b/docs/
Hello,
Trying to use opengl hardware acceleration on the Weston RDP backend I found
that the “has_llc” limitation on the “intel_readpixels_tiled_memcpy” fast path
was avoiding a fast intelPixelRead behavior. I’m using an Intel Bay Trail GEN7,
so a byt device family with 0x0F31 id (no llc, I gu
It's been 8 days since I posted this. Since there are no reviews, I
guess everybody is OK with this or doesn't care, so I can push this,
right?
Marek
On Thu, Feb 15, 2018 at 1:11 AM, Marek Olšák wrote:
> Hi,
>
> This is the second version of GL 3.1 compatibility support patches.
> There is also
Patch by "Ismail Doenmez"
https://bugzilla.suse.com/show_bug.cgi?id=1082307
---
configure.ac | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index 8a9172690a..a23eb844d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1032,6 +1032,7 @@ llvm_add_default_components(
Patch by "Tomas Chvatal" with modifications
by "Michal Srb" to not break python 2.
https://bugzilla.suse.com/show_bug.cgi?id=1082303
Signed-off-by: Stefan Dirsch
---
src/gallium/drivers/r600/egd_tables.py | 52 +-
1 file changed, 26 insertions(+), 26 deletions(-
Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed
formats that can render. When GetCompressed* functions are called, the
pixels are returned in the non-compressed format that is used for the
rendering.
With this patch we store both the compressed and non-compressed versions
o
Jordan - terribly sorry I got you into this mess :( Just drop the
st/mesa hunk and push the i965 change - I believe that's all reviewed
and tested.
Marek - feel free to rewrite it the way you suggest. This is something
that'll get reverted later, so I didn't want to mess about with
function signat
Hi,
Am Freitag, 23. Februar 2018, 14:31:30 CET schrieb Daniel Stone:
> Hi Dylan,
>
> On 20 February 2018 at 18:36, Dylan Baker wrote:
> > Currently meson will generate a pkg-config that links to EGL_mesa (or
> > GLX_mesa), but this isn't correct, it should always link to EGL or GL.
> > Probably
Hi Marc,
On 23 February 2018 at 15:42, Marc Dietrich wrote:
> Am Freitag, 23. Februar 2018, 14:31:30 CET schrieb Daniel Stone:
>> On 20 February 2018 at 18:36, Dylan Baker wrote:
>> > Currently meson will generate a pkg-config that links to EGL_mesa (or
>> > GLX_mesa), but this isn't correct, it
Reviewed-by: Marek Olšák
Marek
On Fri, Feb 23, 2018 at 2:21 PM, Samuel Pitoiset
wrote:
> Original patch from Timothy Arceri, I have just fixed the
> not equal case locally.
>
> This fixes one important rendering issue in Wolfenstein 2
> (the cutscene transition issue).
>
> RadeonSI uses the sam
Am Freitag, 23. Februar 2018, 16:57:18 CET schrieb Daniel Stone:
> Hi Marc,
>
> On 23 February 2018 at 15:42, Marc Dietrich wrote:
> > Am Freitag, 23. Februar 2018, 14:31:30 CET schrieb Daniel Stone:
> >> On 20 February 2018 at 18:36, Dylan Baker wrote:
> >> > Currently meson will generate a pkg
On Fri, Feb 23, 2018 at 1:26 AM, Jose Maria Casanova Crespo <
jmcasan...@igalia.com> wrote:
> The surfaces that backup the GPU buffers have a boundary check that
> considers that access to partial dwords are considered out-of-bounds.
> For example is basic 16-bit cases of buffers with size 2 or 6
On 02/23/2018 03:06 AM, Mike Lothian wrote:
This still looks wrong, there's now two 4.3 sections:
Yeah, but I guess I don't see it as a big deal. Fixing it would involve
a bit of a hack. While processing the big list of queries, I'd have to
check for extension=="4.3" and call a function to
On 02/23/2018 07:39 AM, Marek Olšák wrote:
It's been 8 days since I posted this. Since there are no reviews, I
guess everybody is OK with this or doesn't care, so I can push this,
right?
Series LGTM. Reviewed-by: Brian Paul
Marek
On Thu, Feb 15, 2018 at 1:11 AM, Marek Olšák wrote:
Hi,
Inspired-by: a similar patch for libdrm by Heiko Becker
Signed-off-by: Eric Engestrom
---
configure.ac | 1 +
meson.build | 3 +++
src/egl/egl-symbols-check | 2 +-
src/egl/meson.build
On 23 February 2018 at 13:55, Thierry Reding wrote:
> On Thu, Feb 22, 2018 at 02:32:26PM +, Emil Velikov wrote:
>> On 22 February 2018 at 13:23, Thierry Reding
>> wrote:
> [...]
>> > Good point. Let me check what exactly we use in the closed-source driver
>> > and then come up with a proposa
On 23 February 2018 at 16:04, Marc Dietrich wrote:
> Am Freitag, 23. Februar 2018, 16:57:18 CET schrieb Daniel Stone:
>> Hi Marc,
>>
>> On 23 February 2018 at 15:42, Marc Dietrich wrote:
>> > Am Freitag, 23. Februar 2018, 14:31:30 CET schrieb Daniel Stone:
>> >> On 20 February 2018 at 18:36, Dyla
On 23 February 2018 at 17:04, Eric Engestrom wrote:
> Inspired-by: a similar patch for libdrm by Heiko Becker
> Signed-off-by: Eric Engestrom
Reviewed-by: Emil Velikov
I'll port the wayland-egl bits to the wayland repo in a second.
Thanks
Emil
___
m
Jason Ekstrand writes:
> There is a potential race between the __sync_fetch_and_add and the
> futex_wake where another thread could come in and start waiting. If we
> hit this case, the other thread will never get woken back up because the
> futex_wake doesn't get called. We can fix this by cal
On Fri, Feb 23, 2018 at 1:40 AM, Iago Toral wrote:
> On Thu, 2018-02-22 at 11:22 -0800, Gustavo Lima Chaves wrote:
> > v2:
> > An attempt to support SpvExecutionModeStencilRefReplacingEXT's
> > behavior
> > also follows, with the interpretation to said mode being we prevent
> > writes to the buil
Ilia Mirkin writes:
> Jordan - terribly sorry I got you into this mess :( Just drop the
> st/mesa hunk and push the i965 change - I believe that's all reviewed
> and tested.
The patch with just the i965 hunk is:
Reviewed-by: Scott D Phillips
___
mesa
On Fri, Feb 23, 2018 at 8:30 AM, Bas Nieuwenhuizen wrote:
>
>
> On Thu, Feb 15, 2018 at 8:54 AM, Connor Abbott wrote:
>>
>> On Wed, Feb 14, 2018 at 11:53 PM, Timothy Arceri
>> wrote:
>> >
>> >
>> > On 15/02/18 04:39, Marek Olšák wrote:
>> >>
>> >> Reviewed-by: Marek Olšák
>> >>
>> >> Marek
>> >
On Fri, Feb 23, 2018 at 9:26 AM, Scott D Phillips <
scott.d.phill...@intel.com> wrote:
> Jason Ekstrand writes:
>
> > There is a potential race between the __sync_fetch_and_add and the
> > futex_wake where another thread could come in and start waiting. If we
> > hit this case, the other thread
Yes, this is the right ordering for NIR (and GLSL) comparisons.
Reviewed-by: Connor Abbott
On Fri, Feb 23, 2018 at 8:21 AM, Samuel Pitoiset
wrote:
> Original patch from Timothy Arceri, I have just fixed the
> not equal case locally.
>
> This fixes one important rendering issue in Wolfenstein 2
Hi Mathias,
On Thu, Feb 22, 2018 at 06:45:19AM +0100, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
Finally use an internal VAO to execute display list draws. Avoid
duplicate state validation for display list draws. Remove client arrays
previously used exclusively for display lists.
Hi,
On Friday, 23 February 2018 18:51:45 CET Clayton Craft wrote:
> This patch caused a new failure in our CI, details are in the bug I filed on
> fdo: https://bugs.freedesktop.org/show_bug.cgi?id=105229
Thanks for your information. I will take a look!
Mathias
Signed-off-by: Eric Engestrom
---
meson.build | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/meson.build b/meson.build
index 2d474b140373292e49e7..28d068742ff914a623f6 100644
--- a/meson.build
+++ b/meson.build
@@ -303,16 +303,14 @@ if not (with_dri or with_g
1 - 100 of 223 matches
Mail list logo
