Since we haven't seen an onslaught of nominations we've decided to extend the
nomination period for another two weeks. Please consider nominating yourself or
anyone else you think would be a suitable candidate. This is your chance to
help steer the future of X.Org and serve the community.
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Mark Janes changed:
What|Removed |Added
Depends on|108787 |
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=108943
Dylan Baker changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On 2019-02-14 4:44 p.m., Marek Olšák wrote:
This still creates gfx shaders. If we switch MM to compute IBs, calling any gfx
function will crash.
Right now only fs_video_buffer/fs_weave_rgb/fs_rgba have compute shader
replacement.
The other gfx shader will be converted to compute shader later.
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Mark Janes changed:
What|Removed |Added
Blocks|107510 |
Depends on|
https://bugs.freedesktop.org/show_bug.cgi?id=107457
Mark Janes changed:
What|Removed |Added
Depends on|107510 |
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=109333
--- Comment #2 from Jan Vesely ---
(In reply to Dylan Baker from comment #1)
> I've submitted a PR to fix this here:
> https://github.com/mesonbuild/meson/pull/4931
thanks!
While PKG_CONFIG_PATH is enough for my usecase,
it might be useful to
On Thu, Feb 14, 2019 at 1:30 PM Jason Ekstrand wrote:
>
> On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez wrote:
>>
>> Strides up to 32B can be implemented for the source regions of most
>> instructions by leveraging either the vertical or the horizontal
>> stride of the hardware Align1 region.
On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
wrote:
> Because the "low" temporary needs to be accessed with word type and
> twice the original stride, attempting to preserve the alignment of the
> original destination can potentially lead to instructions with illegal
> destination stride
Jason Ekstrand writes:
> On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
> wrote:
>
>> Strides up to 32B can be implemented for the source regions of most
>> instructions by leveraging either the vertical or the horizontal
>> stride of the hardware Align1 region. The main motivation for this
On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
wrote:
> This is required in combination with the following commit, because
> otherwise if a source region with an extended 8+ stride is present in
> the instruction (which we're about to declare legal) we'll end up
> emitting code that attempts to
This still creates gfx shaders. If we switch MM to compute IBs, calling any
gfx function will crash.
Marek
On Tue, Feb 12, 2019, 2:53 PM Zhu, James Add compute shader initilization, assign and cleanup in vl_compositor API.
> Set video compositor compute shader render as default when pipe
On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
wrote:
> Strides up to 32B can be implemented for the source regions of most
> instructions by leveraging either the vertical or the horizontal
> stride of the hardware Align1 region. The main motivation for this is
> that currently the
On Thu, Feb 14, 2019 at 1:43 PM Dieter Nützel wrote:
> For the whole series (the updated branch merged in)
>
> Tested-by: Dieter Nützel
>
> on Polaris 20
>
> FreeCAD, Blender, UH, UV, US, some VTK apps
> No surprising speed up but e.g. NO slowdown.
>
> tb stands even for
> [Mesa-dev] [PATCH
Reviewed-by: Jason Ekstrand
On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
wrote:
> Even though the hardware spec claims that any "integer DWord multiply"
> operation is affected by the regioning restrictions of CHV/BXT/GLK,
> this is inconsistent with the behavior of the simulator and with
>
On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
wrote:
> Currently the execution type calculation will return a bogus value in
> cases like:
>
> mov_indirect(8) vgrf0:w, vgrf1:w, vgrf2:ud, 32u
>
> Which will be considered to have a 32-bit integer execution type even
> though the actual
On Wed, Feb 13, 2019 at 12:05:00PM +0200, Eleni Maria Stea wrote:
> For CopyImageSubData to copy the data during the 1st draw call, we need
> to update the shadow tree right before the rendering.
>
> v2:
> - Added assertion that the miptree doesn't need update at the time we
> update the
On Wed, Feb 13, 2019 at 12:04:59PM +0200, Eleni Maria Stea wrote:
> GPUs Gen < 8 cannot sample ETC2 formats. So far, they converted the
> compressed EAC/ETC2 images to non-compressed RGBA images. When
> GetCompressed* functions were called, the pixels were returned in this
> RGBA format and not
ping?
On Mon, Feb 4, 2019 at 3:37 PM Jason Ekstrand wrote:
> On Mon, Nov 5, 2018 at 8:58 PM Timothy Arceri
> wrote:
>
>> Once linking opts are done this pass recombines varying components.
>>
>> This patch is loosely based on Connor's vectorize alu pass.
>>
>> V2: skip fragment shaders
>>
>>
On Thu, Feb 14, 2019 at 1:18 PM Matt Turner wrote:
> On Mon, Feb 11, 2019 at 8:44 PM Jason Ekstrand
> wrote:
> >
> > This fixes a bug in runscape where we were optimizing x >> 16 to an
> > extract and then negating and converting to float. The NIR to fs pass
> > was dropping the negate on the
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Bug 109535 depends on bug 109582, which changed state.
Bug 109582 Summary: Performance regressions in Mesa 19.0.0-rc2
https://bugs.freedesktop.org/show_bug.cgi?id=109582
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Bug 109535 depends on bug 109609, which changed state.
Bug 109609 Summary: [SKL/CFL GT2] Up to 20% perf drop in Sacha Willems' Vulkan
Triangle demo
https://bugs.freedesktop.org/show_bug.cgi?id=109609
What|Removed
On Mon, Feb 11, 2019 at 8:44 PM Jason Ekstrand wrote:
>
> This fixes a bug in runscape where we were optimizing x >> 16 to an
> extract and then negating and converting to float. The NIR to fs pass
> was dropping the negate on the floor breaking a geometry shader and
> causing it to render
Tested-by: Dieter Nützel
running together with
[Mesa-dev] [PATCH 00/26] RadeonSI: Primitive culling with async compute
- V2
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215240.html
Dieter
Am 14.02.2019 02:37, schrieb Timothy Arceri:
This was probably useful when it was
On 12/02/2019 04:44, Jason Ekstrand wrote:
This fixes a bug in runscape where we were optimizing x >> 16 to an
extract and then negating and converting to float. The NIR to fs pass
was dropping the negate on the floor breaking a geometry shader and
causing it to render nothing.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=109323
--- Comment #2 from Dylan Baker ---
And I responded to the wrong bug. sigh
--
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109333
Dylan Baker changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Dylan Baker
https://bugs.freedesktop.org/show_bug.cgi?id=109323
Dylan Baker changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Dylan Baker
For the whole series (the updated branch merged in)
Tested-by: Dieter Nützel
on Polaris 20
FreeCAD, Blender, UH, UV, US, some VTK apps
No surprising speed up but e.g. NO slowdown.
tb stands even for
[Mesa-dev] [PATCH 0/4] RadeonSI: Follow-up for the primitive culling
series
too (but no SI,
Quoting Emil Velikov (2019-02-14 03:43:13)
> From: Emil Velikov
>
> Earlier commit introduced support for haiku yet did not properly
> annotate the loader/xmlconfig dependencies.
>
> Thus we ended up adding inc_loader for each !haiku platform - see
> 659910eda01 9a96bf0ecd0 731508b988
Thanks for the patch Ilia.
I had updated the utility function in gallium/aux for this pipe cap but not
internal to SWR.
Reviewed-by: Alok Hota
-Alok
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Ilia Mirkin
> Sent: Wednesday,
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Jason Ekstrand changed:
What|Removed |Added
Depends on|109517 |
Referenced Bugs:
Fixes all subgroup test failures in vulkancts on Icelake.
Series is:
Tested-by: Anuj Phogat
On Fri, Jan 18, 2019 at 4:09 PM Francisco Jerez wrote:
>
> Currently the execution type calculation will return a bogus value in
> cases like:
>
> mov_indirect(8) vgrf0:w, vgrf1:w, vgrf2:ud, 32u
>
>
On Thu, Feb 14, 2019 at 11:53 AM Erik Faye-Lund
wrote:
>
> On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote:
> > > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > > > tournier.e...@gmail.com> wrote:
> > [...]
> > > > > > A solution would be to inline the
> > > > > > function in
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Jason Ekstrand changed:
What|Removed |Added
Blocks||107510
Referenced Bugs:
On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote:
> > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > > tournier.e...@gmail.com> wrote:
> [...]
> > > > > A solution would be to inline the
> > > > > function in GLSL but I'm scared than the following shader
> > > > > will
> > > > >
On Thu, 14 Feb 2019 at 15:33, Eric Engestrom wrote:
>
> On Thursday, 2019-02-14 11:43:13 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Earlier commit introduced support for haiku yet did not properly
> > annotate the loader/xmlconfig dependencies.
> >
> > Thus we ended up adding
On Thursday, 2019-02-14 11:43:13 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Earlier commit introduced support for haiku yet did not properly
> annotate the loader/xmlconfig dependencies.
>
> Thus we ended up adding inc_loader for each !haiku platform - see
> 659910eda01 9a96bf0ecd0
> > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > tournier.e...@gmail.com> wrote:
> > > >
[...]
> > > > A solution would be to inline the
> > > > function in GLSL but I'm scared than the following shader will
> > > > be huge.
From my adventures in R600 Evergreen NIR land I can say
On Thu, Feb 14, 2019 at 10:00:17AM +0100, Daniel Vetter wrote:
> Clear rules avoid arguing.
>
> I think it'd be good to have an equally solid list on the kms side.
> But kms is much more meant to be a standard, and the list of userspace
> projects we've accepted in the past is constantly shifting
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #7 from tempel.jul...@gmail.com ---
I'll try to do that. I'd be grateful though if there also was a solution for
the missing shadows of small objects bug (initial bugreport), which hopefully
the renderdoc capture of the linked issue
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #6 from Samuel Pitoiset ---
Can you bisect? And eventually upload a renderdoc capture?
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #5 from tempel.jul...@gmail.com ---
A few days ago, it looked like in my first comment of this ticket (not perfect
due to the partially missing shadows, but bearable):
https://abload.de/img/screenshot_20190209_1sjj21.png
With one of
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #4 from Samuel Pitoiset ---
What do you mean?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 41 ++
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 3acf41728ac..867a13622f9 100644
---
It uses the new LLVM intrinsics.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 38 ++
src/amd/common/ac_llvm_build.h | 14 +
2 files changed, 52 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #3 from tempel.jul...@gmail.com ---
Created attachment 143379
--> https://bugs.freedesktop.org/attachment.cgi?id=143379=edit
broken hedges
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #2 from tempel.jul...@gmail.com ---
The hedges look quite awful with the latest git changes. :)
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
On 2/14/19 2:41 PM, Andres Gomez wrote:
On Thu, 2019-02-14 at 14:31 +0200, Tapani Pälli wrote:
LGTM
Reviewed-by: Tapani Pälli
Thanks for the review, Tapani ☺
On 2/12/19 2:17 PM, Andres Gomez wrote:
Instead of generating a GL_INVALID_ENUM error when the type or format
is incorrect
On Thu, 2019-02-14 at 14:31 +0200, Tapani Pälli wrote:
> LGTM
>
> Reviewed-by: Tapani Pälli
Thanks for the review, Tapani ☺
>
> On 2/12/19 2:17 PM, Andres Gomez wrote:
> > Instead of generating a GL_INVALID_ENUM error when the type or format
> > is incorrect while using
LGTM
Reviewed-by: Tapani Pälli
On 2/12/19 2:17 PM, Andres Gomez wrote:
Instead of generating a GL_INVALID_ENUM error when the type or format
is incorrect while using glClear{Named}Buffer{Sub}Data, generate
GL_INVALID_VALUE.
From page 72 (page 94 of the PDF) of the OpenGL 4.6 spec:
Not
If we hang the GPU and end up banning our context, we will no longer be
able to submit and abort with an error (exit(1) no less). As we submit
minimal incremental batches that rely on the logical context state of
previous batches, we can not rely on the kernel's recovery mechanism
which tries to
The kernel tries to repair a hanging context by restoring the default
state (or else we have discovered that the context may be unusably
corrupt by the reset). However, this is unsuitable for mesa as it
(rightfully) assumes that the context image contains the state it has
earlier set and so only
Object handles are local to the device fd, so double check we are not
mixing together objects from multiple screens on execbuf submission.
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Emil Velikov
Earlier commit introduced support for haiku yet did not properly
annotate the loader/xmlconfig dependencies.
Thus we ended up adding inc_loader for each !haiku platform - see
659910eda01 9a96bf0ecd0 731508b988 cec6cb01e216.
One piece remained though - the wayland platform.
On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote:
> On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote:
> > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > > > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > > > On
On Thu, 2019-02-14 at 08:53 +1000, Dave Airlie wrote:
> On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin
> wrote:
> > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > tournier.e...@gmail.com> wrote:
> > >
> > >
> > > On Wednesday, 13 February 2019, Stéphane Marchesin <
> > >
Clear rules avoid arguing.
I think it'd be good to have an equally solid list on the kms side.
But kms is much more meant to be a standard, and the list of userspace
projects we've accepted in the past is constantly shifting and
adjusting. So I figured I'll leave that as an exercise for later on.
58 matches
Mail list logo
