https://bugs.freedesktop.org/show_bug.cgi?id=106348
--- Comment #1 from Michel Dänzer ---
Could be a duplicate of bug 106180.
--
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=106348
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-t...@lists.x.org
On Wed, May 2, 2018 at 3:38 PM, Timothy Arceri wrote:
> On 02/05/18 22:36, Timothy Arceri wrote:
>>
>> On 02/05/18 21:48, Grazvydas Ignotas wrote:
>>>
>>> On Wed, May 2, 2018 at 1:27 PM, Timothy Arceri
>>> wrote:
---
On 02/05/18 22:36, Timothy Arceri wrote:
On 02/05/18 21:48, Grazvydas Ignotas wrote:
On Wed, May 2, 2018 at 1:27 PM, Timothy Arceri
wrote:
---
src/mesa/drivers/dri/common/dri_util.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
On 02/05/18 21:48, Grazvydas Ignotas wrote:
On Wed, May 2, 2018 at 1:27 PM, Timothy Arceri wrote:
---
src/mesa/drivers/dri/common/dri_util.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
On Mon, 2018-03-19 at 16:56 +0200, Eleni Maria Stea wrote:
> Gen 7 GPUs store the compressed EAC/ETC2 images in other non-compressed
> formats that can render. When GetCompressed* functions are called, the
> pixels are returned in the non-compressed format that is used for the
> rendering.
>
>
From: Matthew Nicholls
Previously before fb077b0728, the LOD parameter was being used in place of the
sample index, which would only copy the first sample to all samples in the
destination image. After that multisample image copies wouldn't copy anything
from my
On Wed, May 2, 2018 at 1:27 PM, Timothy Arceri wrote:
> ---
> src/mesa/drivers/dri/common/dri_util.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index
https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #5 from mgorc...@qnx.com ---
Will test within 3-4 hours and let you know. Thank you very much for the prompt
fix!
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #4 from Tapani Pälli ---
Created attachment 139271
--> https://bugs.freedesktop.org/attachment.cgi?id=139271=edit
fix attempt
Would this fix things for you?
--
You are receiving this mail because:
You are the
Hi,
On 02.05.2018 02:25, James Xiong wrote:
From: "Xiong, James"
With the current implementation, brw_bufmgr may round up a request
size to the next bucket size, result in 25% more memory allocated in
the worst senario. For example:
Request sizeActual size
Reviewed-by: Lionel Landwerlin
On 02/05/18 06:50, Kenneth Graunke wrote:
Making these part of libintel_common allows us to use them in the DRI
driver. The standalone tool binaries already link against the common
library, too, so it's no harder for them.
---
Reviewed-by: Lionel Landwerlin
On 02/05/18 06:50, Kenneth Graunke wrote:
With the new callback, Jason's newer batch decoder infrastructure
should be able to do just as well as the old open coded INTEL_DEBUG=bat
handling, with much less code. If there are any
On 02/05/18 06:50, Kenneth Graunke wrote:
Given an arbitrary batch, we don't always know what the size of certain
things are, such as how many entries are in a binding table. But it's
easy for the driver to track that information, so with a simple callback
we can calculate this correctly for
Struct fields might span several dwords, but iter_dword is incremented
up to the last dword of the current field before we print out the
struct's fields. We can't use iter_dword for computing the offset into
the pointer of data to decode.
v2: Fix displayed offset number (Ken)
Signed-off-by:
NIR assumes that booleans are always 32-bit, but Intel hardware produces
16-bit booleans for 16-bit comparisons. This means that we need to convert
the 16-bit result to 32-bit.
In the future we want to add an optimization pass to clean this up and
hopefully remove the conversions.
v2 (Jason):
---
src/mesa/drivers/dri/common/dri_util.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index 7cb6248b130..d72f72d0756 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++
---
src/mapi/glapi/gen/apiexec.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
index b5e0ad4a179..d33cc85d47f 100644
--- a/src/mapi/glapi/gen/apiexec.py
+++ b/src/mapi/glapi/gen/apiexec.py
@@ -46,7 +46,7 @@
The Game crashes on start-up if it can't create a compat 4.1 profile.
It also wants tess shaders and ARB_draw_indirect to be avaliable in
compat but they require actual work as the would be accessable to
currently supported GL versions if enabled. It seems playable
without them.
Bugzilla:
---
src/mesa/main/version.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 84babd69e2f..540f5482034 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -591,6 +591,8 @@ _mesa_get_version(const struct gl_extensions
https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #3 from Tapani Pälli ---
Yeah, this is the case. We could change this to use flush_with_flags and have a
new flag that causes us to wait for last batchbuffer. I can give this a shot.
--
You are receiving this
On 02/05/18 07:44, Kenneth Graunke wrote:
On Tuesday, May 1, 2018 4:43:05 PM PDT Lionel Landwerlin wrote:
Struct fields might span several dwords, but iter_dword is incremented
up to the last dword of the current field before we print out the
struct's fields. We can't use iter_dword for
On Wed, 2018-04-25 at 11:49 -0400, boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang
>
> Previous bit-fields assignments are incorrect and will result certain mpeg4
> decode failed due to wrong flag values. This patch fixes these assignments.
>
> Signed-off-by: Boyuan Zhang
From: Michel Dänzer
And only free no longer needed back buffers there as well.
We want to stick to the same back buffer throughout a frame, otherwise
we can run into various issues.
Bugzilla: https://bugs.freedesktop.org/105906
Fixes: 3160cb86aa92 "egl/x11: Re-allocate
On 2018-05-02 06:00 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> This can result in 2x increase in performance on non-harvested Kaveris.
FWIW, no difference with glxgears on my (non-harvested AFAIK) Kaveris,
neither with amdgpu nor radeon. Should I try something else?
https://bugs.freedesktop.org/show_bug.cgi?id=106337
--- Comment #2 from mgorc...@qnx.com ---
Yes, it is i965 DRI driver on ApolloLake (BXT) hardware.
The test was following: BO object (LINEAR) is shared between compositor and
GLES app (used as KHRImage for native pixmap). GLES
Series is:
Reviewed-by: Samuel Pitoiset
On 05/01/2018 10:48 PM, Bas Nieuwenhuizen wrote:
This fixes
dEQP-VK.api.device_init.create_instance_invalid_api_version
CC: 18.1
---
src/amd/vulkan/radv_device.c | 9 -
1 file
Heya,
On 2018-05-01 18:44, Rob Herring wrote:
On Tue, May 1, 2018 at 3:13 AM, Robert Foss wrote:
Hey Rob,
On 2018-05-01 04:20, Rob Herring wrote:
On Fri, Apr 27, 2018 at 6:57 AM, Robert Foss
wrote:
From: Rob Herring
On 30/04/18 20:51, Jason Ekstrand wrote:
> On Mon, Apr 30, 2018 at 1:46 AM, Samuel Iglesias Gonsálvez
> > wrote:
>
> On 26/04/18 18:14, Jason Ekstrand wrote:
>>
>>
>> On Thu, Apr 26, 2018 at 2:24 AM, Samuel Iglesias Gonsálvez
>>
SPIR-V allows to define the shift, offset and count operands for
shift and bitfield opcodes with a bit-size different than 32 bits,
but in NIR the opcodes have that limitation. As agreed in the
mailing list, this patch adds a conversion to 32 bits to fix this.
For more info, see:
> That all sounds good. Those are exactly the things we wanted when
> creating NIR, so it's nice to hear :)
Hooray!
> It might be beneficial for you to lower b2f there
Ah, I had not noticed that section was seperate. Yes, I think you're
right about that.
Updated patch sent. (I hope I did this
This pass is required by the Midgard compiler; our instruction set uses
NIR-style booleans (~0 for true) but lacks a dedicated b2f instruction.
Normally, this lowering pass would be implemented in a backend-specific
algebraic pass, but this conflicts with the existing iand->b2f pass in
Sorry this needs more work I will send another version.
On 02/05/18 16:54, Timothy Arceri wrote:
---
src/mesa/drivers/dri/common/dri_util.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
---
src/mesa/main/version.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 84babd69e2f..540f5482034 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -591,6 +591,8 @@ _mesa_get_version(const struct gl_extensions
---
src/mesa/drivers/dri/common/dri_util.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index 7cb6248b130..b6bc5361308 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++
On Tuesday, May 1, 2018 4:43:01 PM PDT Lionel Landwerlin wrote:
> Hi all,
>
> While investigating an error state I noticed some strange values. Here
> are a few changes and fixes. You can give it a try on the error states
> from https://bugs.freedesktop.org/show_bug.cgi?id=106243
>
> Cheers,
>
On Tuesday, May 1, 2018 4:43:05 PM PDT Lionel Landwerlin wrote:
> Struct fields might span several dwords, but iter_dword is incremented
> up to the last dword of the current field before we print out the
> struct's fields. We can't use iter_dword for computing the offset into
> the pointer of
On Mon, 2018-04-30 at 14:43 -0700, Jason Ekstrand wrote:
> On Mon, Apr 30, 2018 at 7:18 AM, Iago Toral Quiroga m> wrote:
> > NIR assumes that booleans are always 32-bit, but Intel hardware
> > produces
> >
> > 16-bit booleans for 16-bit comparisons. This means that we need to
We will need to handle this on other backends as well, dri2 and wayland
at least would stumble to same issue, maybe fix them all in one go?
Looks like android, surfaceless and drm backends check the returned
config already.
On 04/30/2018 02:51 PM, Juan A. Suarez Romero wrote:
According to
101 - 139 of 139 matches
Mail list logo