Also,
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107275
On Wed, Jul 18, 2018 at 9:16 PM Jason Ekstrand wrote:
> On Sat, Jul 14, 2018 at 4:26 PM Bas Nieuwenhuizen
> wrote:
>
>> Reinserting code directly before a jump means the block gets split
>> and merged, removing the original
On 19 July 2018 at 15:07, Dave Airlie wrote:
> On 2 July 2018 at 03:32, Gert Wollny wrote:
>> Below tests would fail with an error message
>> "Vertex format (R4G4B4A4|R5G5B5A1) not supported."
>> Add the formate to the translation routine to enable these formats.
>>
>> Fixes:
>>
On 2 July 2018 at 03:32, Gert Wollny wrote:
> Below tests would fail with an error message
> "Vertex format (R4G4B4A4|R5G5B5A1) not supported."
> Add the formate to the translation routine to enable these formats.
>
> Fixes:
>
On Thu, Jul 19, 2018 at 10:24 AM, Timothy Arceri wrote:
> On 19/07/18 12:02, Connor Abbott wrote:
>>
>> Why not do the more general thing, and evaluate the condition in every
>> block dominated by the then and else blocks? That should handle the
>> loop and non-loop cases.
>
>
> Can you explain
This is OK but the code also needs to compile with Visual C++.
Marek
On Wed, Jul 18, 2018 at 4:34 PM, David Riley wrote:
> Without this change, dlopen()/dlclose() of any driver results in memory
> being leaked which becomes problematic if things are being reinitialized
> repeatedly (eg from a
From: Dave Airlie
There might be a nicer way to do this, but this is at least correct.
This fixes:
KHR-GL44.tessellation_shader.single.max_patch_vertices
KHR-GL44.tessellation_shader.tessellation_control_to_tessellation_evaluation.gl_PatchVerticesIn
---
src/gallium/drivers/r600/r600_shader.c |
From: Marek Olšák
---
.../auxiliary/driver_trace/tr_dump_state.c| 1 +
src/gallium/auxiliary/postprocess/pp_mlaa.c | 2 +-
src/gallium/auxiliary/util/u_dump_state.c | 1 +
src/gallium/auxiliary/util/u_tests.c | 1 +
src/gallium/docs/source/screen.rst| 23
Hi,
This implements the Gallium part of EQAA. I'd rather get this merged
sooner than later because of the amount of trivial but vast changes in
Gallium.
Please review.
Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
From: Marek Olšák
---
src/gallium/docs/source/screen.rst | 11 +++
src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i915_screen.c | 1 +
From: Marek Olšák
Framebuffer without attachments now supports 16 samples.
---
src/gallium/drivers/radeonsi/si_state.c | 36 ++---
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
From: Marek Olšák
---
.../auxiliary/driver_ddebug/dd_screen.c | 3 ++-
src/gallium/auxiliary/driver_noop/noop_pipe.c | 4 ++-
.../auxiliary/driver_rbug/rbug_screen.c | 2 ++
.../auxiliary/driver_trace/tr_screen.c| 3 ++-
src/gallium/auxiliary/hud/font.c | 2
From: Marek Olšák
and use pipe_resource::nr_storage_samples instead of
r600_texture::num_color_samples.
---
src/amd/common/ac_surface.c | 6 +--
src/amd/common/ac_surface.h | 2 +-
src/amd/vulkan/radv_image.c | 2 +-
On Sat, Jul 14, 2018 at 4:26 PM Bas Nieuwenhuizen
wrote:
> Reinserting code directly before a jump means the block gets split
> and merged, removing the original block and replacing it in the
> process.
>
> Hence keeping a pointer to the continue block over a reinsert
> causes issues.
>
> This
https://bugs.freedesktop.org/show_bug.cgi?id=94747
--- Comment #4 from Timothy Arceri ---
(In reply to Ian Romanick from comment #3)
> (In reply to Timothy Arceri from comment #2)
> > As (In reply to Jason Ekstrand from comment #1)
> > > The code for this already exists. It's called
For simplicity we only allow this to work for scalar types.
---
src/compiler/nir/nir_search.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/src/compiler/nir/nir_search.c b/src/compiler/nir/nir_search.c
index 743ffdf232c..c0224ca4360 100644
---
These appear in a single Dirt Showdown compute shader. With this
VGPR spilling in the radeonsi NIR backend is reduced.
---
src/compiler/nir/nir_opt_algebraic.py | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
---
src/compiler/nir/nir_search.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compiler/nir/nir_search.c b/src/compiler/nir/nir_search.c
index 28b36b2b863..743ffdf232c 100644
--- a/src/compiler/nir/nir_search.c
+++ b/src/compiler/nir/nir_search.c
@@ -73,6 +73,9 @@
On 19/07/18 12:02, Connor Abbott wrote:
Why not do the more general thing, and evaluate the condition in every
block dominated by the then and else blocks? That should handle the
loop and non-loop cases.
Can you explain what the advantage would be in doing that? Is it just
likely to reduce
Until now, we had separate passes for lowering gl_PatchVerticesIn to
a statically known constant (for TES inputs when linked against a TCS),
and a uniform in the other cases. Annoyingly, one had to be run before
nir_lower_system_values, and the other afterward. This simplified the
passes, but
Why not do the more general thing, and evaluate the condition in every
block dominated by the then and else blocks? That should handle the
loop and non-loop cases.
On Thu, Jul 19, 2018 at 8:06 AM, Timothy Arceri wrote:
> Since we know what side of the branch we ended up on we can just
> replace
Until now, we had separate passes for lowering gl_PatchVerticesIn to
a statically known constant (for TES inputs when linked against a TCS),
and a uniform in the other cases. Annoyingly, one had to be run before
nir_lower_system_values, and the other afterward. This simplified the
passes, but
Rb
On July 18, 2018 16:49:07 Kenneth Graunke wrote:
These are lowered by brw_nir_lower_vs_inputs(). If they weren't, we
would have already hit the unreachable() in emit_system_values_block().
---
src/intel/compiler/brw_fs_nir.cpp | 16
1 file changed, 4 insertions(+), 12
Since we know what side of the branch we ended up on we can just
replace the use with a constant.
All helped shaders are from Unreal Engine 4 besides one shader from
Dirt Showdown.
V2: make sure we do evaluation when condition is used in else with
a single block (we were checking for blocks
https://bugs.freedesktop.org/show_bug.cgi?id=107224
Timothy Arceri changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
These are lowered by brw_nir_lower_vs_inputs(). If they weren't, we
would have already hit the unreachable() in emit_system_values_block().
---
src/intel/compiler/brw_fs_nir.cpp | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=107283
Bug ID: 107283
Summary: Dispatch sanity tests broken
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Keywords: bisected, regression
On 19/07/18 03:07, Brian Paul wrote:
On 07/17/2018 06:47 PM, Stefan Dirsch wrote:
On Tue, Jul 17, 2018 at 04:57:26PM -0600, Brian Paul wrote:
Reviewed-by: Brian Paul
Do you need me to push this for you?
I'm afraid the answer is yes. Tried it but push hangs forever after this
# git push
Danylo Piliaiev writes:
> After optimization passes and many trasfromations most of memory
"transformations"
> NIR holds is a garbage which was being freed only after shader deletion.
"is garbage"
> Freeing it at the end of linking will save memory which would be useful
> in case there are a
Ian Romanick writes:
> On 07/16/2018 02:46 PM, Eric Anholt wrote:
>> This fixes dEQP case:
>>
>> dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_fragment
>
> Are we sure that test is correct? I'm sure I already know the answer,
> but does the test contain
Signed-off-by: Sonny Jiang
---
src/gallium/drivers/radeonsi/si_build_pm4.h | 24
src/gallium/drivers/radeonsi/si_gfx_cs.c| 3 +++
src/gallium/drivers/radeonsi/si_state.h | 1 +
src/gallium/drivers/radeonsi/si_state_shaders.c | 21
https://bugs.freedesktop.org/show_bug.cgi?id=94747
--- Comment #3 from Ian Romanick ---
(In reply to Timothy Arceri from comment #2)
> As (In reply to Jason Ekstrand from comment #1)
> > The code for this already exists. It's called nir_opt_peephole_select. The
> > only problem is that it only
On 07/16/2018 02:46 PM, Eric Anholt wrote:
> This fixes dEQP case:
>
> dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_fragment
Are we sure that test is correct? I'm sure I already know the answer,
but does the test contain any justification or spec
On Wed, Jul 18, 2018 at 06:21:32PM +0100, Lionel Landwerlin wrote:
> Signed-off-by: Lionel Landwerlin
> ---
> src/intel/tools/aub_write.c | 45 ++---
> 1 file changed, 32 insertions(+), 13 deletions(-)
>
> diff --git a/src/intel/tools/aub_write.c
Very sketchily
Reviewed-by: Jason Ekstrand
On Wed, Jul 18, 2018 at 10:21 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> In commit 86cb05a6d35a52 ("intel: aubinator: remove standard input
> processing option") we removed the ability to process aub as an input
> stream because
Without this change, dlopen()/dlclose() of any driver results in memory
being leaked which becomes problematic if things are being reinitialized
repeatedly (eg from a fuzzer).
Even with this change, repeated dlopen()/dlclose() results in a single
LLVM mutex being allocated and never freed (used
The two patches look correct to me.
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi Sonny,
I've pushed the first 2 patches.
See below for feedback on this patch.
On Tue, Jul 17, 2018 at 10:22 AM, Sonny Jiang wrote:
> Signed-off-by: Sonny Jiang
> ---
> src/gallium/drivers/radeonsi/si_build_pm4.h | 23 +++
> src/gallium/drivers/radeonsi/si_gfx_cs.c
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Jul 18, 2018 at 2:02 PM, Eric Anholt wrote:
> Nothing in EGL_KHR_gl_image.txt seems to let us deny creation based on
> formats, and doing so causes many failures in
> dEQP-EGL.functional.image.api.*
>
> The NONE value we were protecting
Reviewed-by: Samuel Pitoiset
On 07/18/2018 08:24 PM, Andres Rodriguez wrote:
Assignment and usage of this variable both happen inside an
if(rad_image_has_dcc()) {} blocks. It seems gcc plays it safe and
assumes that both function calls could have different return values.
But in this case we
Emil Velikov writes:
> From: Emil Velikov
>
> With commit c6c0f947142, back in 2006 Brian removed the
> _glapi_check_multithread() call from core mesa - _mesa_make_current.
>
> He moved it to a DRI loader (type of) decision - with equivalents in
> the monolithic OSMesa and libGL-Xlib.
>
> Some
some nitpicks, but with those fixed:
Reviewed-by: Karol Herbst
On Wed, Jul 18, 2018 at 7:05 PM, Rhys Perry wrote:
> This hits the shader-db numbers a good bit, though a few xmads is way
> faster than an imul or imad and the cost is mitigated by the next commit,
> which optimizes many
Assignment and usage of this variable both happen inside an
if(rad_image_has_dcc()) {} blocks. It seems gcc plays it safe and
assumes that both function calls could have different return values.
But in this case we should be safe.
---
src/amd/vulkan/radv_meta_fast_clear.c | 2 +-
1 file changed,
Assignment and usage of this variable both happen inside an
if(rad_image_has_dcc()) {} blocks. It seems gcc plays it safe and
assumes that both function calls could have different return values.
But in this case we should be safe.
---
src/amd/vulkan/radv_meta_fast_clear.c | 2 +-
1 file changed,
On Wed, Jul 18, 2018 at 7:05 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> .../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 63
> ++
> .../nouveau/codegen/nv50_ir_target_gm107.cpp | 6 ++-
> .../nouveau/codegen/nv50_ir_target_nvc0.cpp| 1 +
>
uint16_t
On Wed, Jul 18, 2018 at 7:05 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir.h | 23
> ++
> .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 17 ++--
>
The EGL CTS expects that you can make images from all sorts of things,
including things like z16 and s8, which we don't have DRM fourccs for.
Just return an error when trying to export one of those.
---
src/egl/drivers/dri2/egl_dri2.c | 27 +++
1 file changed, 27
Nothing in EGL_KHR_gl_image.txt seems to let us deny creation based on
formats, and doing so causes many failures in
dEQP-EGL.functional.image.api.*
The NONE value we were protecting from only gets looked at in the
__DRI_IMAGE_ATTRIB_FORMAT and __DRI_IMAGE_ATTRIB_FOURCC queries, which are
used
On Wed, Jul 18, 2018 at 1:46 PM, Roland Scheidegger wrote:
> Am 18.07.2018 um 19:29 schrieb Marek Olšák:
>> On Tue, Jul 17, 2018 at 9:44 AM, Roland Scheidegger
>> wrote:
>>> Initially, width/height were actually needed because not all
>>> pipe_surface objects were backed by pipe_resource
I think draw_count won't be very large. I'll send v2, because I made
some mistakes there.
Marek
On Tue, Jul 17, 2018 at 3:09 PM, Eric Anholt wrote:
> Marek Olšák writes:
>
>> From: Marek Olšák
>>
>> ---
>> src/gallium/auxiliary/util/u_vbuf.c | 189
>> 1 file
Am 18.07.2018 um 19:29 schrieb Marek Olšák:
> On Tue, Jul 17, 2018 at 9:44 AM, Roland Scheidegger
> wrote:
>> Initially, width/height were actually needed because not all
>> pipe_surface objects were backed by pipe_resource objects (that was ages
>> ago...). Hence the comment when that was
Rob Clark writes:
> From: Eric Anholt
>
> Reviewed-by: Rob Clark
> ---
> Not sure if this ever got sent to list.. but this extension is meant to
> be exposed in GLES as well as GL
Did the trivial whitespace fix and pushed.
signature.asc
Description: PGP signature
Reviewed-by: Marek Olšák
Marek
On Mon, Jul 16, 2018 at 12:01 AM, Timothy Arceri wrote:
> This allows NIR to CSE more operations. LLVM does this also so the
> impact is limited, however doing this in NIR allows other opts to
> make progress. For example some loops in Civilization Beyond Earth
>
I pushed the patch. Thanks!
Marek
On Wed, Jul 18, 2018 at 1:30 PM, Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Mon, Jul 16, 2018 at 3:20 PM, Timothy Pearson
> wrote:
>>
>> color_interp_vgpr_index was declared as a generic char value.
>> Because signed values are used in
Reviewed-by: Marek Olšák
Marek
On Mon, Jul 16, 2018 at 3:20 PM, Timothy Pearson
wrote:
>
> color_interp_vgpr_index was declared as a generic char value.
> Because signed values are used in this variable, the result
> was not safe across architectures and crashed on ppc64[el]
> and arm.
>
>
Reviewed-by: Marek Olšák
Marek
On Tue, Jul 17, 2018 at 10:36 AM, Jan Vesely wrote:
> They might lead to unrecoverable GPU hang.
> Signed-off-by: Jan Vesely
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
On Tue, Jul 17, 2018 at 9:44 AM, Roland Scheidegger wrote:
> Initially, width/height were actually needed because not all
> pipe_surface objects were backed by pipe_resource objects (that was ages
> ago...). Hence the comment when that was fixed, since it was always
> actually possible to derive
With the alignment fixed, this is:
Reviewed-by: Marek Olšák
Marek
On Wed, Jul 18, 2018 at 11:01 AM, Rob Clark wrote:
> From: Eric Anholt
>
> Reviewed-by: Rob Clark
> ---
> Not sure if this ever got sent to list.. but this extension is meant to
> be exposed in GLES as well as GL
>
>
On Wed, Jul 18, 2018 at 1:05 PM, Rhys Perry wrote:
> Signed-off-by: Rhys Perry
> ---
> src/util/bitscan.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/src/util/bitscan.h b/src/util/bitscan.h
> index dc89ac93f2..cae61d3f71 100644
> ---
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aub_write.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/intel/tools/aub_write.c b/src/intel/tools/aub_write.c
index 1224e8f6b7f..de4ce33 100644
--- a/src/intel/tools/aub_write.c
+++
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/intel_dump_gpu.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/src/intel/tools/intel_dump_gpu.c b/src/intel/tools/intel_dump_gpu.c
index 5fd2c8ea723..6ce7d452afb 100644
---
In commit 86cb05a6d35a52 ("intel: aubinator: remove standard input
processing option") we removed the ability to process aub as an input
stream because we're now rely on mmapping the aub file to back the
buffers aubinator is parsing.
intel_aubdump was the provider of the standard input data and
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aub_write.c | 45 ++---
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/src/intel/tools/aub_write.c b/src/intel/tools/aub_write.c
index de4ce33..9c140553542 100644
---
Shouldn't this be a non-shader CAP? Because the value is not different
between shader stages and doesn't make sense for non-fragment shaders.
Marek
On Sun, Jul 15, 2018 at 2:15 PM, Karol Herbst wrote:
> From: Karol Herbst
>
> this way Nouveau can report 128 inputs, but only 124 varyings.
>
>
Changes in v2:
- rebase
- bring back constant folding for multiplication by power-of-twos for nv50
- remove TODO in nv50_ir_target_gm107.cpp
- document XMAD's flags
- change how XMAD's per-operand flags are represented
- move util/bitscan.h stuff into a new patch
- stylistic changes
This series
Signed-off-by: Rhys Perry
---
src/util/bitscan.h | 28
1 file changed, 28 insertions(+)
diff --git a/src/util/bitscan.h b/src/util/bitscan.h
index dc89ac93f2..cae61d3f71 100644
--- a/src/util/bitscan.h
+++ b/src/util/bitscan.h
@@ -286,6 +286,34 @@
Signed-off-by: Rhys Perry
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 23 ++
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 17 ++--
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 18 +
Signed-off-by: Rhys Perry
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 63 ++
.../nouveau/codegen/nv50_ir_target_gm107.cpp | 6 ++-
.../nouveau/codegen/nv50_ir_target_nvc0.cpp| 1 +
3 files changed, 69 insertions(+), 1 deletion(-)
diff --git
Strongly mitigates the harm from the previous commit, which made many
integer multiplications much more heavy on the register and instruction
count.
total instructions in shared programs : 5294693 -> 5268293 (-0.50%)
total gprs used in shared programs: 624962 -> 624196 (-0.12%)
total shared
This hits the shader-db numbers a good bit, though a few xmads is way
faster than an imul or imad and the cost is mitigated by the next commit,
which optimizes many multiplications by immediates into shorter and less
register heavy instructions than the xmads.
total instructions in shared
On 07/17/2018 06:47 PM, Stefan Dirsch wrote:
On Tue, Jul 17, 2018 at 04:57:26PM -0600, Brian Paul wrote:
Reviewed-by: Brian Paul
Do you need me to push this for you?
I'm afraid the answer is yes. Tried it but push hangs forever after this
# git push --verbose
Pushing to
Am 17.07.2018 um 19:04 schrieb Gert Wollny:
> From: Gert Wollny
>
> The array index needs to be corrected and it must be insured that it is
> rounded and its value is non-negative before it is combined with the
> face id.
>
> v5: Use RNDNE instead of ADD 0.5 and FLOOR (Ilia Mirkin)
>
> Fixes
https://bugs.freedesktop.org/show_bug.cgi?id=107276
soredake changed:
What|Removed |Added
CC||fds...@krutt.org
--
You are receiving this
On Wed, Jul 18, 2018 at 05:34:13PM +0300, Eleni Maria Stea wrote:
> On 07/10/2018 03:10 AM, Nanley Chery wrote:
> > On Thu, Jun 14, 2018 at 10:50:57PM +0300, Eleni Maria Stea wrote:
> >> On 06/14/2018 10:27 PM, Nanley Chery wrote:
> >>
> >>> +Jason, Ken
> >>>
> >>> Hello,
> >>>
> >>> I recently
No worries, I should have removed it when I included the tool.
Sending a v2.
On 18/07/18 17:13, Jason Ekstrand wrote:
I'm happy for us to do this and it would have made my life easier when
refactoring the aub_write code. Unfortunately, since I just landed
that, this will need some rebasing.
I'm happy for us to do this and it would have made my life easier when
refactoring the aub_write code. Unfortunately, since I just landed that,
this will need some rebasing. Sorry, I didn't realize how you'd intended
things to be ordered before I landed my refactors. :-(
On Wed, Jul 18, 2018
On Wed, Jul 18, 2018 at 7:33 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Awesome tool! And not even too much code!
>
> Reviewed-by: Lionel Landwerlin
>
Thanks!
> In the interest of consistency and because this is an installable
> binary, I would rename it.
> Now for the
On Thu 12 Jul 2018, Jason Ekstrand wrote:
> On Wed, Jun 27, 2018 at 5:55 PM Chad Versace <[1]chadvers...@chromium.org>
> wrote:
>
> On Tue 26 Jun 2018, Jason Ekstrand wrote:
> > At the moment, this is entirely internal but we'll expose it to clients
> > of the BLORP API in the next
On Wed 11 Jul 2018, Chad Versace wrote:
> +Ken, I had a question about GLboolean. I call you by name in the
> comments below.
>
> On Fri 29 Jun 2018, Fritz Koenig wrote:
> > Adds an extension to glFramebufferParameteri
> > that will specify if the framebuffer is vertically
> > flipped.
Thanks,
Reviewed-by: Lionel Landwerlin
On 18/07/18 16:24, Jason Ekstrand wrote:
On Wed, Jul 18, 2018 at 3:08 AM Lionel Landwerlin
mailto:lionel.g.landwer...@intel.com>>
wrote:
On 18/07/18 00:05, Jason Ekstrand wrote:
> For large buffers which span an entire l1 page table, we got
On Wed, Jul 18, 2018 at 11:01 AM, Rob Clark wrote:
> From: Eric Anholt
>
> Reviewed-by: Rob Clark
> ---
> Not sure if this ever got sent to list.. but this extension is meant to
> be exposed in GLES as well as GL
>
> .../glapi/gen/AMD_performance_monitor.xml | 22 +--
>
On Wed, Jul 18, 2018 at 3:08 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> On 18/07/18 00:05, Jason Ekstrand wrote:
> > For large buffers which span an entire l1 page table, we got the range
> > calculations wrong. In this case, we end up with an l1_start which is
> > the first
On Wed, Jul 11, 2018 at 3:54 PM Chad Versace wrote:
>
> +Ken, I had a question about GLboolean. I call you by name in the
> comments below.
>
> On Fri 29 Jun 2018, Fritz Koenig wrote:
> > Adds an extension to glFramebufferParameteri
> > that will specify if the framebuffer is vertically
> >
Hey Rob,
On 2018-07-18 15:30, Rob Herring wrote:
On Tue, Jul 17, 2018 at 4:33 AM Robert Foss wrote:
This series implements kms_swrast support for the Android
platform. And since having to debug a null pointer dereference,
simplify that process for the next guy.
So is this working for you
From: Eric Anholt
Reviewed-by: Rob Clark
---
Not sure if this ever got sent to list.. but this extension is meant to
be exposed in GLES as well as GL
.../glapi/gen/AMD_performance_monitor.xml | 22 +--
src/mesa/main/extensions_table.h | 2 +-
2 files changed,
On 07/10/2018 03:10 AM, Nanley Chery wrote:
> On Thu, Jun 14, 2018 at 10:50:57PM +0300, Eleni Maria Stea wrote:
>> On 06/14/2018 10:27 PM, Nanley Chery wrote:
>>
>>> +Jason, Ken
>>>
>>> Hello,
>>>
>>> I recently did some miptree work relating to the r8stencil_mt and I
>>> think I now have a more
Awesome tool! And not even too much code!
Reviewed-by: Lionel Landwerlin
In the interest of consistency and because this is an installable
binary, I would rename it.
Now for the hard part : intel_error2aub ?
-
Lionel
On 18/07/18 00:05, Jason Ekstrand wrote:
---
Reviewed-by: Lionel Landwerlin
On 18/07/18 00:05, Jason Ekstrand wrote:
---
src/intel/tools/aub_write.c | 764 +++
src/intel/tools/aub_write.h | 96
src/intel/tools/intel_dump_gpu.c | 762 +-
Reviewed-by: Lionel Landwerlin
On 18/07/18 00:05, Jason Ekstrand wrote:
Instead of having quite so many singletons, we use a struct aub_file to
organize the bits we need for writing an aub file.
---
src/intel/tools/intel_dump_gpu.c | 498 ++-
1 file changed, 287
In commit 86cb05a6d35a52 ("intel: aubinator: remove standard input
processing option") we removed the ability to process aub as an input
stream because we're now rely on mmapping the aub file to back the
buffer aubinator is parsing.
intel_aubdump was the provider of the standard input data and
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve_fs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve_fs.c
b/src/amd/vulkan/radv_meta_resolve_fs.c
index 3feeb45897..7c6ddf513c 100644
---
We already check that in radv_cmd_buffer_resolve_subpass().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve_cs.c | 12
src/amd/vulkan/radv_meta_resolve_fs.c | 12
2 files changed, 24 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c
The goal is to use radv_barrier()/radv_subpass_barrier() as
much as possible for further optimizations.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 3 ++-
src/amd/vulkan/radv_meta_resolve_cs.c | 16 +---
src/amd/vulkan/radv_meta_resolve_fs.c | 13
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index b67f0ffdbe..4a6b5fdcd9 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++
https://bugs.freedesktop.org/show_bug.cgi?id=107275
--- Comment #3 from mais...@archlinux.us ---
Yes, doesn't segfault now. Seems to work as expected.
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
The series are
Acked-by: Leo Liu
On 07/16/2018 06:03 PM, Leo Liu wrote:
On 2018-07-16 04:01 PM, Marek Olšák wrote:
From: Marek Olšák
Dependencies between rings are inserted correctly if a buffer is
represented by only one unique amdgpu_winsys_bo instance.
Use a hash table keyed by
https://bugs.freedesktop.org/show_bug.cgi?id=107276
--- Comment #4 from Philip Rebohle ---
Created attachment 140695
--> https://bugs.freedesktop.org/attachment.cgi?id=140695=edit
Demo app that does not trigger the problem
I used this small sample app in an attempt to reproduce the problem,
https://bugs.freedesktop.org/show_bug.cgi?id=107276
--- Comment #3 from Philip Rebohle ---
Created attachment 140694
--> https://bugs.freedesktop.org/attachment.cgi?id=140694=edit
Final image (broken)
--
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=107276
--- Comment #2 from Philip Rebohle ---
Created attachment 140693
--> https://bugs.freedesktop.org/attachment.cgi?id=140693=edit
Final image (correct)
--
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=107276
--- Comment #1 from Philip Rebohle ---
Created attachment 140692
--> https://bugs.freedesktop.org/attachment.cgi?id=140692=edit
Workaround that fixes the rendering issue
--
You are receiving this mail because:
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=107276
Bug ID: 107276
Summary: radv: OpBitfieldUExtract returns incorrect result when
count is zero
Product: Mesa
Version: git
Hardware: Other
OS: All
1 - 100 of 118 matches
Mail list logo
