Rb
On September 18, 2018 03:37:50 Caio Marcelo de Oliveira Filho
wrote:
Since commit 75881bed9e1 "i965: Rework the TCS passthrough shader to
use NIR." the created nir_shader is not dummy, and it is compiled by
the backend like the others.
---
src/mesa/drivers/dri/i965/brw_tcs.c | 4
1 fi
Good Morning,
On Tuesday, 18 September 2018 05:10:04 CEST Brian Paul wrote:
> The function pointer declarations in dd.h for the BufferData() and
> BufferSubData() use the ARB-suffixed datatypes. This patch changes
> the buffer_data_fallback() and buffer_sub_data_fallback() functions
> to use thos
Did you try --libdir /usr/lib/i386-linux-gnu ?
Marek
On Mon, Sep 17, 2018 at 11:02 PM, Brian Paul wrote:
> Hi Dylan,
>
> I have my 32-bit cross-compile working, but "ninja -C builddir install"
> isn't putting the 32-bit libs and drivers in the right place.
>
> I've been playing with the meson --
From: Marek Olšák
---
docs/features.txt | 57 +++
1 file changed, 57 insertions(+)
diff --git a/docs/features.txt b/docs/features.txt
index 9ccf803d470..a97f998a5cc 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -337,20 +337,77 @@ Khronos,
---
src/gallium/drivers/r300/r300_screen.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index a464cfb..19d3a1b 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.
Add ir_intrinsic_begin_fragment_shader_ordering switch case to
silence warning
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index ffaaeff..5a7e25a 100644
-
The function pointer declarations in dd.h for the BufferData() and
BufferSubData() use the ARB-suffixed datatypes. This patch changes
the buffer_data_fallback() and buffer_sub_data_fallback() functions
to use those datatypes too.
This fixes a build warning when building 32-bit libraries. Evident
Hi Dylan,
I have my 32-bit cross-compile working, but "ninja -C builddir install"
isn't putting the 32-bit libs and drivers in the right place.
I've been playing with the meson --prefix option and the
-Ddri-drivers-path=foo option but haven't found the right incantation.
On Ubuntu, I want the
https://bugs.freedesktop.org/show_bug.cgi?id=107369
--- Comment #14 from infini...@pwned.gg ---
Did you get a chance to analyze my dump?
I filed a LLVM bug here https://bugs.llvm.org/show_bug.cgi?id=38979
Didn't yet get a chance to test it with LLVM 7 yet but I didn't manage to find
any related
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 29, 2018 at 8:19 PM, Timothy Arceri wrote:
> ---
> src/mesa/drivers/dri/radeon/radeon_screen.h | 13 +
> src/util/xmlpool/ca.po | 20
> src/util/xmlpool/de.po
It seems like a good idea since EXT_framebuffer_blit/multisample are
also exposed.
Reviewed-by: Marek Olšák
Marek
On Sat, Sep 8, 2018 at 12:20 AM, Timothy Arceri wrote:
> Since user defined names are not allowed in core profile
> we remove the allow_user_names bool and just check if
> we have
Same here. I'm working on updating our internal build scripts to use
Meson. Working through 32-bit cross compile issues now...
-Brian
On 09/17/2018 07:09 PM, Marek Olšák wrote:
> Other than the --with-sha1 thing, meson works for me.
>
> That said, we need some time to move our internal build
Reviewed-by: Marek Olšák
Marek
On Wed, Sep 12, 2018 at 7:02 AM, Erik Faye-Lund
wrote:
> If we update the program-state etc, we risk compiling needless shaders,
> which can cost quite a bit of performance.
>
> Signed-off-by: Erik Faye-Lund
> ---
> This was motivated by seeing an unexpected shad
Reviewed-by: Marek Olšák
Marek
On Thu, Sep 13, 2018 at 4:06 AM, Gert Wollny wrote:
> From: Gert Wollny
>
> Since blending will be disabled later for integer formats we have to
> consider that in the case of a mixed set of integer/non-integer format
> buffers blending must be handled on a per b
On Mon, Sep 17, 2018 at 5:50 PM Marek Olšák wrote:
>
> One missing feature is --with-sha1=. libcrypto has an unstable ABI and
> Steam uses it. For Mesa to work with Steam, libnettle has/had to be
> used instead.
We imported OpenBSD's sha1 implementation a year and a half ago to
avoid all of that.
For the series:
Reviewed-by: Marek Olšák
Marek
On Tue, Sep 11, 2018 at 8:52 PM, Timothy Arceri wrote:
> This game is looking for some odd extension after creating a core
> context such as ARB_vertex_program and EXT_framebuffer_object.
>
> Rather then enabling these in core this forces the game
Reviewed-by: Marek Olšák
Marek
On Wed, Sep 12, 2018 at 6:50 AM, Timothy Arceri wrote:
> This reverts commit bc65dcab3bc48673ff6180afb036561a4b8b1119.
>
> This was manually reverted. Reverting stops the menu hanging in
> some id tech games such as RAGE and Wolfenstein The New Order.
>
> Bugzilla
Since commit 75881bed9e1 "i965: Rework the TCS passthrough shader to
use NIR." the created nir_shader is not dummy, and it is compiled by
the backend like the others.
---
src/mesa/drivers/dri/i965/brw_tcs.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tcs.c
Other than the --with-sha1 thing, meson works for me.
That said, we need some time to move our internal builds to meson and
there is a tiny chance that we'll discover some issues.
Removing autotools after 18.3 would be preferable.
Thanks,
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker w
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that autotools can do that meson cannot (that we actually want
One missing feature is --with-sha1=. libcrypto has an unstable ABI and
Steam uses it. For Mesa to work with Steam, libnettle has/had to be
used instead.
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can
https://bugs.freedesktop.org/show_bug.cgi?id=107965
Bug ID: 107965
Summary: kmscube: video cube not working: i965_dri.so does not
support the 0x PCI ID and segfaulting
Product: Mesa
Version: git
Hardware: x86-64 (AM
By the way, apparently VC4 has this restriction as well. Eric Anholt
covered more primitives in his logic, but also skipped trifans:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/vc4/vc4_draw.c#n431
I think it's worth copying some of that in here, or if you're feeling
generous,
From: Christoph Haag
---
meson.build | 4
meson_options.txt | 6 ++
2 files changed, 10 insertions(+)
diff --git a/meson.build b/meson.build
index 0588ebf8e7a..5e250470ed1 100644
--- a/meson.build
+++ b/meson.build
@@ -1188,6 +1188,8 @@ else
_llvm_version = '>= 3.3.0'
endif
Thanks for all answers.
Small bug: src/gallium/winsys/sw is built even though I've not
selected any swrast driver.
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about de
> Quoting Marek Olšák (2018-09-17 14:25:36)
> > Where do I find default values for meson configure options?
> >
> > Thanks,
> > Marek
>
> The meson_options.txt file has the default options. A lot of them are
> unfortunately just "auto", which is the downside of having a single build
> system
> t
On Monday, September 10, 2018 4:23:31 PM PDT Anuj Phogat wrote:
> Different ICL SKUs have different URB sizes.
>
> Signed-off-by: Anuj Phogat
> ---
> src/intel/dev/gen_device_info.c | 43 ++---
> 1 file changed, 29 insertions(+), 14 deletions(-)
>
> diff --git a/src/
https://bugs.freedesktop.org/show_bug.cgi?id=107923
Dylan Baker changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tuesday, August 28, 2018 10:54:57 AM PDT Anuj Phogat wrote:
> h/w specification requires this bit to be always set.
>
> Suggested-by: Kenneth Graunke
> Signed-off-by: Anuj Phogat
> ---
> src/intel/genxml/gen11.xml| 5 +
> src/intel/vulkan/genX_state.c | 14 ++
> 2 files
On Tuesday, August 28, 2018 3:31:18 PM PDT Anuj Phogat wrote:
> h/w specification requires this bit to be always set.
>
> V2: Fix bit mask (Chris Wilson)
>
> Suggested-by: Kenneth Graunke
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/drivers/dri/i965/brw_defines.h | 4
> src/mesa/dri
Quoting Marek Olšák (2018-09-17 15:11:37)
> 'meson configure' returns 'auto' for a lot of options. I'm interested
> in what meson chose.
For platforms, dri-drivers, gallium-drivers, and vulkan-drivers, glx, gbm, egl
it trys to pick and os + arch appropriate set, for the media state trackers,
valgr
On Mon, Sep 17, 2018 at 06:11:37PM -0400, Marek Olšák wrote:
> 'meson configure' returns 'auto' for a lot of options. I'm interested
> in what meson chose.
I see what you mean now, thanks for clarification. Even though meson
sets replacement values when it sees 'auto', it doesn't update the
optio
Quoting Marek Olšák (2018-09-17 15:14:11)
> How do I build 32-bit Mesa with meson?
>
> Thanks,
> Marek
>
Some people get away with just adding CFLAGs=-m32, but using a cross file and
doing a cross build is a better way, and is basically required if you want llvm.
Here's mine: https://gitlab.free
How do I build 32-bit Mesa with meson?
Thanks,
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that auto
'meson configure' returns 'auto' for a lot of options. I'm interested
in what meson chose.
Marek
On Mon, Sep 17, 2018 at 6:09 PM, Caio Marcelo de Oliveira Filho
wrote:
> On Mon, Sep 17, 2018 at 05:18:52PM -0400, Marek Olšák wrote:
>> If I configure meson, how can I know which state trackers, API
On Mon, Sep 17, 2018 at 05:18:52PM -0400, Marek Olšák wrote:
> If I configure meson, how can I know which state trackers, APIs, and
> backends are enabled?
'meson configure' in the build directory gives you that information
(at least some of it). That might give you some information. Part of
the
On Mon, Sep 17, 2018 at 05:30:22PM -0400, Marek Olšák wrote:
> Is there any documentation for configure options? Or do I have to do
> "grep get_option meson.build" to get the list at least?
The options are fully described in meson_options.txt file.
'meson configure' in a build directory will pret
Hi Marek, I've compressed the questions that Daniel didn't answer into one email
and tried to answer them. Hopefully this helps.
Quoting Marek Olšák (2018-09-17 14:07:30)
> I don't see radeonsi_dri.so. How/where is radeonsi_dri.so created?
radeonsi_dri is created like all of the mega drivers by s
Hi,
On Mon, 17 Sep 2018 at 22:31, Marek Olšák wrote:
> Is there any documentation for configure options? Or do I have to do
> "grep get_option meson.build" to get the list at least?
Most of these questions can be answered by running:
meson configure $builddir
More documentation is available a
Is there any documentation for configure options? Or do I have to do
"grep get_option meson.build" to get the list at least?
Thanks,
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the di
Where do I find default values for meson configure options?
Thanks,
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is
> there
> an
What's the rationale for enabling glx-tls by default without the
option to change it?
Thanks,
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools b
If I configure meson, how can I know which state trackers, APIs, and
backends are enabled?
Thanks,
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autoto
I don't see radeonsi_dri.so. How/where is radeonsi_dri.so created?
Thanks,
Marek
On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is
> the
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #10 from Axel Davy ---
Thanks.
The trace doesn't seem to have any particular issues. I guess the issue cannot
be captured with a trace.
I notice wine used to have similar issues (people recommended to switch to gdi
in the wine regis
https://bugs.freedesktop.org/show_bug.cgi?id=107698
--- Comment #6 from efeli...@yahoo.com ---
I reinstalled my desktop but I have the same results.
I triedamdgpu.dc=0 on the kernel command line but no results, I have black
screen.
It's working with kernel 4.17.* but not working with kernel 4.
In the GL_MESA_framebuffer_flip_y implementation
_mesa_is_winsys_fbo checks were replaced with
FlipY checks. rb->Name is also used to determine
if a buffer is winsys.
v2: Fixes annotation [for emil]
Fixes: ab05dd183cc ("i965: implement GL_MESA_framebuffer_flip_y [v3]")
---
src/mesa/drivers/dri/
https://bugs.freedesktop.org/show_bug.cgi?id=107391
--- Comment #3 from Samuel Pitoiset ---
This patch allows you to force anisotropy with RADV.
https://patchwork.freedesktop.org/patch/250317/
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
Ported from RadeonSI.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 46 +--
src/amd/vulkan/radv_private.h | 3 +++
2 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
ind
On Mon, Sep 17, 2018 at 2:22 PM, Jonathan Marek wrote:
> a20x can only draw 65535 vertices at once. this fix only applies to
> triangles.
>
> Signed-off-by: Jonathan Marek
> ---
> src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 30 +--
> 1 file changed, 28 insertions(+), 2 deleti
On Thu, Aug 23, 2018 at 11:01 AM Emil Velikov wrote:
>
> On Thu, 23 Aug 2018 at 18:41, Emil Velikov wrote:
> >
> > Hi Fritz,
> >
> > On Wed, 22 Aug 2018 at 23:01, Fritz Koenig wrote:
> > >
> > > In the GL_MESA_framebuffer_flip_y implementation
> > > _mesa_is_winsys_fbo checks were replaced with
Hello Dylan,
It looks fine to me as well. Thank you for fixing the merge conflict.
Pierre
On 2018-09-14 — 09:16, Dylan Baker wrote:
> Quoting Pierre Moreau (2017-12-04 15:51:04)
> > Those operations do not map to actual hardware instructions, therefore
> > those should always be lowered to 32-bi
on a20x the GPU will hang if this register is zero
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
b/src/gallium/drivers/freedreno/a2xx/fd2_emit.c
index dcb7b650
a20x can only draw 65535 vertices at once. this fix only applies to
triangles.
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 30 +--
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_draw.c
b
emulated fragcoord. a2xx has *some* hw support but it is not practical
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/a2xx/fd2_compiler.c| 16
1 file changed, 16 insertions(+)
diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_compiler.c
b/src/gallium/drivers
adds all the required logic for a20x hw binning to work
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/a2xx/fd2_draw.c | 95
src/gallium/drivers/freedreno/a2xx/fd2_emit.c | 10 +-
src/gallium/drivers/freedreno/a2xx/fd2_emit.h | 3 +-
src/gallium/drivers/free
writes to position export are mapped to a temp reg, code inserted at the
end of vertex shaders to export the position and compute the memory
exports for hw binning on a20x. C64 is the offset in the binning data,
C65/C66 are viewport parameters, C67+i/C68+i are binning view parameters.
C3+i is the b
this is for a2xx specific semantics (vertex id) and a basic SSA form
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/a2xx/fd2_compiler.c | 54 +--
src/gallium/drivers/freedreno/a2xx/ir-a2xx.c | 45 ++--
src/gallium/drivers/freedreno/a2xx/ir-a2xx.h | 9 +
this also adds a num_vsc_pipe which represents the number of pipes to use:
this value is useful because more pipes has a higher cost (on a20x)
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/freedreno_context.h | 1 +
.../drivers/freedreno/freedreno_gmem.c| 30 ++
this introduces some tracking of the number of vertices drawn in the
current batch: the draw command needs an offset to the start of the
binning data
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/adreno_pm4.xml.h| 7 +
.../drivers/freedreno/freedreno_batch.c | 1 +
Signed-off-by: Jonathan Marek
---
.../drivers/freedreno/freedreno_resource.c| 57 +--
.../drivers/freedreno/freedreno_resource.h| 1 +
.../drivers/freedreno/freedreno_screen.c | 29 +++---
.../drivers/freedreno/freedreno_screen.h | 10 ++--
.../freedreno/drm
the two a20x GPUs tested are a200 in the imx51 and the imx53 (not a205).
the 201 id is used for the imx51 (it only has 128kb gmem as opposed to the
typical 256kb for a200)
Signed-off-by: Jonathan Marek
---
src/gallium/drivers/freedreno/freedreno_screen.c | 2 ++
1 file changed, 2 insertions(+)
Signed-off-by: Jonathan Marek
---
configure.ac| 4 ++--
src/gallium/targets/dri/target.c| 5 +++-
src/gallium/winsys/imx/drm/Makefile.am | 9 +++
src/gallium/winsys/imx/drm/imx_drm_winsys.c | 26 -
4 files changed, 35 ins
On Mon, Sep 17, 2018 at 10:44 AM, Dylan Baker wrote:
> Currently gallium's xlib target will fail to link due to multiple
> definitions of all the symbols in libmesautil, this only shows up in
> autotools, and not in meson due to differences in the way that meson and
> autotools handle linking stat
Quoting Brian Paul (2018-09-17 10:54:01)
> On 09/17/2018 11:44 AM, Dylan Baker wrote:
> > Currently gallium's xlib target will fail to link due to multiple
> > definitions of all the symbols in libmesautil, this only shows up in
> > autotools, and not in meson due to differences in the way that mes
desOn Mon, 2018-09-17 at 10:11 -0700, Matt Turner wrote:
> On Mon, Sep 17, 2018 at 9:46 AM Dylan Baker
> wrote:
> >
> > I feel like for !windows meson is in good enough shape at this
> > point that we can start having the discussion about deleting the
> > autotools build.
> > So, is there anythin
On 09/17/2018 11:44 AM, Dylan Baker wrote:
Currently gallium's xlib target will fail to link due to multiple
definitions of all the symbols in libmesautil, this only shows up in
autotools, and not in meson due to differences in the way that meson and
autotools handle linking static archives into
Quoting Jan Vesely (2018-09-17 10:36:52)
> Hi,
>
> On Mon, 2018-09-17 at 09:44 -0700, Dylan Baker wrote:
> > I feel like for !windows meson is in good enough shape at this point that we
> > can start having the discussion about deleting the autotools build. So, is
> > there
> > anything left that
Currently gallium's xlib target will fail to link due to multiple
definitions of all the symbols in libmesautil, this only shows up in
autotools, and not in meson due to differences in the way that meson and
autotools handle linking static archives into static archives. Autotools
uses -Wl,--whole-a
Corrects building glx as gallium-xlib without any dri targets.
Fixes: 66c94b9313a697ce8f2b222f4ba353035e4b8726
("meson: build gallium winsys for dri, null, and wrapper")
---
src/gallium/auxiliary/pipe-loader/meson.build | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --g
Hi,
On Mon, 2018-09-17 at 09:44 -0700, Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that autotools can do that meson cannot (that we actually w
Quoting Eric Engestrom (2018-09-17 09:53:30)
>
>
> On September 17, 2018 4:16:12 PM UTC, Dylan Baker wrote:
> > I'm not crazy about this solution, it seems more like papering over a
> > bug than
> > fixing the bug. I'm really curious why we can reproduce this in
> > autotools but
> > not meson a
On Mon, Sep 17, 2018 at 9:46 AM Dylan Baker wrote:
>
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that autotools can do that meson cannot (that we actually want
Down with autotools!
On Mon, Sep 17, 2018 at 11:45 AM Dylan Baker wrote:
> I feel like for !windows meson is in good enough shape at this point that
> we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that autotools can do that meson cannot (
On September 17, 2018 4:16:12 PM UTC, Dylan Baker wrote:
> I'm not crazy about this solution, it seems more like papering over a
> bug than
> fixing the bug. I'm really curious why we can reproduce this in
> autotools but
> not meson as well.
Yeah, I have to agree with Dylan there, but then aga
I feel like for !windows meson is in good enough shape at this point that we
can start having the discussion about deleting the autotools build. So, is there
anything left that autotools can do that meson cannot (that we actually want to
implement)? And, what is a reasonable time-table to remove th
On 2018-09-15 3:04 a.m., Marek Olšák wrote:
> On Fri, Sep 14, 2018 at 4:53 AM, Michel Dänzer wrote:
>> On 2018-09-13 8:56 p.m., Marek Olšák wrote:
>>
>>> +* What happens if a driver is unloaded and the app creates a thread?
>>
>> I suppose the child process will likely crash, because the memor
NVC0_CB_AUX_BINDLESS_INFO isn't written to on Maxwell+ and it's too small
anyway.
With these changes, TXQ is used to determine the number of samples and
the coordinate adjustment information looked up in a small array in the
driver constant buffer.
v2: rework to use TXQ and a small array instead
I'm not crazy about this solution, it seems more like papering over a bug than
fixing the bug. I'm really curious why we can reproduce this in autotools but
not meson as well.
Dylan
Quoting Sergii Romantsov (2018-09-17 03:23:04)
> Error of multiple definitions for libmesagallium and libmesautil m
On Mon, Sep 17, 2018 at 10:08 AM Danylo Piliaiev
wrote:
>
>
> On 9/17/18 5:34 PM, Jason Ekstrand wrote:
>
> On Mon, Sep 17, 2018 at 8:34 AM Danylo Piliaiev
> wrote:
>
>> Hi Jason,
>>
>> I have implemented the extension and it works, however before sending the
>> patch I decided to see how it can
On Wed, 2018-09-12 at 14:30 +0200, Gert Wollny wrote:
> Am Mittwoch, den 12.09.2018, 01:24 +0300 schrieb Andres Gomez:
> > Gert, should we also include this in the stable queues ?
>
> Yes, Andres, that seems to make sense, thanks for checking back,
>
Added to the queue for the next release, on
On Mon, Sep 17, 2018 at 11:00 AM, Rhys Perry wrote:
> NVC0_CB_AUX_BINDLESS_INFO isn't written to on Maxwell+ and it's too small
> anyway.
>
> With these changes, TXQ is used to determine the number of samples and
> the coordinate adjustment information looked up in a small array in the
> driver co
On 9/17/18 5:34 PM, Jason Ekstrand wrote:
On Mon, Sep 17, 2018 at 8:34 AM Danylo Piliaiev
mailto:danylo.pilia...@gmail.com>> wrote:
Hi Jason,
I have implemented the extension and it works, however before
sending the patch I decided to see how it can interact with other
extens
NVC0_CB_AUX_BINDLESS_INFO isn't written to on Maxwell+ and it's too small
anyway.
With these changes, TXQ is used to determine the number of samples and
the coordinate adjustment information looked up in a small array in the
driver constant buffer.
v2: rework to use TXQ and a small array instead
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #9 from ilia ---
Done, here is is
https://drive.google.com/open?id=1tgPtchr2MNm1JG2vm-UoGmtkmmxCVyDT
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._
When we're about to re-arrange a bunch of blocks, it's a good idea to
make sure that we don't have deref uses crossing block boundaries.
Otherwise we may end up with a deref going through a phi and that would
be bad.
---
src/compiler/nir/nir_opt_loop_unroll.c | 13 -
1 file changed, 4
This pass re-materializes deref instructions on a per-block basis to
ensure that every use of a deref occurs in the same block as the
instruction which uses it.
---
src/compiler/nir/nir.h | 1 +
src/compiler/nir/nir_deref.c | 132 +++
2 files changed, 133 in
---
src/compiler/nir/nir_opt_if.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 5780ae3794b..0c94aa170b5 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -181,6
The lcssa and phis_to_regs passes are used by various NIR optimizations
that modify the CFG. Putting a couple of asserts will help ensure that
we don't accidentally put derefs in phis as part of an optimization
pass.
---
src/compiler/nir/nir_from_ssa.c | 2 ++
src/compiler/nir/nir_to_lcssa.c | 3
On 09/14/2018 07:55 PM, 杭中健 wrote:
Dear All,
I was trapped when compiling mesa-18.0.0 on Redhat el6.10(kernel:
2.6.32-754.el6.x86_64), and I don't how to fix it.
So I write this mail and asking for help, thanks in advance.
It seems OK during "configure", but fails during "make" and output as
https://bugs.freedesktop.org/show_bug.cgi?id=107954
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Sep 17, 2018 at 8:34 AM Danylo Piliaiev
wrote:
> Hi Jason,
>
> I have implemented the extension and it works, however before sending the
> patch I decided to see how it can interact with other extension -
> VK_EXT_conditional_render
> and got confused:
>
> From the spec it is not disallow
On 9/17/18 11:22 AM, Jason Ekstrand wrote:
It's not the job of the driver to check these things. Developers should
be running with validation layers enabled which are supposed to catch
this. There are so many other ways things can go wrong if the user
provides bad input and this only fixes
Only supported by GFX9+.
The conservativeraster Sascha demo seems to work as expected.
v2: fix when switching to DISABLED
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 14 +
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_pipeline.c| 49 ++
etna_resource_alloc and etna_resource_from_handle currently use different
checks.
This leads to
etna_resource_from_handle:492: target=2, format=PIPE_FORMAT_B8G8R8X8_UNORM,
1080x1920x1, array_size=1, last_level=0, nr_samples=0, usage=0, bind=8000a,
flags=0
etna_resource_from_handle:541: BO
Hi Jason,
I have implemented the extension and it works, however before sending
the patch I decided to see how it can interact with other extension -
VK_EXT_conditional_render
and got confused:
From the spec it is not disallowed to call functions of
VK_KHR_draw_indirect_count in conditional
https://bugs.freedesktop.org/show_bug.cgi?id=106922
Samuel Pitoiset changed:
What|Removed |Added
Summary|Tangrams demo: LLVM ERROR: |radv: corruption issues
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_blit.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_blit.c b/src/amd/vulkan/radv_meta_blit.c
index e796291120..ef690edb47 100644
--- a/src/amd/vulkan/radv
https://bugs.freedesktop.org/show_bug.cgi?id=107923
Brad King changed:
What|Removed |Added
CC||brad.k...@kitware.com
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=100960
--- Comment #10 from Sergii Romantsov ---
Thanks, Fabian.
That proves that Windows has a workaround for (0,0,0)-vector and treat it as
(1,0,0)-vector
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assig
1 - 100 of 113 matches
Mail list logo
