On 24.06.2016 19:21, Emil Velikov wrote:
> On 24 June 2016 at 03:32, Michel Dänzer wrote:
>> On 23.06.2016 22:25, Emil Velikov wrote:
>>> On 23 June 2016 at 03:49, Michel Dänzer wrote:
On 22.06.2016 21:04, Emil Velikov wrote:
> From: Emil Velikov
>
> Do not rely on the git sha1:
https://bugs.freedesktop.org/show_bug.cgi?id=96684
--- Comment #1 from Kenneth Graunke ---
I can't reproduce this. I tried both classic swrast and llvmpipe and it seems
to be working fine.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
On Sat, Jun 25, 2016 at 4:54 PM, Alejandro Piñeiro wrote:
> In theory they don't overdrawn. The test has a square formed by N
> non-overlapping triangles. With just one call to glDrawRangeElements,
> this always works. But if we split it in M subsets, so M calls to
> glDrawRangeElements with N/M t
Both explicit and implicit.
Using vtx 0 (as existing llvm code implies) does not work for dynamic offsets.
Signed-off-by: Jan Vesely
---
Hi,
I ran into problem when using VTX_READ from constant buffer would work only for
0 index. The LLVM code implied that it should work (or maybe they consider
Rob Clark writes:
> On Sat, Jun 25, 2016 at 11:33 PM, Eric Anholt wrote:
>> Rob Herring writes:
>>
>>> It is necessary to reuse existing BOs when dmabufs are imported. There
>>> are 2 cases that need to be handled. dmabufs can be created/exported and
>>> imported by the same process and can be
On 06/26/2016 11:55 PM, Ilia Mirkin wrote:
On Sun, Jun 26, 2016 at 5:49 PM, Samuel Pitoiset
wrote:
On 06/26/2016 11:46 PM, Ilia Mirkin wrote:
We don't appear to handle src(0) having a neg modifier in the
immediate case. Does the insnCanLoad logic account for that? (Perhaps
the bit is ther
On Sun, Jun 26, 2016 at 5:49 PM, Samuel Pitoiset
wrote:
>
>
> On 06/26/2016 11:46 PM, Ilia Mirkin wrote:
>>
>> We don't appear to handle src(0) having a neg modifier in the
>> immediate case. Does the insnCanLoad logic account for that? (Perhaps
>> the bit is there and we just forgot about it?)
>
On 06/26/2016 11:46 PM, Ilia Mirkin wrote:
We don't appear to handle src(0) having a neg modifier in the
immediate case. Does the insnCanLoad logic account for that? (Perhaps
the bit is there and we just forgot about it?)
I don't see any neg modifier in envydis for IADD32I.
On Sun, Jun 26,
We don't appear to handle src(0) having a neg modifier in the
immediate case. Does the insnCanLoad logic account for that? (Perhaps
the bit is there and we just forgot about it?)
On Sun, Jun 26, 2016 at 5:40 PM, Samuel Pitoiset
wrote:
> IADD only allows to emit 19-bits immediates. This is similar
MOV only allows to emit 19-bits immediates. This is similar to the
previous fix I did for IMUL.
Signed-off-by: Samuel Pitoiset
Cc:
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/cod
IADD only allows to emit 19-bits immediates. This is similar to the
previous fix I did for MOV.
Signed-off-by: Samuel Pitoiset
Cc:
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codeg
Nayan Deshmukh wrote:
Hi Andy,
On Sun, Jun 26, 2016 at 12:25 AM, Andy Furniss wrote:
Nayan Deshmukh wrote:
Hi Andy,
Thanks for testing the patches.
Please send me the videos and ratios with which there is corruption.
https://drive.google.com/file/d/0BxP5-S1t9VEEaHZEM203RFpyNEE/view?us
Only include the ones that can be used by the shader.
This fixes texture coordinates, which were completely wrong,
because WPOS was included in the list of attribs. It also
increases performance noticeably.
Signed-off-by: Miklós Máté
---
src/mesa/swrast/s_context.c | 3 ++-
1 file changed, 2 in
https://bugs.freedesktop.org/show_bug.cgi?id=96684
Bug ID: 96684
Summary: [swrast] piglit glsl-array-bounds-01 regression
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Key
On Sat, Jun 25, 2016 at 11:33 PM, Eric Anholt wrote:
> Rob Herring writes:
>
>> It is necessary to reuse existing BOs when dmabufs are imported. There
>> are 2 cases that need to be handled. dmabufs can be created/exported and
>> imported by the same process and can be imported multiple times.
>>
Hi Andy,
On Sun, Jun 26, 2016 at 12:25 AM, Andy Furniss wrote:
> Nayan Deshmukh wrote:
>
>> Hi Andy,
>>
>> Thanks for testing the patches.
>>
>> Please send me the videos and ratios with which there is corruption.
>>
>
>
> https://drive.google.com/file/d/0BxP5-S1t9VEEaHZEM203RFpyNEE/view?usp=sha
Rob Herring writes:
> It is necessary to reuse existing BOs when dmabufs are imported. There
> are 2 cases that need to be handled. dmabufs can be created/exported and
> imported by the same process and can be imported multiple times.
> Copying other drivers, add a hash table to track exported BO
Rb
On Jun 25, 2016 9:30 PM, "Eric Anholt" wrote:
> The intent was to continue down the indirect chain, not to call ourselves
> with unchanged input arguments. Found by code inspection, and comparison
> to copy_prop_alu_src().
>
> We haven't hit this because callers of NIR's copy prop are doing s
Reviewed-by: Ilia Mirkin
Might be good to make a note of why, and/or reference the GK110 commit
that did the same thing.
On Sun, Jun 26, 2016 at 11:23 AM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> Cc:
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 +-
>
Signed-off-by: Samuel Pitoiset
Cc:
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp
index 5a7
On Sun, 2016-06-26 at 16:15 +0300, Grazvydas Ignotas wrote:
> Tried this while playing with apitrace and am getting segfaults when
> running any trace with a cached (second) run. Not sure if it's
> "wrong"
> traces I've chosen or what, you can take one example from this bug:
> https://bugs.freedesk
On Sat, Jun 25, 2016 at 8:54 PM, Eric Anholt wrote:
> The intent was to continue down the indirect chain, not to call ourselves
> with unchanged input arguments. Found by code inspection, and comparison
> to copy_prop_alu_src().
>
> We haven't hit this because callers of NIR's copy prop are doing
Tried this while playing with apitrace and am getting segfaults when
running any trace with a cached (second) run. Not sure if it's "wrong"
traces I've chosen or what, you can take one example from this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=96425
It would also be good idea to hide the
This was useful when debugging the previous commit's issue.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index a929a20..2f473cc 100644
-
emit_urb_writes() contains code to emit an EOT write with no actual
data when there are no output varyings. This makes sense for the VS
and TES stages, where it's called once at the end of the program.
However, in the geometry shader stage, emit_urb_writes() is called once
for every EmitVertex().
Thx for the patch:
Reviewed-by: Julien Isorce
I'll push it today.
On 26 June 2016 at 08:02, Gurkirpal Singh wrote:
> Call to handle_table_get in vlVaDestroySurfaces can
> return NULL on failure.
>
> CID: 1243522
>
> Signed-off-by: Gurkirpal Singh
> ---
> src/gallium/state_trackers/va/surface
Call to handle_table_get in vlVaDestroySurfaces can
return NULL on failure.
CID: 1243522
Signed-off-by: Gurkirpal Singh
---
src/gallium/state_trackers/va/surface.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/su
27 matches
Mail list logo
