It is still unreviewed.
Sam
On 2/8/19 8:17 AM, Samuel Iglesias Gonsálvez wrote:
> First three versions of this branch were sent for review to the mailing
> list. In order to avoid flooding the list with more emails, I create
> this MR to continue the review process there.
>
> Reminder: this
https://bugs.freedesktop.org/show_bug.cgi?id=109711
--- Comment #3 from root@scoopta.ninja ---
It turns out this issue only occurs under XWayland and NOT under X.Org however
I'm not sure if it's actually a mesa bug with XWayland or an XWayland bug
directly.
--
You are receiving this mail
Lionel, are you going to push it with this quote? I can add it
otherwise.
Sam
On Thu, 2019-02-21 at 13:41 +, Lionel Landwerlin wrote:
> On 21/02/2019 13:30, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-02-21 12:57:09)
> > > I did not find the PRM bit that says it must be 64b
OK now I understand, this hunk got added accidentially twice from 2
separate commits!
Reviewed-by: Tapani Pälli
On 2/22/19 7:50 AM, Tapani Pälli wrote:
Hi;
On 2/22/19 1:30 AM, Mauro Rossi wrote:
Fixes the following building error:
including ./external/mesa/Android.mk ...
Hi;
On 2/22/19 1:30 AM, Mauro Rossi wrote:
Fixes the following building error:
including ./external/mesa/Android.mk ...
build/core/base_rules.mk:183: *** external/mesa/src/intel:
MODULE.TARGET.STATIC_LIBRARIES.libmesa_isl_tiled_memcpy already defined by
external/mesa/src/intel.
make: ***
https://bugs.freedesktop.org/show_bug.cgi?id=109735
Shmerl changed:
What|Removed |Added
CC||shtetl...@gmail.com
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=109735
--- Comment #3 from Shmerl ---
Yep, I can confirm it renders OK with radv 18.3.2 / llvm 7.0.1, but font is
broken with radv in Mesa master / llvm 9.0
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=109739
--- Comment #1 from Shmerl ---
Another problem was that ninja install doesn't deploy actual layer .so file.
I did this in my build script:
DESTDIR="$dest_dir" LC_ALL=C.UTF-8 ninja install
It deployed VkLayer_MESA_overlay.json, but missed
https://bugs.freedesktop.org/show_bug.cgi?id=109739
Bug ID: 109739
Summary: Mesa build fails when vulkan-overlay-layer option is
enabled
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Fix the logic for buffer full check on alloc.
This patch just takes the fix Nicolai attached to the bug report
and updates it to work on master.
Fixes: e0f0d3675d4 ("radeonsi: factor si_query_buffer logic out of si_query_hw")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109561
---
https://bugs.freedesktop.org/show_bug.cgi?id=109735
--- Comment #2 from osch...@web.de ---
Created attachment 143436
--> https://bugs.freedesktop.org/attachment.cgi?id=143436=edit
bisect log
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=109735
--- Comment #1 from osch...@web.de ---
Created attachment 143435
--> https://bugs.freedesktop.org/attachment.cgi?id=143435=edit
screenshot
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=109735
Bug ID: 109735
Summary: [Regression] broken font with mesa_vulkan_overlay
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity:
On Thu, Feb 21, 2019 at 5:11 PM Connor Abbott wrote:
>
> On Thu, Feb 21, 2019 at 5:07 PM Alyssa Rosenzweig
> wrote:
>>
>> > Yes, there is a buffer for holding the results of the tiler. The way it
>> > works is that the userspace driver allocates a very large buffer with a
>> > "grow on page
Fixes the following building error:
including ./external/mesa/Android.mk ...
build/core/base_rules.mk:183: *** external/mesa/src/intel:
MODULE.TARGET.STATIC_LIBRARIES.libmesa_isl_tiled_memcpy already defined by
external/mesa/src/intel.
make: *** [build/core/ninja.mk:164:
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Bug 109535 depends on bug 109328, which changed state.
Bug 109328 Summary: [BSW BXT GLK] dEQP-VK.subgroups.arithmetic.subgroup
regressions
https://bugs.freedesktop.org/show_bug.cgi?id=109328
What|Removed
On Thu, Feb 21, 2019 at 12:02:58PM +0200, Eleni Maria Stea wrote:
> Calculating the scissor rectangle fields with the y flipped (0 on top)
> can generate negative values that will cause assertion failure later on
> as the scissor fields are all unsigned. We must clamp the bbox values
> again to
> I don't know about Midgard, but on Bifrost it definitely uses GROW_ON_GPF,
> telling the kernel to preallocate some small-ish initial set, presumably as
> an optimization. I don't think you can accurately predict how much memory
> you're going to need ahead of time, since it depends on how the
On Thu, Feb 21, 2019 at 5:07 PM Alyssa Rosenzweig
wrote:
> > Yes, there is a buffer for holding the results of the tiler. The way it
> > works is that the userspace driver allocates a very large buffer with a
> > "grow on page fault" bit, so the kernel will allocate more memory as the
> > tiler
https://bugs.freedesktop.org/show_bug.cgi?id=109711
--- Comment #2 from root@scoopta.ninja ---
Yeah, apparently I didn't make that very clear. It is a GAME hang. As in I have
to forcibly kill the game from htop but it is not a full system hang.
--
You are receiving this mail because:
You are
On Thursday, February 21, 2019 8:55:31 AM PST Jason Ekstrand wrote:
> Copy+paste error. It was supposed to test cull and not clip.
>
> Fixes: 4e69fba534e "nir: Rewrite lower_clip_cull_distance_arrays..."
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109717
> Cc: Kenneth Graunke
> ---
What happened to this patch? We carry it downstream for the deqp fix.
Can we get it into 19.0?
Thanks,
Kristian
On Wed, Aug 29, 2018 at 5:39 PM Lionel Landwerlin
wrote:
>
> The documentation puts the URB size for SKL GT1 as "128K - 192K". I
> guess this means we can't tell which one it is, so
On 21/02/2019 16:55, Jason Ekstrand wrote:
Copy+paste error. It was supposed to test cull and not clip.
Fixes: 4e69fba534e "nir: Rewrite lower_clip_cull_distance_arrays..."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109717
Cc: Kenneth Graunke
Trivial, I really thought it was
Copy+paste error. It was supposed to test cull and not clip.
Fixes: 4e69fba534e "nir: Rewrite lower_clip_cull_distance_arrays..."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109717
Cc: Kenneth Graunke
---
src/compiler/nir/nir_lower_clip_cull_distance_arrays.c | 2 +-
1 file changed,
On Thu, Feb 14, 2019 at 4:53 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > 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
On Thu, Feb 14, 2019 at 9:33 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > 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,
This MR cleans up some old cruft lying around in our back-end compiler
surrounding images.
The first three commits provide an enum for surface opcode sources and drop
the surface builder from the scalar back-end. Now that image format
lowering has moved to NIR and we have logical opcodes for HW
On Thu, Feb 21, 2019 at 11:09 AM Marek Olšák wrote:
>
> On Thu, Feb 21, 2019, 12:08 AM Ilia Mirkin wrote:
>>
>> I don't think that's right... this is used in e.g.
>>
>>case TGSI_OPCODE_RESQ:
>> if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File))
>>
On Thu, Feb 21, 2019, 12:08 AM Ilia Mirkin wrote:
> I don't think that's right... this is used in e.g.
>
>case TGSI_OPCODE_RESQ:
> if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File))
> info->uses_bindless_images = true;
> break;
>
> And if you call RESQ with
> Yes, there is a buffer for holding the results of the tiler. The way it
> works is that the userspace driver allocates a very large buffer with a
> "grow on page fault" bit, so the kernel will allocate more memory as the
> tiler asks for it.
To be clear, right now I have this magic misc_0
> *somewhere* the result of VS (or binning shader if VS is split in two)
> needs to be saved for use during the per-tile rendering. Presumably
> you have to give the hw a buffer of appropriate/matching size
> somewhere, or with enough geometry (and too small a buffer) things
> will overflow and
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #35 from asimiklit ---
Created attachment 143430
--> https://bugs.freedesktop.org/attachment.cgi?id=143430=edit
patch to disallow an elimination of the first unused ub/ssbo array elements
(In reply to Ian Romanick from comment
On Thu, Feb 21, 2019 at 3:01 PM Rob Clark wrote:
> On Thu, Feb 21, 2019 at 1:19 AM Alyssa Rosenzweig
> wrote:
> >
> > For reasons that are still unclear (speculation included in the comment
> > added in this patch), the tiler? metadata has a fast path that we were
> > not enabling; there looks
On Thu, Feb 21, 2019 at 3:45 AM Juan A. Suarez Romero
wrote:
> On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
> used to select between 8 bit subpixel precision (value 0) or 4 bit
> subpixel precision (value 1). As this value is not set, means it is
> taking the value 0,
Reviewed-by: Jason Ekstrand
On Thu, Feb 21, 2019 at 5:33 AM Thomas Helland
wrote:
> This patch is:
>
> Reviewed-by: Thomas Helland
>
> Den ons. 20. feb. 2019 kl. 04:04 skrev Timothy Arceri <
> tarc...@itsqueeze.com>:
> >
> > This reduces the time spent in nir_opt_cse() by almost a half.
> >
I've run the test with applied patch and it's successfully passed.
Also, this patch fixed an one issue from another ticket -
https://bugs.freedesktop.org/show_bug.cgi?id=109594 - with this patch,
totem app doesn't crashes at resizing
Thanks!
Tested-by: Paul Chelombitko
чт, 21 февр. 2019 г. в
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Bug 109535 depends on bug 109594, which changed state.
Bug 109594 Summary: totem assert failure: totem:
src/intel/genxml/gen9_pack.h:72: __gen_uint: La declaración `v <= max' no se
cumple.
https://bugs.freedesktop.org/show_bug.cgi?id=109594
https://bugs.freedesktop.org/show_bug.cgi?id=109535
Bug 109535 depends on bug 109594, which changed state.
Bug 109594 Summary: totem assert failure: totem:
src/intel/genxml/gen9_pack.h:72: __gen_uint: La declaración `v <= max' no se
cumple.
https://bugs.freedesktop.org/show_bug.cgi?id=109594
On 2019-02-19 10:58 a.m., Emil Velikov wrote:
> On Tue, 19 Feb 2019 at 03:32, Vinson Lee wrote:
>>CXXLDgallium_dri.la
>> duplicate symbol _compute_shader_video_buffer in:
>>
>> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
>>
>>
On Thu, Feb 21, 2019 at 1:19 AM Alyssa Rosenzweig wrote:
>
> For reasons that are still unclear (speculation included in the comment
> added in this patch), the tiler? metadata has a fast path that we were
> not enabling; there looks to be a possible time/memory tradeoff, but the
> details remain
On 21/02/2019 13:30, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-02-21 12:57:09)
I did not find the PRM bit that says it must be 64b aligned, but I can
see that's what i915 checks.
Chris: If you have a pointer to it, I could add the quote.
In amongst the register specs,
PLANE_STRIDE:
Quoting Lionel Landwerlin (2019-02-21 12:57:09)
> I did not find the PRM bit that says it must be 64b aligned, but I can
> see that's what i915 checks.
>
> Chris: If you have a pointer to it, I could add the quote.
In amongst the register specs,
PLANE_STRIDE:
For Linear memory, this field
I did not find the PRM bit that says it must be 64b aligned, but I can
see that's what i915 checks.
Chris: If you have a pointer to it, I could add the quote.
Thanks!
Reviewed-by: Lionel Landwerlin
On 19/02/2019 12:06, Samuel Iglesias Gonsálvez wrote:
Signed-off-by: Samuel Iglesias
Using the GPU has a cost, it implies preparing the RS/BLT request and
then possibly requires extra GPU -> CPU syncs, so let's only use
GPU-based tiling/untiling for rather big regions.
While at it, move the "should we use the GPU to tile/untile" logic to
its own function to make things more
https://bugs.freedesktop.org/show_bug.cgi?id=109532
--- Comment #34 from asimiklit ---
(In reply to asimiklit from comment #26)
> (In reply to Ian Romanick from comment #17)
> > (In reply to asimiklit from comment #6)
> > > Created attachment 143288 [details]
> > > this simple program helps me
Fixes: 3d7611e9 "st/nir: use NIR for asm programs"
---
src/mesa/program/prog_to_nir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
index 312b299361e..6e3fa9432a3 100644
--- a/src/mesa/program/prog_to_nir.c
Hi,
This series aims at optimizing updates of small regions inside a
texture. This is particularly useful when updating a texture atlas one
bit at a time.
Before going for this CPU-based tiling/untiling approach we tried
optimizing things by keeping track of all updates triggered by the
Noticed this while looking at recent commits.
I'm not familiar with the Mesa codebase so this might be incorrect,
but I don't see how this strdup'ed variable would be freed.
Matthias Lorenz (1):
Avoid leaking parameter name in prog_to_nir.
src/mesa/program/prog_to_nir.c | 3 ++-
1 file
Sometimes using CPU based untiling/tiling makes, like when updating
a really small region of the texture atlas which is not RS-aligned.
CPU-based support for simple tile layout was already supported, but
not the multi/super tile cases.
Make the etna_texture_[un]tile() more generic to support those
This patch is:
Reviewed-by: Thomas Helland
Den ons. 20. feb. 2019 kl. 04:04 skrev Timothy Arceri :
>
> This reduces the time spent in nir_opt_cse() by almost a half.
> ---
> src/compiler/nir/nir_opt_cse.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
CL#3532 added a test for alpha to coverage without a color attachment.
First the test draws a primitive with alpha 0 and a subpass with only
a depth buffer. No writes to a depth buffer are expected. Then a
second draw with a color buffer and the same depth buffer is done to
verify the depth buffer
https://bugs.freedesktop.org/show_bug.cgi?id=109698
--- Comment #2 from Emil Velikov ---
AFAICT there are two issues here.
1. the prefix wrongfully added to the custom variable
2. the custom variable can be a list of paths separated by colon, yet only the
first one ends up in dri.pc
Perhaps
Calculating the scissor rectangle fields with the y flipped (0 on top)
can generate negative values that will cause assertion failure later on
as the scissor fields are all unsigned. We must clamp the bbox values
again to make sure they don't exceed the fb_height. Also fixed a
calculation error.
Hi,
On Thu, Feb 21, 2019 at 10:35 AM Tapani Pälli
wrote:
> Hi;
>
> On 2/11/19 6:46 PM, Oscar Blumberg wrote:
> > apply_implicit_conversion only converts and check base types but we
> > need actual type equality for function returns, otherwise you can
> > return a vec2 from a function declared
On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.
On the other side, in the Vulkan CTS tests, if the
On 2/21/19 11:35 AM, Tapani Pälli wrote:
Hi;
On 2/11/19 6:46 PM, Oscar Blumberg wrote:
apply_implicit_conversion only converts and check base types but we
need actual type equality for function returns, otherwise you can
return a vec2 from a function declared as returning a float.
Do you
https://bugs.freedesktop.org/show_bug.cgi?id=109711
--- Comment #1 from Bas Nieuwenhuizen ---
So is this an actual hang of the GPU or just a freeze for the game? (i.e. does
it need a reboot to do anything again or can you just close the game?) Reading
the DXVK bug I'm wondering which of the two
Hi;
On 2/11/19 6:46 PM, Oscar Blumberg wrote:
apply_implicit_conversion only converts and check base types but we
need actual type equality for function returns, otherwise you can
return a vec2 from a function declared as returning a float.
Do you have some test shader that hits this
https://bugs.freedesktop.org/show_bug.cgi?id=109711
Bug ID: 109711
Summary: [DXVK] Skyrim Special edition hangs
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=109698
--- Comment #1 from Sergii Romantsov ---
Hello, Jeremy.
Looks like during meson configuration you are also using --prefix=/usr
So if at this moment as workaround option dri-drivers-path will exclude a
'prefix' from path it should work, like:
60 matches
Mail list logo
