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.
> ---
> src/intel/vulkan/anv_blorp.c | 225
I dropped a comment in patch 4 which may or may not be relevant and
then a couple nitpicks in patch 6 that you can take or ignore. Either
way, the series is:
Reviewed-by: Iago Toral Quiroga
On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> ---
> include/vulkan/vulkan.h |
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/anv_private.h | 3 +
> src/intel/vulkan/genX_cmd_buffer.c |
Hello Everyone,
at this moment I develop on freedesktop opencl. Current the mesa opencl
break clinfo to read the information from nvidia when mesa opencl is
available. There is no other graphic card plugged in.
The stable 18.3.1 it works.
Don't know how to analise this kind of problem.
On Fri, 2019-01-11 at 08:05 +0100, Iago Toral wrote:
> On Thu, 2019-01-10 at 13:18 -0600, Jason Ekstrand wrote:
> > Topi just asked me on IRC what I thought about handling 16-bit
> > booleans on Intel hardware in the light of the 1-bit boolean
> > stuff. The current state of the driver is that we
Thanks Marek, what would need to happen to get this enabled
again? Will simply reverting the commit that took it out work? If
so is there any chance of getting this put back officially or
would I have to manually compile the driver each release?
In particular
On Friday, 2019-01-11 10:58:38 +0100, 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,
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
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
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
On 11/01/2019 11:37, Eric Engestrom wrote:
On Friday, 2019-01-11 10:58:38 +0100, 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
On Fri, 2019-01-11 at 11:43 +, Lionel Landwerlin wrote:
> On 11/01/2019 11:37, Eric Engestrom wrote:
> > On Friday, 2019-01-11 10:58:38 +0100, 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
On 11/01/2019 11:41, Iago Toral wrote:
On Fri, 2019-01-11 at 11:13 +, Lionel Landwerlin wrote:
On 11/01/2019 10:50, Iago Toral Quiroga wrote:
Fixes: f6aa9f718516 'anv/pipeline_cache: Add support for caching
NIR'
---
src/intel/vulkan/anv_pipeline_cache.c | 5 +++--
1 file changed, 3
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
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
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
> ---
>
On Fri, 2019-01-11 at 11:13 +, Lionel Landwerlin wrote:
> On 11/01/2019 10:50, Iago Toral Quiroga wrote:
> > Fixes: f6aa9f718516 'anv/pipeline_cache: Add support for caching
> > NIR'
> > ---
> > src/intel/vulkan/anv_pipeline_cache.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2
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
---
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
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
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
Fixes: f6aa9f718516 'anv/pipeline_cache: Add support for caching NIR'
---
src/intel/vulkan/anv_pipeline_cache.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Or maybe just check cache->cache instead, which I guess was the original
intention, but I kind of prefer having all fields
On 11/01/2019 10:50, Iago Toral Quiroga wrote:
Fixes: f6aa9f718516 'anv/pipeline_cache: Add support for caching NIR'
---
src/intel/vulkan/anv_pipeline_cache.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Or maybe just check cache->cache instead, which I guess was the original
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
"
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
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.
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
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,
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
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
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 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
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
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
>
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 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
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
>> > >
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
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
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
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
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
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.
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
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
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
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
"&>" 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
"--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
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?
>
>
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
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
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
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
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
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
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:
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
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
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
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
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
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
> >
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
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
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 +++-
> >
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
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Kai changed:
What|Removed |Added
Depends on||109319
Referenced Bugs:
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
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
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
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
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=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 ...
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
>
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||109326
Referenced Bugs:
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
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
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
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 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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Alias||autotools-removal
--
You are receiving
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
>>
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 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
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Depends on||109325
Referenced Bugs:
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
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
> >
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 #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
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Depends on||109324
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Matt Turner changed:
What|Removed |Added
Alias|autotools-removal |mesa-autotools-removal
--
You are
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
https://bugs.freedesktop.org/show_bug.cgi?id=109324
Dylan Baker changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
> >
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
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
1 - 100 of 114 matches
Mail list logo
