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 follows:
CC nouveau_context.l
https://bugs.freedesktop.org/show_bug.cgi?id=106922
--- Comment #8 from Samuel Pitoiset ---
Thanks for checking. Apparently the corruption is Polaris specific. On vega it
works nice, if you have the hardware can you confirm?
--
You are receiving this mail because:
You are the QA Contact for the
Hi,
Thank you for the review.
On 9/15/18 2:15 AM, Timothy Arceri wrote:
Series:
Reviewed-by: Timothy Arceri
Are there piglit tests to go with this?
Yes, there is a test "[PATCH] glsl-1.10: add a
'initialization-incompatible-type-propagation' test":
https://patchwork.freedesktop.org/patch/2
And return a better error value.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107954
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 32 +---
src/amd/vulkan/radv_shader.c | 3 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_blit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_blit.c b/src/amd/vulkan/radv_meta_blit.c
index a205686e553..e7962911208 100644
--- a/src/amd/vulkan/radv_meta_blit.c
+++ b/src/am
https://bugs.freedesktop.org/show_bug.cgi?id=107954
--- Comment #1 from Samuel Pitoiset ---
Should be fixed with
https://patchwork.freedesktop.org/patch/249829/
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
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 one tiny one.
On Mon, Sep 17, 2018 at 4:18 AM Sam
https://bugs.freedesktop.org/show_bug.cgi?id=107954
--- Comment #2 from Jason Ekstrand ---
That's not the job of the driver. You should be running with validation layers
enabled while developing applications.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are t
Reviewed-by: Timothy Arceri
On 17/9/18 7:18 pm, Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_blit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_blit.c b/src/amd/vulkan/radv_meta_blit.c
index a2056
Reviewed-by: Timothy Arceri
On 17/9/18 7:18 pm, Samuel Pitoiset wrote:
And return a better error value.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107954
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 32 +---
src/amd/vulkan/radv
Reviewed-by: Bas Nieuwenhuizen
On Mon, Sep 17, 2018 at 11:18 AM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_blit.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_blit.c b/src/amd/vulkan/rad
Error of multiple definitions for libmesagallium and libmesautil may be
fixed by linker-option allow-multiple-definition
CC: Dylan Baker
Fixes: 8396043f304b (Replace uses of _mesa_bitcount with util_bitcount)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107923
Signed-off-by: Sergii Roma
https://bugs.freedesktop.org/show_bug.cgi?id=107923
--- Comment #6 from Sergii Romantsov ---
Proposed patch: https://patchwork.freedesktop.org/patch/249831/
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
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
https://bugs.freedesktop.org/show_bug.cgi?id=107923
Brad King changed:
What|Removed |Added
CC||brad.k...@kitware.com
--
You are receiving
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=106922
Samuel Pitoiset changed:
What|Removed |Added
Summary|Tangrams demo: LLVM ERROR: |radv: corruption issues
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
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
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 ++
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=107954
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
---
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
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
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._
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
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
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 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 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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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(+)
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 +
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
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
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
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 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
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
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
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
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=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.
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
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
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
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
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
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
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
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
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
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
'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
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
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
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: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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=107923
Dylan Baker changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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/
> 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
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
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
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,
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
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
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
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
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
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
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 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
1 - 100 of 113 matches
Mail list logo
