Instead of emitting all of the conditions for the cases of a switch
statement up-front, emit them on-the-fly as we emit the code for each
case. The original justification for this was that we were going to
have to build a default case anyway which would need them all. However,
we can just trust C
On Thu, Jan 3, 2019 at 2:40 PM Ian Romanick wrote:
> On 11/28/18 6:59 PM, Marek Olšák wrote:
> > From: Marek Olšák
> >
> > Tested by piglit.
>
> It doesn't look like there are any piglit test
>
> > ---
> > docs/features.txt | 2 +-
> > docs/relnotes/19.0.0.html
On Fri, Jan 11, 2019 at 8:50 PM Kenneth Graunke wrote:
>
> On Friday, January 11, 2019 9:32:20 AM PST Eric Anholt wrote:
> > Jason Ekstrand writes:
> >
> > > On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke
> > > wrote:
> > >
> > >> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote
On Fri, Jan 11, 2019 at 6:19 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> The bug caused that rgb565 framebuffers used argb1555.
>
> Fixes: 433ca3127a3b94bfe9a513e7c7ce594e09e1359f
> ---
> src/gallium/state_trackers/dri/dri2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
Reviewed-by: Kristian H. Kristensen
On Fri, Jan 11, 2019 at 3:19 PM Marek Olšák wrote:
>
> From: Marek Olšák
>
> The bug caused that rgb565 framebuffers used argb1555.
>
> Fixes: 433ca3127a3b94bfe9a513e7c7ce594e09e1359f
> ---
> src/gallium/state_trackers/dri/dri2.c | 2 +-
> 1 file changed, 1
On Fri, Jan 11, 2019 at 6:53 PM Marek Olšák wrote:
> From: Marek Olšák
>
> This fixes an assertion failure with GLCTX when cts-runner is used.
> (not a specific test)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108877
> Cc: 18.3
> ---
> .../drivers/radeonsi/si_state_viewport.c
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/106
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Marek Olšák
same as all other shaders
---
src/gallium/drivers/radeonsi/si_compute_blit.c | 14 ++
src/gallium/drivers/radeonsi/si_pipe.c | 8
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c
b/src/
From: Marek Olšák
---
.../drivers/radeonsi/si_shader_tgsi_mem.c | 25 +--
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 6decedc4cce..727def56f65 10064
From: Marek Olšák
This fixes an assertion failure with GLCTX when cts-runner is used.
(not a specific test)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108877
Cc: 18.3
---
.../drivers/radeonsi/si_state_viewport.c | 21 ---
1 file changed, 18 insertions(+), 3 de
From: Marek Olšák
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108877
Cc: 18.3
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_sta
From: Marek Olšák
---
src/amd/common/ac_llvm_build.c | 18 +-
.../drivers/radeonsi/si_shader_tgsi_mem.c | 4 ++--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 76047148a6
Quoting Ilia Mirkin (2019-01-11 14:43:26)
> On Fri, Jan 11, 2019 at 5:38 PM Matt Turner wrote:
> >
> > On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin wrote:
> > >
> > > On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
> > > >
> > > > From: Gert Wollny
> > > >
> > > > Since Meson will eventually
From: Marek Olšák
launch_grid calls it.
---
src/gallium/drivers/radeonsi/si_compute_blit.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c
b/src/gallium/drivers/radeonsi/si_compute_blit.c
index 086793637f0..11da04bed85 100644
--- a/src/gallium/d
https://bugs.freedesktop.org/show_bug.cgi?id=109138
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Marek Olšák
The bug caused that rgb565 framebuffers used argb1555.
Fixes: 433ca3127a3b94bfe9a513e7c7ce594e09e1359f
---
src/gallium/state_trackers/dri/dri2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_track
On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin wrote:
>
> On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
> >
> > From: Gert Wollny
> >
> > Since Meson will eventually be the only build system deprecate autotools
> > now. It can still be used by invoking configure with the flag
> > --enable-au
https://bugs.freedesktop.org/show_bug.cgi?id=109324
Dylan Baker changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Bug 109323 depends on bug 109324, which changed state.
Bug 109324 Summary: mesa: Need ability to reconfigure on upgrade of Meson
https://bugs.freedesktop.org/show_bug.cgi?id=109324
What|Removed |Added
-
On Fri, Jan 11, 2019 at 5:38 PM Matt Turner wrote:
>
> On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin wrote:
> >
> > On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
> > >
> > > From: Gert Wollny
> > >
> > > Since Meson will eventually be the only build system deprecate autotools
> > > now. It c
On Fri, Jan 11, 2019 at 2:28 PM Ilia Mirkin wrote:
>
> On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
> >
> > From: Gert Wollny
> >
> > Since Meson will eventually be the only build system deprecate autotools
> > now. It can still be used by invoking configure with the flag
> > --enable-au
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Alias|autotools-removal |mesa-autotools-removal
--
You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=109326
Bug ID: 109326
Summary: mesa: Meson configuration summary should be printed
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severi
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Depends on||109326
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=109325
Bug ID: 109325
Summary: mesa: Need ability to retrieve command line of Meson
configuration
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Depends on||109325
Referenced Bugs:
https://bugs.fr
On Fri, Jan 11, 2019 at 5:12 PM Matt Turner wrote:
>
> From: Gert Wollny
>
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
> --enable-autotools
>
> NAKed-by: Ilia Mirkin
[nouveau]
> Acked-by: Eric Enge
https://bugs.freedesktop.org/show_bug.cgi?id=109324
Bug ID: 109324
Summary: mesa: Need ability to reconfigure on upgrade of Meson
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Seve
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Depends on||109324
Referenced Bugs:
https://bugs.fr
On Fri, Jan 11, 2019 at 2:17 PM Jason Ekstrand wrote:
>
> On Fri, Jan 11, 2019 at 4:11 PM Matt Turner wrote:
>>
>> From: Gert Wollny
>>
>> Since Meson will eventually be the only build system deprecate autotools
>> now. It can still be used by invoking configure with the flag
>> --enable-autot
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Alias||autotools-removal
--
You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Bug ID: 109323
Summary: [TRACKER] mesa: Remove autotools
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
On Fri, Jan 11, 2019 at 4:11 PM Matt Turner wrote:
> From: Gert Wollny
>
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
> --enable-autotools
>
> NAKed-by: Ilia Mirkin
> Acked-by: Eric Engestrom
> Acke
From: Gert Wollny
Since Meson will eventually be the only build system deprecate autotools
now. It can still be used by invoking configure with the flag
--enable-autotools
NAKed-by: Ilia Mirkin
Acked-by: Eric Engestrom
Acked-by: Kenneth Graunke
Acked-by: Lionel Landwerlin
Acked-by: Jason E
https://bugs.freedesktop.org/show_bug.cgi?id=105371
--- Comment #20 from mirh ---
A couple of devs are working into reinventing the wheel so that you could
basically have r600 cards work and be supported almost like they had been
released in 2018 (well, sans vulkan)
And you have been already pro
Gert Wollny writes:
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
> --enable-autotools
>
> Signed-off-by: Gert Wollny
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
_
https://bugs.freedesktop.org/show_bug.cgi?id=105371
--- Comment #19 from amonpaike ---
is not there anyone who can give a view to what happens in what I reported in
the previous comment?
are these GPUs really old enough to be abandoned?
on windows blender on these gpu runs that is a beauty ...
i
A long time in a galaxy far far away, there was a GLSLang bug with how
it handled samplers passed in as function parameters. (The bug can be
found here: https://github.com/KhronosGroup/glslang/issues/179.)
Unfortunately, that version was shipped in several apps and has been
causing heartburn for o
It's an optimization so we should probably be calling it in the
optimization loop.
---
src/intel/compiler/brw_nir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 749c00ebcc6..92d7fe4bede 100644
--- a/src/intel/compiler/brw_nir
Instead of applying the workaround universally, detect semi-old GLSLang
via the generator ID and only enable the workaround on old GLSLang.
This isn't nearly as precise as one would like it to be because the
first GLSLang generator id version bump was on October 7, 2017 which is
about 1.5 years aft
From: Christian Gmeiner
A pipe_resource can be shared by all the pipe_context's hanging off the
same pipe_screen.
Signed-off-by: Christian Gmeiner
Signed-off-by: Marek Vasut
To: mesa-dev@lists.freedesktop.org
Cc: etna...@lists.freedesktop.org
---
Changes from v1 -> v2:
- to remove the resourc
On Fri, Jan 11, 2019 at 1:55 PM Kenneth Graunke
wrote:
> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> > I think I kind of like having "mem" be on external things. Shared is a
> > little weird there because it never leaves the chip so is it mem or
> shader?
>
> On Intel GPUs
On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> I think I kind of like having "mem" be on external things. Shared is a
> little weird there because it never leaves the chip so is it mem or shader?
On Intel GPUs, "shared" maps to a concept called "Shared Local Memory".
So I tend
On Fri, Jan 11, 2019 at 1:50 PM Kenneth Graunke
wrote:
> On Friday, January 11, 2019 9:32:20 AM PST Eric Anholt wrote:
> > Jason Ekstrand writes:
> >
> > > On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke <
> kenn...@whitecape.org>
> > > wrote:
> > >
> > >> On Friday, January 11, 2019 8:33:41 AM
On Friday, January 11, 2019 9:32:20 AM PST Eric Anholt wrote:
> Jason Ekstrand writes:
>
> > On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke
> > wrote:
> >
> >> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> >> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> >> >
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Kai changed:
What|Removed |Added
Depends on||109319
Referenced Bugs:
https://bugs.freedesktop
Am So., 16. Dez. 2018 um 12:24 Uhr schrieb Gert Wollny :
>
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
> --enable-autotools
>
> Signed-off-by: Gert Wollny
Reviewed-by: Christian Gmeiner
> ---
> IMO
Just a small convenience patch I had sitting here for a while.
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/104
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Jan 11, 2019 at 3:21 AM Iago Toral wrote:
> On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> > ---
> > src/intel/vulkan/anv_device.c | 28 ++
> > src/intel/vulkan/anv_extensions.py | 1 +
> > src/intel/vulkan/anv_pass.c| 37 +++-
> > src/intel/vulkan/an
On Fri, Jan 11, 2019 at 2:19 AM Iago Toral wrote:
> On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> > This function is modeled after the aux_op functions except that it
> > has a
> > lot more parameters because it deals with two images as well as
> > source
> > and destination regions.
This merge request, which I've marked WIP, is trying to push ANV in a more
modern direction. Whereas most other drivers have abandon binding tables
in favour of descriptor buffers, we've been holding on to binding tables
like our lives depended on it. This MR attempts to start moving us into
the
On Fri, Jan 11, 2019 at 9:11 AM Kenneth Graunke wrote:
>
> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> > > Those names (nir_var_func_local, nir_var_thread_local, and
> > > nir_var_thread_global) make more sense to m
On Fri, Jan 11, 2019 at 10:57:16AM -0600, Jason Ekstrand wrote:
> All,
>
> The mesa project has now hit 100 merge requests (36 are still open). I
> (and I'm sure others) would be curious to hear people's initial thoughts on
> the process. What's working well? What's not working? Is it total fa
I haven't played with merge requests yet, except for reviewing some
small RADV patches from Bas.
From my point of view, the main problem now is that we have to look
both at the mailing list and at the merge requests page and that's quite
annoying.
I don't think it's really a win to have two
On Fri, Jan 11, 2019 at 11:23 AM Danylo Piliaiev
wrote:
> My small thoughts/questions:
>
> - First of all discussions are really much more convenient.
> - Several (mine) merge requests were "Closed" and merged (not just merged,
> they are under "Closed" category), am I missing something?
>
It de
Jason Ekstrand writes:
> On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke
> wrote:
>
>> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
>> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
>> > > Those names (nir_var_func_local, nir_var_thread_local, and
>> > > nir_var_t
Quoting Jason Ekstrand (2019-01-11 09:05:21)
> I'm putting my own thoughts in a reply for some reason. Here's what I've
> seen.
>
> 1. I really like GitLab "discussions". It provides a very good way for both
> the author and the reviewers to keep track of what review comments have been
> dealt
On Fri, 11 Jan 2019 at 13:05, Tom Butler wrote:
> In particular I'm looking to get FSAA working in older games via wine, mostly
> they don't support antialiasing which is a shame because there's plenty of
> GPU power going to waste which could be fixing the jaggles. On nvidia
> __GL_FSAA_MODE w
My small thoughts/questions:
- First of all discussions are really much more convenient.
- Several (mine) merge requests were "Closed" and merged (not just
merged, they are under "Closed" category), am I missing something?
- Is there a way to grant rights to creator of merge request to
add/chan
On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke
wrote:
> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> > > Those names (nir_var_func_local, nir_var_thread_local, and
> > > nir_var_thread_global) make more sense to m
https://bugs.freedesktop.org/show_bug.cgi?id=106595
--- Comment #24 from Rhys Perry ---
I seem to be able to reproduce the problem (alpha-tested geometry not visible)
but only when Multi-sample Alpha-Test is enabled and WineD3D is used.
After disabling Multi-sample Alpha-Test or using DXVK, alpha
On Fri, Jan 11, 2019 at 9:13 AM Iago Toral Quiroga
wrote:
> We had defined MAX_IMAGES as 8, which we used to size the array for
> image push constant data. The comment there stated that this was for
> gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes
> that array, asserting tha
On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> > Those names (nir_var_func_local, nir_var_thread_local, and
> > nir_var_thread_global) make more sense to me than private/function.
> >
> > Another option is `nir_var_local_
I'm putting my own thoughts in a reply for some reason. Here's what I've
seen.
1. I really like GitLab "discussions". It provides a very good way for
both the author and the reviewers to keep track of what review comments
have been dealt with and what comments are still outstanding.
2. GitLab
All,
The mesa project has now hit 100 merge requests (36 are still open). I
(and I'm sure others) would be curious to hear people's initial thoughts on
the process. What's working well? What's not working? Is it total fail
and should we go back to mailing lists?
--Jason
__
"
On Fri, Jan 11, 2019 at 5:19 PM Kenneth Graunke wrote:
>
> On Wednesday, January 9, 2019 5:33:22 PM PST Ian Romanick wrote:
> > On 1/8/19 9:57 PM, Kenneth Graunke wrote:
> > > On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> > >> the naming is a bit confusing no matter how you
Feature to print out EGL returned configs for debug purposes.
'eglChooseConfig' and 'eglGetConfigs' debug information printout is
enabled when the log level equals '_EGL_DEBUG'. The configs are
printed, and if any of them are "chosen" they are marked with their
index in the chosen configs array.
This patch series provides an easy way to see what configs
have been returned by the 'eglGetConfigs' and 'eglChooseConfig'
functions, and give an overview of config attributes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedes
Being able to retrieve the log level can be useful to enable/disable
debug code. The alternative, which is calling 'getenv' function every
time to retrieve the log level, is more "expensive".
Signed-off-by: Silvestrs Timofejevs
Reviewed-by: Eric Engestrom
---
src/egl/main/egllog.c | 9 +
This function is similar to strncat, but unlike strncat it allows to
concatenate the buffer with a formatted string. The alternative would
be to have an intermediate string that is formated first, and then
appended via strncat.
v2:
revert accidentally introduced blank line removal
Signed-off-b
On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke
wrote:
> On Wednesday, January 9, 2019 5:33:22 PM PST Ian Romanick wrote:
> > On 1/8/19 9:57 PM, Kenneth Graunke wrote:
> > > On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> > >> the naming is a bit confusing no matter how you lo
On Wednesday, January 9, 2019 5:33:22 PM PST Ian Romanick wrote:
> On 1/8/19 9:57 PM, Kenneth Graunke wrote:
> > On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> >> the naming is a bit confusing no matter how you look at it. Within SPIR-V
> >> "global" memory is memory accessible
On 2019/01/11, Andres Gomez wrote:
> "--summary" will also print extended header information such as
> creations, renames and mode changes.
>
I might be missing some settings - cannot see any of those here.
Regardless, I have slight inclination towards --no-patch (as Eric
suggested) but either wa
On 2019/01/11, Andres Gomez wrote:
> "&>" is bash specific.
>
> Fixes: e0dbfc99537 ("bin/get-pick-list.sh: warn when commit lists invalid
> sha")
> Cc: Juan A. Suarez
> Cc: Eric Engestrom
> Cc: Dylan Baker
> Cc: Emil Velikov
Reviewed-by: Emil Velikov
Out of curiosity, are you using dash/mk
On Fri, 2019-01-11 at 15:22 +, Emil Velikov wrote:
> Hi Andres,
>
> On Fri, 11 Jan 2019 at 15:05, Andres Gomez wrote:
> >
> > I'll start with the 18.3.2 release process and keep with the the
> > following bugfix releases by now.
> >
>
> I was going through it earlier today and was going to
On Fri, 11 Jan 2019 at 15:22, Emil Velikov wrote:
>
> Hi Andres,
>
> On Fri, 11 Jan 2019 at 15:05, Andres Gomez wrote:
> >
> > I'll start with the 18.3.2 release process and keep with the the
> > following bugfix releases by now.
> >
> I was going through it earlier today and was going to send it
On Fri, 2019-01-11 at 15:24 +, Lionel Landwerlin wrote:
> On 11/01/2019 15:12, Iago Toral Quiroga wrote:
> > We had defined MAX_IMAGES as 8, which we used to size the array for
> > image push constant data. The comment there stated that this was
> > for
> > gen8, but anv_nir_apply_pipeline_layo
Hi Andres,
On Fri, 11 Jan 2019 at 15:05, Andres Gomez wrote:
>
> I'll start with the 18.3.2 release process and keep with the the
> following bugfix releases by now.
>
I was going through it earlier today and was going to send it out in
the next couple of hours.
For anyone wondering "lucky" me g
On 11/01/2019 15:12, Iago Toral Quiroga wrote:
We had defined MAX_IMAGES as 8, which we used to size the array for
image push constant data. The comment there stated that this was for
gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes
that array, asserting that we don't exceed t
We had defined MAX_IMAGES as 8, which we used to size the array for
image push constant data. The comment there stated that this was for
gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes
that array, asserting that we don't exceed that number of images,
which imposes a limit of MA
On Friday, 2019-01-11 16:43:27 +0200, Andres Gomez wrote:
> "&>" is bash specific.
>
> Fixes: e0dbfc99537 ("bin/get-pick-list.sh: warn when commit lists invalid
> sha")
> Cc: Juan A. Suarez
> Cc: Eric Engestrom
> Cc: Dylan Baker
> Cc: Emil Velikov
> Signed-off-by: Andres Gomez
Reviewed-by:
I'll start with the 18.3.2 release process and keep with the the
following bugfix releases by now.
On Mon, 2019-01-07 at 15:33 +0200, Andres Gomez wrote:
> Emil, the 18.3.2 should have already happened by the 19th of December.
>
> Is there anything stopping you from going ahead with it?
>
> I've
Hi Kevin,
Thanks for that massive undertaking in addressing this.
On 2019/01/04, Kevin Strasser wrote:
> The dri core api was written with the assumption that all attribute values
> would fit into 32 bits. This limitation means the config handlers can't
> accept 64 bpp formats. Reserve 64 bits fo
On Friday, 2019-01-11 16:42:25 +0200, Andres Gomez wrote:
> "--summary" will also print extended header information such as
> creations, renames and mode changes.
>
> Let's just use "-s", which suppresses the diff output.
>
> Fixes: 559c32d2412 ("bin/get-pick-list.sh: simplify git oneline printin
On Friday, 2019-01-11 14:20:38 +, Emil Velikov wrote:
> On Wed, 2 Jan 2019 at 13:48, Eric Engestrom wrote:
> >
> > On Thursday, 2018-12-27 20:41:47 +, Alexander von Gluck IV wrote:
> > > ---
> > > src/egl/drivers/haiku/egl_haiku.cpp | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deleti
"&>" is bash specific.
Fixes: e0dbfc99537 ("bin/get-pick-list.sh: warn when commit lists invalid sha")
Cc: Juan A. Suarez
Cc: Eric Engestrom
Cc: Dylan Baker
Cc: Emil Velikov
Signed-off-by: Andres Gomez
---
bin/get-pick-list.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
"--summary" will also print extended header information such as
creations, renames and mode changes.
Let's just use "-s", which suppresses the diff output.
Fixes: 559c32d2412 ("bin/get-pick-list.sh: simplify git oneline printing")
Cc: Juan A. Suarez
Cc: Eric Engestrom
Cc: Dylan Baker
Cc: Emil
On 2019/01/03, Eric Engestrom wrote:
> `gcc-ar` is preferred over the generic `ar`, and the `arm` family is
> for 32-bit ARM [1].
>
> [1] https://mesonbuild.com/Reference-tables.html#cpu-families
>
> Signed-off-by: Eric Engestrom
Nice. For the series
Reviewed-by: Emil Velikov
-Emil
___
On 2019/01/02, Eric Engestrom wrote:
> Fixes the following errors:
> usage: which [-as] program ...
> /Users/travis/.travis/job_stages: line 110: --version: command not found
>
> ... caused by the use of an undefined $LLVM_CONFIG
>
> Signed-off-by: Eric Engestrom
Reviewed-by: Emil Velikov
On Wed, 2 Jan 2019 at 13:48, Eric Engestrom wrote:
>
> On Thursday, 2018-12-27 20:41:47 +, Alexander von Gluck IV wrote:
> > ---
> > src/egl/drivers/haiku/egl_haiku.cpp | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/egl/drivers/haiku/egl_haiku.cpp
> > b/
On Sat, 29 Dec 2018 at 16:05, Ilia Mirkin wrote:
>
> 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
Hi Veluri,
On 2018/12/23, Veluri Mithun wrote:
> - Try to retrieve driver name from dri2_egl_display
>
I would add a note that GLVND based Mesa and GLVND itself aren't updated.
Might be a good idea to add an inline comment or two.
> Signed-off-by: Veluri Mithun
> ---
> docs/specs/EGL_MESA_quer
Acked-by: Marek Olšák
Marek
On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny wrote:
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
> --enable-autotools
>
> Signed-off-by: Gert Wollny
> ---
> IMO autotools
On 11/01/2019 12:40, Iago Toral wrote:
On Fri, 2019-01-11 at 12:31 +, Lionel Landwerlin wrote:
On 11/01/2019 12:12, Iago Toral Quiroga wrote:
We had defined MAX_IMAGES as 8, which we used to size the array for
image push constant data. The comment there stated that this was
for
gen8, but an
On Fri, 2019-01-11 at 12:31 +, Lionel Landwerlin wrote:
> On 11/01/2019 12:12, Iago Toral Quiroga wrote:
> > We had defined MAX_IMAGES as 8, which we used to size the array for
> > image push constant data. The comment there stated that this was
> > for
> > gen8, but anv_nir_apply_pipeline_layo
On 11/01/2019 12:12, Iago Toral Quiroga wrote:
We had defined MAX_IMAGES as 8, which we used to size the array for
image push constant data. The comment there stated that this was for
gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes
that array, asserting that we don't exceed t
On 11/01/2019 12:05, Iago Toral Quiroga wrote:
Fixes: f6aa9f718516 'anv/pipeline_cache: Add support for caching NIR'
Thanks a bunch :
Reviewed-by: Lionel Landwerlin
---
src/intel/vulkan/anv_pipeline_cache.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/intel/vulkan/an
We had defined MAX_IMAGES as 8, which we used to size the array for
image push constant data. The comment there stated that this was for
gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes
that array, asserting that we don't exceed that number of images,
which imposes a limit of MA
https://bugs.freedesktop.org/show_bug.cgi?id=109131
--- Comment #4 from Emil Velikov ---
AFAICT we probe if the compiler supports -std... before using it.
If somehow that's not the case we ought to fix that, or fallback to one that
owrks.
Patches welcome :-)
--
You are receiving this mail beca
Fixes: f6aa9f718516 'anv/pipeline_cache: Add support for caching NIR'
---
src/intel/vulkan/anv_pipeline_cache.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/intel/vulkan/anv_pipeline_cache.c
b/src/intel/vulkan/anv_pipeline_cache.c
index f9733c5309..d96102c287 100644
--- a/src/in
1 - 100 of 114 matches
Mail list logo
