The original idea was that the backend compiler could eliminate
surfaces, so we would have it mark which ones are actually used,
then shrink the binding table accordingly. Unfortunately, it's a
pretty blunt mechanism - it can only prune things from the end,
not the middle - since we decide the lay
https://bugs.freedesktop.org/show_bug.cgi?id=99781
--- Comment #7 from Samuel Sieb ---
Of course, as soon as I write that and try again, it crashes every time even
limited to one cpu. I must have just been lucky that one time or something.
--
You are receiving this mail because:
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=99781
--- Comment #6 from Samuel Sieb ---
I can verify that limiting the program to one core allows it to start up.
--
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=109177
--- Comment #1 from MirceaKitsune ---
Created attachment 142918
--> https://bugs.freedesktop.org/attachment.cgi?id=142918&action=edit
Screenshot of the graphical corruption
A screenshot of the graphical corruption which can be observed moment
https://bugs.freedesktop.org/show_bug.cgi?id=109177
MirceaKitsune changed:
What|Removed |Added
Priority|medium |high
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=109177
Bug ID: 109177
Summary: Blender 2.8 triggers GPU lockup when entering Edit
Mode
Product: Mesa
Version: 18.3
Hardware: Other
OS: All
Status: NEW
Align16 is no longer a thing, so a new implementation is provided
using Align1 instead. Not all possible swizzles can be represented as
a single Align1 region, but some fast paths are provided for
frequently used swizzles that can be represented efficiently in Align1
mode.
Fixes ~90 subgroup quad
These are a number of fixes and clean-ups we've been carrying around
for a while in an internal branch. Most of the fixes are required for
conformance of a future platform, but due to their nature some of them
are likely to affect shipping platforms as well -- Especially the
issues addressed by pa
This legalization pass is meant to handle situations where the source
or destination regioning controls of an instruction are unsupported by
the hardware and need to be lowered away into separate instructions.
This should be more reliable and future-proof than the current
approach of handling CHV/B
This seems to be a problem in combination with the lower_regioning
pass introduced by a future commit, which can modify a SIMD-split
instruction causing its execution size to become illegal again. A
subsequent call to lower_simd_width() would hit this bug on a future
platform.
Cc: mesa-sta...@lis
I triggered this bug while prototyping code for a future platform on
IVB. Could be a problem today though if a strided move is
copy-propagated into a type-converting move with DF destination.
Cc: mesa-sta...@lists.freedesktop.org
---
src/intel/compiler/brw_eu_emit.c | 11 ---
1 file chan
Currently the visitor attempts to enforce the regioning restrictions
that apply to double-precision instructions on CHV/BXT at NIR-to-i965
translation time. It is possible though for the copy propagation pass
to violate this restriction if a strided move is propagated into one
of the affected inst
---
src/intel/compiler/brw_fs_builder.h | 68 +-
src/intel/compiler/brw_fs_nir.cpp | 89 +++--
2 files changed, 12 insertions(+), 145 deletions(-)
diff --git a/src/intel/compiler/brw_fs_builder.h
b/src/intel/compiler/brw_fs_builder.h
index 4846820722
lower_integer_multiplication() implements 32x32-bit multiplication on
some platforms by bit-casting one of the 32-bit sources into two
16-bit unsigned integer portions. This can give incorrect results if
the original instruction specified a source modifier. Fix it by
emitting an additional MOV in
These are broken on a future platform, but it turns out we don't need
to fix them, since they're just type-converting moves with strided
source. Kill them.
---
src/intel/compiler/brw_eu_defines.h | 2 --
src/intel/compiler/brw_fs.cpp | 2 --
src/intel/compiler/brw_fs.h
---
src/intel/compiler/brw_fs.cpp | 2 +-
src/intel/compiler/brw_ir_fs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 4aacc72a1b7..889509badab 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/c
It's redundant with the functionality provided by lower_regioning now.
---
src/intel/Makefile.sources| 1 -
src/intel/compiler/brw_fs.cpp | 1 -
src/intel/compiler/brw_fs.h | 1 -
.../compiler/brw_fs_lower_conversions.cpp | 132 --
On Sat, Dec 29, 2018 at 5:23 PM Jan Vesely wrote:
>
> On Wed, 2018-12-26 at 15:26 +, Eric Engestrom wrote:
> > On Tuesday, 2018-12-25 23:09:53 +0100, Jan Vesely wrote:
> > > Guess my meson-fu is still pretty weak.
> > > Now I see the build failure again:
> > > In file included from ../mesa/src
On Wed, 2018-12-26 at 15:26 +, Eric Engestrom wrote:
> On Tuesday, 2018-12-25 23:09:53 +0100, Jan Vesely wrote:
> > Guess my meson-fu is still pretty weak.
> > Now I see the build failure again:
> > In file included from ../mesa/src/intel/vulkan/anv_private.h:77:0,
> > from ../
On Sat, Dec 29, 2018 at 6:17 AM Mathias Fröhlich
wrote:
> In Emils patches building on top, _eglGetDRMDeviceRenderNode is only called
> from
> code paths guarded with HAVE_LIBDRM.
OK, so we could also guard the function's existence on HAVE_LIBDRM as
well. I think that's the most logical way forw
Hi all,
given what I see in Emils patches and in the assumption that this helps already
for haiku.
For both:
Reviewed-by: Mathias Fröhlich
best
Mathias
On Thursday, 27 December 2018 21:41:46 CET Alexander von Gluck IV wrote:
> ---
> src/egl/main/egldevice.c | 6 +-
> 1 file changed, 5 ins
Good morning,
On Thursday, 27 December 2018 21:59:47 CET Ilia Mirkin wrote:
> I don't see this function used anywhere... it's not exported either.
>
> It was added in dbb4457d9858fa977246aa5e9cabe83455022dfe by Emil as
> part of EGL_EXT_device_drm, but appears unused in that commit as well.
>
>
22 matches
Mail list logo
