On Mon, 2017-04-03 at 08:55 -0700, Nanley Chery wrote:
> On Mon, Apr 03, 2017 at 08:02:54AM +0200, Iago Toral wrote:
> >
> > Can anyone review this one?
> >
> > On Wed, 2017-03-29 at 08:58 +0200, Iago Toral Quiroga wrote:
> > >
> > > Writing and testing are two different things and they can be s
On Mon, Apr 3, 2017 at 11:28 PM, Roland Scheidegger wrote:
> Am 03.04.2017 um 17:11 schrieb Alex Deucher:
>> On Sun, Apr 2, 2017 at 2:00 PM, Marek Olšák wrote:
>>> From: Marek Olšák
>>>
>>> Also:
>>>
>>> pipe_transfer: 48 -> 40 bytes.
>>> pipe_blit_info = 176 -> 160 bytes.
>>> ---
>>> src/galli
On 04/03/2017 11:09 PM, Rob Clark wrote:
> On Mon, Apr 3, 2017 at 4:57 PM, Rob Clark wrote:
>> On Mon, Apr 3, 2017 at 4:06 PM, Thomas Hellstrom
>> wrote:
>>> On 04/03/2017 07:33 PM, Thomas Hellstrom wrote:
On 04/03/2017 07:13 PM, Rob Clark wrote:
> On Mon, Apr 3, 2017 at 12:56 PM, Thoma
The default GCC implementation works only for i386 and the new
libunwind implementation is very slow at capturing backtraces which makes
it unusable together with the u_debug_flush functionality, which is also
why we make the user have to explicitly select libunwind if needed.
The check for availa
Why don't you set disableLinearOpt instead?
Marek
On Tue, Apr 4, 2017 at 4:17 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> The below commit caused a regression on radv with 1D textures,
> this was because the base level for these small textures was
> being degraded to a linear level due to th
On 03/04/17 21:04, Robert Bragg wrote:
On Mar 30, 2017 16:16, "Lionel Landwerlin"
mailto:lionel.g.landwer...@intel.com>>
wrote:
While exercising reading report with moderate load, we might have to
wait for all the reports to land in the OA buffer, otherwise we might
miss some re
Hi,
I noticed that GALLIUM_HUD does not write hud values into files properly.
The destination files look empty at least for 5 min and then are filed in
with some burst. I wonder if it could be a problem with the
GALLIUM_HUD_PERIOD which would be wrong when writing values into files. Or
write is n
The default GCC implementation works only for i386 and the new
libunwind implementation is very slow at capturing backtraces which makes
it unusable together with the u_debug_flush functionality, which is also
why we make the user have to explicitly select libunwind if needed.
The check for availa
Hi,
On 04.04.2017 09:23, Luke Kenneth Casson Leighton wrote:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848895
there's a really strange and comprehensively cross-application
intermittent bug that's only occurring on opengl-based applications,
that's been introduced some time in the past
On 4 April 2017 at 10:00, Thomas Hellstrom wrote:
> On 04/03/2017 11:09 PM, Rob Clark wrote:
>> On Mon, Apr 3, 2017 at 4:57 PM, Rob Clark wrote:
>>> On Mon, Apr 3, 2017 at 4:06 PM, Thomas Hellstrom
>>> wrote:
On 04/03/2017 07:33 PM, Thomas Hellstrom wrote:
> On 04/03/2017 07:13 PM, Rob
I guess that this patch is meant to be squashed into 4/4.
For the series:
Reviewed-by: Andreas Boll
2017-04-03 13:28 GMT+02:00 Juan A. Suarez Romero :
> v2 (Andreas Boll):
> - Mark GL 4.1 as supported by i965/gen7+
> - Mark GL_ARB_shader_precision as supported by i965/gen7+
> - Update release no
On Apr 4, 2017 11:26, "Julien Isorce" wrote:
Hi,
I noticed that GALLIUM_HUD does not write hud values into files properly.
The destination files look empty at least for 5 min and then are filed in
with some burst. I wonder if it could be a problem with the
GALLIUM_HUD_PERIOD which would be wron
Thx Edmondo, let me know the result! Also is the pane on screen supposed to
work with llvmpipe driver because I cannot see it with GALLIUM_HUD=fps
LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe glxgears
Cheers.
Julien
On 4 April 2017 at 11:29, Edmondo Tommasina
wrote:
>
>
> On Apr 4, 2017 11:2
https://bugs.freedesktop.org/show_bug.cgi?id=68380
Daniel Stone changed:
What|Removed |Added
CC||dan...@fooishbar.org
--- Comment #2 from
On Tue, Apr 4, 2017 at 11:04 AM, Eero Tamminen
wrote:
>> anyway, apologies: nobody whose applications are affected by this
>> really has a clue where the *actual* bug is so i am escalating it down
>> the chain of library dependencies, making people aware. it could be
>> X11, it could be mesa, we
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Apr 4, 2017 at 12:10 PM, Luke Kenneth Casson Leighton
wrote:
>> Does DRI2 vs. DRI3 have any effect on it?
>
> hmm, good question. i'm running with "DRI" "true" (so don't know if
> it's 2 or 3), other people wi
On Tue, Apr 4, 2017 at 5:00 AM, Thomas Hellstrom wrote:
> On 04/03/2017 11:09 PM, Rob Clark wrote:
>> On Mon, Apr 3, 2017 at 4:57 PM, Rob Clark wrote:
>>> On Mon, Apr 3, 2017 at 4:06 PM, Thomas Hellstrom
>>> wrote:
On 04/03/2017 07:33 PM, Thomas Hellstrom wrote:
> On 04/03/2017 07:13 P
On Tue, Apr 4, 2017 at 6:28 AM, Emil Velikov wrote:
> On 4 April 2017 at 10:00, Thomas Hellstrom wrote:
>> On 04/03/2017 11:09 PM, Rob Clark wrote:
>>> On Mon, Apr 3, 2017 at 4:57 PM, Rob Clark wrote:
On Mon, Apr 3, 2017 at 4:06 PM, Thomas Hellstrom
wrote:
> On 04/03/2017 07:33 P
On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom wrote:
> But one more worrying thing is that with these fixes, debug_flush gets
> too slow to be usable. I get about one frame every 5 seconds from Ubuntu
> compiz. The culprit seems to be unw_get_proc_name(). Is there a way we
> can save intermedia
On 04/04/2017 02:34 PM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom
> wrote:
>> But one more worrying thing is that with these fixes, debug_flush gets
>> too slow to be usable. I get about one frame every 5 seconds from Ubuntu
>> compiz. The culprit seems to be unw_get_pro
On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom wrote:
> On 04/04/2017 02:34 PM, Rob Clark wrote:
>> On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom
>> wrote:
>>> But one more worrying thing is that with these fixes, debug_flush gets
>>> too slow to be usable. I get about one frame every 5 sec
When the GBM BOs are created, they are created using a bo with a correct
memory requirement but with an incorrect channel layout. This makes
drivers that are picky about matching formats (svga/vmwgfx) complain.
Use the correct GBM formats and require GBM >= 13.0 to make sure they
are available.
S
On Tue, Apr 4, 2017 at 8:06 AM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 6:28 AM, Emil Velikov wrote:
>> On 4 April 2017 at 10:00, Thomas Hellstrom wrote:
>>> On 04/03/2017 11:09 PM, Rob Clark wrote:
On Mon, Apr 3, 2017 at 4:57 PM, Rob Clark wrote:
> On Mon, Apr 3, 2017 at 4:06 PM, Th
On 04/04/17 00:22, Jordan Justen wrote:
From BDW PRM, Volume 6: Command Stream Programming, 'Render Command
Header Format'.
Signed-off-by: Jordan Justen
---
src/intel/common/gen_decoder.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/intel/common/gen_
Sounds like a good strategy :)
Acked-by: Lionel Landwerlin
On 04/04/17 00:22, Jordan Justen wrote:
Decoding with aubinator encountered a command of 0x. With the
previous code, it caused aubinator to jump 255 + 2 dwords to start
decoding again.
Instead we can attempt to detect the know
Reviewed-by: Lionel Landwerlin
On 04/04/17 00:22, Jordan Justen wrote:
Signed-off-by: Jordan Justen
---
src/intel/tools/aubinator.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index a64bce7a536..0d33c392384
On 04/04/2017 02:49 PM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom
> wrote:
>> On 04/04/2017 02:34 PM, Rob Clark wrote:
>>> On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom
>>> wrote:
But one more worrying thing is that with these fixes, debug_flush gets
too s
On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom wrote:
> On 04/04/2017 02:34 PM, Rob Clark wrote:
>> On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom
>> wrote:
>>> But one more worrying thing is that with these fixes, debug_flush gets
>>> too slow to be usable. I get about one frame every 5 sec
On Tue, Apr 4, 2017 at 10:00 AM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom
> wrote:
>> On 04/04/2017 02:34 PM, Rob Clark wrote:
>>> On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom
>>> wrote:
But one more worrying thing is that with these fixes, debug_flush gets
On 04/04/2017 04:06 PM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 10:00 AM, Rob Clark wrote:
>> On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom
>> wrote:
>>> On 04/04/2017 02:34 PM, Rob Clark wrote:
On Tue, Apr 4, 2017 at 1:49 AM, Thomas Hellstrom
wrote:
> But one more worrying
From: Nicolai Hähnle
The sparse buffer implementation requires amdgpu_bo_va_op_raw.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 3df9af1..455c090 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,21 +67,21 @@ OPENCL_VERS
Ah, you didn't wait for amdgpu_query_sensor_info() ?
On 04/04/2017 04:36 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
The sparse buffer implementation requires amdgpu_bo_va_op_raw.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.
From: Ilia Mirkin
v2 (Nicolai):
- BALLOT isn't per-channel
- expand the documentation (also for VOTE_*)
v3:
- only BALLOT returns a 64-bit lanemask (Boyan)
- relax the requirement on READ_INVOC: the invocation number to read
from must be uniform within a sub-group. This matches the
GL_ARB_sh
On 04.04.2017 16:38, Samuel Pitoiset wrote:
Ah, you didn't wait for amdgpu_query_sensor_info() ?
Sorry, I didn't see that in time, and Marek already made a release this
morning. But libdrm releases are supposed to be lightweight, so not a
huge deal if they happen very frequently.
Cheers,
Ni
On 04/04/2017 04:43 PM, Nicolai Hähnle wrote:
On 04.04.2017 16:38, Samuel Pitoiset wrote:
Ah, you didn't wait for amdgpu_query_sensor_info() ?
Sorry, I didn't see that in time, and Marek already made a release this
morning. But libdrm releases are supposed to be lightweight, so not a
huge de
v2: Check if the input channels are enabled
Set lower 32 bits zero instead of clockhi
Signed-off-by: Boyan Ding
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
b
v2: Also enable support on nv50
Signed-off-by: Boyan Ding
---
docs/features.txt | 2 +-
docs/relnotes/17.1.0.html | 2 +-
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 2 +-
4 files change
For the series:
Tested-by: Dieter Nützel
On Turks XT (6670).
Marek can you apply?
Dieter
Am 02.04.2017 19:33, schrieb Constantine Kharlamov:
Specifically, non-line primitives skipped, and defaulting to reset on
each packet.
The skip of non-line primitives saves ≈110 resetting of
PA_SC_LINE
On Tue, Apr 4, 2017 at 10:41 AM, Nicolai Hähnle wrote:
> From: Ilia Mirkin
>
> v2 (Nicolai):
> - BALLOT isn't per-channel
> - expand the documentation (also for VOTE_*)
>
> v3:
> - only BALLOT returns a 64-bit lanemask (Boyan)
> - relax the requirement on READ_INVOC: the invocation number to read
For the series:
Reviewed-by: Nicolai Hähnle
And FWIW, I like i32_0/1. It's shorter :)
On 03.04.2017 11:52, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 116 ++---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 4 +-
On 03.04.2017 12:09, Marek Olšák wrote:
I've changed the commit message to "targets: export radeon
winsys_create functions to silence LLVM warning".
Reviewed-by: Nicolai Hähnle
Marek
On Mon, Apr 3, 2017 at 12:08 PM, Marek Olšák wrote:
From: Marek Olšák
It silences the following radeon
From: Ilia Mirkin
v2 (Nicolai):
- BALLOT isn't per-channel
- expand the documentation (also for VOTE_*)
v3:
- only BALLOT returns a 64-bit lanemask (Boyan)
- relax the requirement on READ_INVOC: the invocation number to read
from must be uniform within a sub-group. This matches the
GL_ARB_sh
Reviewed-by: Marek Olšák
Marek
On Tue, Apr 4, 2017 at 4:36 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The sparse buffer implementation requires amdgpu_bo_va_op_raw.
> ---
> configure.ac | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure
On Tue, 2017-04-04 at 12:29 +0200, Andreas Boll wrote:
> I guess that this patch is meant to be squashed into 4/4.
Yes. My mistake because I forgot to squash before sending it again.
J.A.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=100559
Bug ID: 100559
Summary: Typo in man page drm(7) version September 2012
Product: Mesa
Version: 17.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
S
On Tue, Apr 4, 2017 at 10:28 AM, Thomas Hellstrom wrote:
> On 04/04/2017 04:06 PM, Rob Clark wrote:
>> On Tue, Apr 4, 2017 at 10:00 AM, Rob Clark wrote:
>>> On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom
>>> wrote:
On 04/04/2017 02:34 PM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 1:4
From: Boyuan Zhang
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_video.c
b/src/gallium/drivers/radeon/radeon_video.c
index 605a2c7..02e8dcf 100644
--- a/src/gallium
Am 04.04.2017 um 17:38 schrieb boyuan.zh...@amd.com:
From: Boyuan Zhang
Signed-off-by: Boyuan Zhang
Reviewed-by: Christian König
---
src/gallium/drivers/radeon/radeon_video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_video.c
Please update the release notes in the last patch.
Thanks,
Andreas
2017-03-20 10:16 GMT+01:00 Samuel Iglesias Gonsálvez :
> Hi,
>
> This series implements initial support for Ivybridge FP64 for both
> align16 and align1 backends, and with that we can enable FP64 and
> OpenGL 4.0 in Ivybridge.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=100559
Eric Engestrom changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 04/04/2017 05:36 PM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 10:28 AM, Thomas Hellstrom
> wrote:
>> On 04/04/2017 04:06 PM, Rob Clark wrote:
>>> On Tue, Apr 4, 2017 at 10:00 AM, Rob Clark wrote:
On Tue, Apr 4, 2017 at 8:45 AM, Thomas Hellstrom
wrote:
> On 04/04/2017 02:34 PM
2017-04-04 17:58 GMT+02:00 Christian König :
> Am 04.04.2017 um 17:38 schrieb boyuan.zh...@amd.com:
>>
>> From: Boyuan Zhang
>>
>> Signed-off-by: Boyuan Zhang
>
>
> Reviewed-by: Christian König
>
Cc: stable?
>> ---
>> src/gallium/drivers/radeon/radeon_video.c | 2 +-
>> 1 file changed, 1 in
In gl core, buffer must be reserved first by CreateBuffers/GenBuffers
to be valid.
Signed-off-by: Gregory Hainaut
---
src/mesa/main/marshal.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/marshal.c b/src/mesa/main/marshal.
It would be used in next commit to allow asynchronous PBO transfer.
The tracking saves the buffer name into a hash. Saving pointer
will be more complex as the buffer is created in BindBuffer due to IsBuffer
insanity.
Perf wise DeleteBuffers is now synchronous for robustness.
Signed-off-by: Grego
Context:
Nouveau uses NULL strings for unnamed parameter of texture gather
offsets opcode.
Fix piglit crashes of the 'texturegatheroffsets' tests on Nouveau
v2: based on Nicolai feedback
Adds an extra flag byte that will be null if the string is null.
This way, null strings are handled transparen
Improve speed on PCSX2
v2:
Add ppbo/ubpo status in XML file
Disable variable parameter (as the pointer would be a fixed offset)
v3:
split buffer tracking into separate patches.
use 'goto fallback_to_sync' when asynchronous transfer isn't supported
Signed-off-by: Gregory Hainaut
---
src/mapi/gl
Hello,
Please find a new version to handle invalid buffer handles.
Allow to handle this kind of case:
genBuffer(&pbo);
DeleteBuffer(pbo);
BindBuffer(pbo)
TexSubImage2D(user_memory_pointer); // Data transfer will be synchronous
There are various subtely to handle multi threaded shared
Well it's a tricky situation with cabac which would be a shame to loose.
Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support
As it stands with cabac on I can make (what I think is) a perfectly
legal stream with ffmpeg or gstreamer (ig
On Tue, Apr 4, 2017 at 12:10 PM, Thomas Hellstrom wrote:
> On 04/04/2017 05:36 PM, Rob Clark wrote:
>> On Tue, Apr 4, 2017 at 10:28 AM, Thomas Hellstrom
>> wrote:
>>> On 04/04/2017 04:06 PM, Rob Clark wrote:
On Tue, Apr 4, 2017 at 10:00 AM, Rob Clark wrote:
> On Tue, Apr 4, 2017 at 8:4
On Tue, Apr 4, 2017 at 10:20 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> On 03/04/17 21:04, Robert Bragg wrote:
>
>
>
> On Mar 30, 2017 16:16, "Lionel Landwerlin"
> wrote:
>
> While exercising reading report with moderate load, we might have to
> wait for all the reports to la
On Mon 03 Apr 2017, Jason Ekstrand wrote:
> On Mon, Apr 3, 2017 at 5:19 PM, Chad Versace
> wrote:
>
> > On Wed 15 Mar 2017, Jason Ekstrand wrote:
> > > This cache allows us to easily ensure that we have a unique anv_bo for
> > > each gem handle. We'll need this in order to support multiple-impor
On 3 April 2017 at 11:09, Marek Olšák wrote:
> I've changed the commit message to "targets: export radeon
> winsys_create functions to silence LLVM warning".
>
Thanks for the update Marek!
Reviewed-by; Emil Velikov
-Emil
___
mesa-dev mailing list
mesa
On 4 April 2017 at 17:13, Andreas Boll wrote:
> 2017-04-04 17:58 GMT+02:00 Christian König :
>> Am 04.04.2017 um 17:38 schrieb boyuan.zh...@amd.com:
>>>
>>> From: Boyuan Zhang
>>>
>>> Signed-off-by: Boyuan Zhang
>>
>>
>> Reviewed-by: Christian König
>>
>
> Cc: stable?
>
Good idea, but we really
On Mon 03 Apr 2017, Jason Ekstrand wrote:
> On Mon, Apr 3, 2017 at 3:45 PM, Chad Versace wrote:
> > On Mon 03 Apr 2017, Jason Ekstrand wrote:
> > > On Mon, Apr 3, 2017 at 12:31 PM, Chad Versace
> > > wrote:
> > > > Since each VkDevice has a unique drm device fd, and since the kernel
> > > > allo
On 4 April 2017 at 13:49, Thomas Hellstrom wrote:
> When the GBM BOs are created, they are created using a bo with a correct
> memory requirement but with an incorrect channel layout. This makes
> drivers that are picky about matching formats (svga/vmwgfx) complain.
>
> Use the correct GBM formats
When the shader does not set one of these values, they are supposed to
get a default value of 0. We have hardware bits in 3DSTATE_CLIP for
this but haven't been setting them. This fixes the intermittent failure
of dEQP-VK.geometry.layered.3d.render_to_default_layer.
Cc: "13.0 17.0"
---
src/int
New C++ features used by upcoming swr changes.
---
configure.ac| 8
src/gallium/drivers/swr/Makefile.am | 4 ++--
src/gallium/drivers/swr/SConscript | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 83cd5d1..5
---
.../swr/rasterizer/codegen/gen_llvm_types.py | 22 +
.../drivers/swr/rasterizer/common/simdintrin.h | 7 +
src/gallium/drivers/swr/rasterizer/core/api.cpp| 8 +-
.../drivers/swr/rasterizer/core/backend.cpp| 43 +-
src/gallium/drivers/swr/rasterizer/core/backend.h |
Highlights include simd16 work, msaa enhancements, and removing the
extra copy of mako we included.
Tim Rowley (9):
swr: [rasterizer core] SIMD16 Frontend WIP
swr: [rasterizer core/memory] Fix missing avx512 storetile
swr: [rasterizer core] Fix center sample pattern
swr: [configure.ac/scon
Implement widened VS output for SIMD16
---
.../drivers/swr/rasterizer/core/frontend.cpp | 42 +-
src/gallium/drivers/swr/rasterizer/core/state.h| 9 +++--
2 files changed, 14 insertions(+), 37 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/fronten
Fix long hidden bug in rasterizer handling of center sample pattern.
---
src/gallium/drivers/swr/rasterizer/core/binner.cpp | 14 +--
.../drivers/swr/rasterizer/core/rasterizer.cpp | 28 +++---
.../drivers/swr/rasterizer/core/rasterizer.h | 10
3 files ch
---
src/gallium/drivers/swr/rasterizer/core/knobs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/knobs.h
b/src/gallium/drivers/swr/rasterizer/core/knobs.h
index 7928f5d..e347558 100644
--- a/src/gallium/drivers/swr/rasterizer/core/kno
Implement widened binner for SIMD16
---
.../drivers/swr/rasterizer/common/simd16intrin.h | 44 +-
src/gallium/drivers/swr/rasterizer/core/binner.cpp | 1642 +---
src/gallium/drivers/swr/rasterizer/core/frontend.h | 98 ++
src/gallium/drivers/swr/rasterizer/core/utils.h|
---
.../drivers/swr/rasterizer/core/backend.cpp| 8 +-
src/gallium/drivers/swr/rasterizer/core/backend.h | 56 -
.../drivers/swr/rasterizer/core/format_types.h | 7 ++
src/gallium/drivers/swr/rasterizer/core/utils.h| 130 ++---
.../drivers/swr/rasteriz
Fix pre-processor macro handing to eliminate silently missing
implementation for AVX512.
---
src/gallium/drivers/swr/rasterizer/core/format_types.h | 18 --
src/gallium/drivers/swr/rasterizer/core/utils.h| 4 ++--
src/gallium/drivers/swr/rasterizer/memory/StoreTile.h | 15
Adding the actual table from the docs makes it clearer exactly what the
restrictions are. In particular, it becomes clear that compressed
textures ignore the alignment parameters in RENDER_SURFACE_STATE.
---
src/intel/isl/isl_gen8.c | 64
1 file ch
On Tue 04 Apr 2017, Jason Ekstrand wrote:
> Adding the actual table from the docs makes it clearer exactly what the
> restrictions are. In particular, it becomes clear that compressed
> textures ignore the alignment parameters in RENDER_SURFACE_STATE.
> ---
> src/intel/isl/isl_gen8.c | 64
>
https://bugs.freedesktop.org/show_bug.cgi?id=68380
--- Comment #3 from Stanislav Vorobiov ---
I guess this is no longer an issue since it was reported years ago. Frankly
speaking, I don't even remember in what scenario and under which circumstances
did I face this...
--
You are receiving this m
On 2017-04-04 06:21:04, Lionel Landwerlin wrote:
> On 04/04/17 00:22, Jordan Justen wrote:
> > From BDW PRM, Volume 6: Command Stream Programming, 'Render Command
> > Header Format'.
> >
> > Signed-off-by: Jordan Justen
> > ---
> > src/intel/common/gen_decoder.c | 12 ++--
> > 1 file c
Tested-by: Mark Janes
Jason Ekstrand writes:
> When the shader does not set one of these values, they are supposed to
> get a default value of 0. We have hardware bits in 3DSTATE_CLIP for
> this but haven't been setting them. This fixes the intermittent failure
> of dEQP-VK.geometry.layered.3
Andy Furniss wrote:
Well it's a tricky situation with cabac which would be a shame to loose.
Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support
As it stands with cabac on I can make (what I think is) a perfectly
legal stream with ff
https://bugs.freedesktop.org/show_bug.cgi?id=100562
Bug ID: 100562
Summary: u_debug_stack.c:59: undefined reference to
`_Ux86_64_getcontext'
Product: Mesa
Version: 11.1
Hardware: x86-64 (AMD64)
OS: Linux (Al
https://bugs.freedesktop.org/show_bug.cgi?id=68380
Daniel Stone changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
The word "clarify" is misspelled in the title.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Andy Furniss wrote:
Well it's a tricky situation with cabac which would be a shame to loose.
Currently I guess it's a bit strange advertising main/high - but then
others do without having mbaff support
As it stands with cabac on I can make (what I think is) a perfectly
legal stream with ff
On Tue, Apr 4, 2017 at 12:47 PM, Julien Isorce wrote:
> Thx Edmondo, let me know the result! Also is the pane on screen supposed to
> work with llvmpipe driver because I cannot see it with GALLIUM_HUD=fps
> LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe glxgears
>
> Cheers.
> Julien
>
> On 4 Apri
Pushed. Thanks!
Marek
On Tue, Apr 4, 2017 at 4:45 PM, Dieter Nützel wrote:
> For the series:
>
> Tested-by: Dieter Nützel
>
> On Turks XT (6670).
>
> Marek can you apply?
>
> Dieter
>
>
> Am 02.04.2017 19:33, schrieb Constantine Kharlamov:
>>
>> Specifically, non-line primitives skipped, and de
Flush the HUD value streams to the dump files after every newline.
---
src/gallium/auxiliary/hud/hud_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 29ef9eee31..633e3650cc 100644
--- a/src/galliu
https://bugs.freedesktop.org/show_bug.cgi?id=100562
Vinson Lee changed:
What|Removed |Added
Version|11.1|git
CC|
Signed-off-by: Fredrik Höglund
---
src/amd/vulkan/radv_cmd_buffer.c | 76 ++
src/amd/vulkan/radv_descriptor_set.c | 22 +-
src/amd/vulkan/radv_descriptor_set.h | 3 ++
src/amd/vulkan/radv_device.c | 19 -
src/amd/vulkan/radv_ent
Move the implementation into a separate function that takes a
cmd_buffer and a dstSetOverride parameter.
When cmd_buffer is not NULL, radv_update_descriptor_sets calls
cs_add_buffer directly instead of updating the buffer list.
This will be used to implement VK_KHR_push_descriptor.
Signed-off-by
This appears to be a leftover from an earlier version of this function.
Nothing is emitted into the CS.
Signed-off-by: Fredrik Höglund
---
src/amd/vulkan/radv_cmd_buffer.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
This series adds support for VK_KHR_push_descriptor and
VK_KHR_descriptor_update_template in radv.
This series is also available at:
git://people.freedesktop.org/~fredrik/mesa radv-push-descriptor-submit
Please review.
Fredrik
deqp-vk -n 'dEQP-VK.binding_model.*.with_push.*'
Test run totals:
Replace the !binding_layout->immutable_samplers assertion in
radv_update_descriptor_sets with a conditional.
The Vulkan specification does not say that it is illegal to update
a sampler descriptor when it is immutable; only that pImageInfo is
ignored.
This change is also needed for push descripto
All offsets and strides are precomputed by
radv_CreateDescriptorUpdateTemplateKHR and stored in the template.
Signed-off-by: Fredrik Höglund
---
src/amd/vulkan/radv_cmd_buffer.c | 24 +
src/amd/vulkan/radv_descriptor_set.c | 163 +
src/amd/vulkan/radv
https://bugs.freedesktop.org/show_bug.cgi?id=100569
Bug ID: 100569
Summary: core/resource.cpp:36:33: error:
non-constant-expression cannot be narrowed from type
'int' to 'int16_t' (aka 'short') in initializer list
[
From: Vinson Lee
Fix linking error.
CXXLDlibGL.la
../../../../src/gallium/auxiliary/.libs/libgallium.a(u_debug_stack.o): In
function `debug_backtrace_capture':
src/gallium/auxiliary/util/u_debug_stack.c:59: undefined reference to
`_Ux86_64_getcontext'
src/gallium/auxiliary/util/u_debug_s
Could you move the declarations you add in radv_descriptor_set.h to
radv_private.h? I'd like to keep it limited to whatever is necessary
for the compiler, which is only the set & pipeline layouts. You could
just put it next to the radv_descriptor_set declaration.
Otherwise, nice work! The series i
Fix linking error.
CXXLDlibGL.la
../../../../src/gallium/auxiliary/.libs/libgallium.a(u_debug_stack.o): In
function `debug_backtrace_capture':
src/gallium/auxiliary/util/u_debug_stack.c:59: undefined reference to
`_Ux86_64_getcontext'
src/gallium/auxiliary/util/u_debug_stack.c:60: undefine
On Friday, March 31, 2017 4:17:08 PM PDT Jason Ekstrand wrote:
> This fixes issues seen when adding support for full 48-bit addresses.
> The 48-bit addresses themselves have nothing to do with it other than
> that it caused the kernel to place buffers slightly differently so they
> interacted diffe
1 - 100 of 202 matches
Mail list logo
