https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #23 from Matt Turner ---
(In reply to comment #22)
> Has this fix landed?
No. See comment 21.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailin
From: Dave Airlie
v2: I rewrote this to use the sample positions properly.
v3: rewrite properly to use bitfield to cast back to signed ints
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 287 ++---
src/gallium/drivers/r600/r600_state.c
From: Dave Airlie
This adds support to the mesa state tracker for ARB_texture_multisample.
hardware doesn't seem to use a different texture instructions, so
I don't think we need to create one for TGSI at this time.
Thanks to Marek for fixes to sample number picking.
v2: idr pointed out a bug
From: Dave Airlie
This just calls into the gallium interface.
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/mesa/sources.mak| 1 +
src/mesa/state_tracker/st_cb_msaa.c | 54 +
src/mesa/state_tracker/st_cb_msaa.h | 39 ++
From: Dave Airlie
This is to be used to implement glGet GL_SAMPLE_POSITION.
Reviewed-by: Marek Olšák
Signed-off-by: Dave Airlie
---
src/gallium/include/pipe/p_context.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/gallium/include/pipe/p_context.h
b/src/gallium/inclu
From: Dave Airlie
This allows us to reuse this for choosing formats for MSAA limits.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_format.c | 24 +++-
src/mesa/state_tracker/st_format.h | 5 +
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/s
Hi guys,
this hopefully addresses the issues pointed out in previous reviews,
the main difference is the st/mesa max samples chooser is correct,
which Ian pointed out.
Also r600g sample positions are now valid, my last attempt missed
some unsigned/signed issues.
Dave.
_
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #22 from Ilyes Gouta ---
Hi,
(In reply to comment #20)
> Created attachment 77156 [details] [review]
> MesaLib-9.1.1-cross.patch
>
> Suggested fix.
Has this fix landed?
Ilyes
--
You are receiving this mail because:
You are the a
From: Eric Anholt
We are intentionally not allocating a slot for gl_ClipVertex. But by
leaving the bit set in the slots_valid, the fragment shader's computation
of where varyings are in urb entry coming out of the SF would be off by
one. Fixes rendering in Freespace 2 SCP, and improves renderin
On Apr 10, 2013, at 6:48 AM, Tobias Grosser wrote:
> On 04/10/2013 02:51 PM, Michel Dänzer wrote:
>> On Mit, 2013-04-10 at 12:59 +0200, Christian König wrote:
>>> Am 10.04.2013 12:21, schrieb Michel Dänzer:
On Mit, 2013-04-10 at 12:07 +0200, Christian König wrote:
> Am 10.04.2013 11:46,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
> OK, the presence of glDrawBuffer(GL_FRONT) in the linked code plus
> the glFinish()/glFlush()es made it look like you were.
I did some experimenting with manual copying... also, the code will
clearly show that I am very inexperienced at GL ;-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
>> I am not using GLES, but normal OpenGL through EGL. And I am
>> pretty sure it's double-buffered - as far as I understood it,
>> that's the default, and I did not attempt to override it in any
>> way (like calling glDrawBuffer).
>
> Oh, our
On 04/10/2013 02:51 PM, Michel Dänzer wrote:
On Mit, 2013-04-10 at 12:59 +0200, Christian König wrote:
Am 10.04.2013 12:21, schrieb Michel Dänzer:
On Mit, 2013-04-10 at 12:07 +0200, Christian König wrote:
Am 10.04.2013 11:46, schrieb Michel Dänzer:
But why the heck is multiplying with 0x4f800
https://bugs.freedesktop.org/show_bug.cgi?id=63078
--- Comment #5 from Chad Versace ---
Ralf, please verify that the bug is fixed on master, then change the bug status
to CLOSED.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=63078
Chad Versace changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=44618
--- Comment #21 from Matt Turner ---
(In reply to comment #20)
> Created attachment 77156 [details] [review]
> MesaLib-9.1.1-cross.patch
>
> Suggested fix.
Looks like you've solved this by not using libtool libraries in
src/glsl/builtin_compile
On 04/10/2013 04:33 PM, Zack Rusin wrote:
Same as with llvmpipe: we can't be divind/moding by zero and we
need to make sure that dividing/moding by zero produces 0x.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 16
1 file changed, 8 inserti
Matt Turner writes:
> On Wed, Apr 10, 2013 at 11:54 AM, Eric Anholt wrote:
>> These checks were all over, and every time I wrote one I had to try to
>> decide again what the cases were for partial updates.
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 35
>> +++--
Kenneth Graunke writes:
> If a region is larger than the estimated aperture size, we map/unmap it
> by copying with the BLT engine. Which means we can't use Y-tiling.
>
> Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my
> recent change to use Y-tiling by default on Gen6+.
https://bugs.freedesktop.org/show_bug.cgi?id=63404
--- Comment #1 from Joe Konno ---
To be clear, the mesa crash and stderr printf will cause the "lucky" instance
to crash as well.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=63404
Joe Konno changed:
What|Removed |Added
CC||brian.j.lo...@intel.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=63404
Priority: medium
Bug ID: 63404
Assignee: mesa-dev@lists.freedesktop.org
Summary: [wayland egl] intel_do_flush_locked failed: invalid
argument, crash
Severity: normal
Clas
Jordan Justen writes:
> I think f5a80846 is a candidate for 9.1.
Yes, I agree. I should have mentioned this in the original email,
(though at the time, I was still exploring alternate solutions as can be
seen in my email).
> This fixes a crash of the latest build of Anomaly Warzone Earth on the
I think f5a80846 is a candidate for 9.1. This fixes a crash of the
latest build of Anomaly Warzone Earth on the 9.1 branch.
On Tue, Feb 19, 2013 at 4:27 PM, Carl Worth wrote:
> This fixes a bug introduced in commit 258453716f001eab1288d99765213 and
> triggered whenever "rb" is NULL.
>
> Fixes bug
which means that our execution mask in GS is equal to 1 not 0xf.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
b/src/gallium/auxil
Same as with llvmpipe: we can't be divind/moding by zero and we
need to make sure that dividing/moding by zero produces 0x.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gall
Here's the output:
creating vs ...
shader compilation status: OK
creating fs ...
shader compilation status: OK
thread #0 (0;0) : ref = 16608
thread #1 (1;0) : ref = 27873
thread #2 (0;1) : ref = 16608
thread #3 (1;1) : ref = 27877
results:
thread 0 (0, 0): expected = 16608, observed = 27876, FAIL
On 04/10/2013 02:08 PM, Kenneth Graunke wrote:
If a region is larger than the estimated aperture size, we map/unmap it
by copying with the BLT engine. Which means we can't use Y-tiling.
Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my
recent change to use Y-tiling by defau
On 04/10/2013 02:08 PM, Kenneth Graunke wrote:
This reduces the nesting level slightly, and in my opinion, makes it a
bit easier to follow.
Cc: Paul Berry
Cc: Chad Versace
Cc: Eric Anholt
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 10 ++
1
On 04/10/2013 01:53 PM, Marek Olšák wrote:
glsl-fs-loop-nested passes here.
nstack is 3 and adding 4 to it doesn't help.
Ok, thanks.
Also I wrote a simple test app that should reproduce the issue if it's
really related to diverging control flow with nested loops and might
more information a
Probably, the optimizer sees that there is second assignment, and skips the
first, f=1.0. It never gets to second though.
On Wed, Apr 10, 2013 at 11:08 PM, Ian Romanick wrote:
> On 04/10/2013 12:20 PM, Vadim Girlin wrote:
>
>> Hi,
>>
>> It seems there is a bug in the compiler. The problem may b
On 04/10/2013 01:32 PM, Kenneth Graunke wrote:
On 04/09/2013 09:01 PM, Paul Berry wrote:
The comment above glsl_type::name claimed that it could sometimes be
NULL. This was wrong--it is never NULL. Many error handling paths
would segfault if it were.
Fix the comment and add assertions to vali
If a region is larger than the estimated aperture size, we map/unmap it
by copying with the BLT engine. Which means we can't use Y-tiling.
Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my
recent change to use Y-tiling by default on Gen6+. This was due to a
botched merge con
This reduces the nesting level slightly, and in my opinion, makes it a
bit easier to follow.
Cc: Paul Berry
Cc: Chad Versace
Cc: Eric Anholt
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff
---
lib/Target/R600/R600Instructions.td | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index 2e9a8a3..1c292bb 100644
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@
---
lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp | 15 +--
lib/Target/R600/R600Instructions.td| 8
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/lib/Target/R600/MCTargetDesc/R600MCCodeEmitter.cpp
b/lib/Target/R600/MCTargetDesc/R600MCCo
---
lib/Target/R600/AMDGPUAsmPrinter.cpp | 35 +--
lib/Target/R600/AMDGPUAsmPrinter.h | 3 ++-
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/lib/Target/R600/AMDGPUAsmPrinter.cpp
b/lib/Target/R600/AMDGPUAsmPrinter.cpp
index dacb033..580cfb4 1006
Matt Turner writes:
> On Wed, Apr 10, 2013 at 11:54 AM, Eric Anholt wrote:
>> This instruction doesn't update its IR destination, it just moves from
>> payload to f0. This caused the dead code elimination pass I'm adding to
>> dead-code-eliminate the first step of interpolation.
>
> This was be
On Wed, Apr 10, 2013 at 11:54 AM, Eric Anholt wrote:
> Motivated by some troubles in register allocation on Valve's shaders, I
> found a cheap (runtime and development time) way to cut some dead code.
> This looked like failure due to losing 16-wide programs, until I updated
> more apps in shader-
On 04/09/2013 09:01 PM, Paul Berry wrote:
The comment above glsl_type::name claimed that it could sometimes be
NULL. This was wrong--it is never NULL. Many error handling paths
would segfault if it were.
Fix the comment and add assertions to validate that it really is never
NULL.
---
src/gls
On Wed, Apr 10, 2013 at 11:54 AM, Eric Anholt wrote:
> This is a poor substitute for proper global dead code elimination that
> could replace both our current paths, but it was very easy to write. It
> particularly helps with Valve's shaders that are translated out of DX
> assembly, which has bee
On 04/09/2013 03:11 PM, Paul Berry wrote:
Changes since v1:
- Consistently use the variable name "shader_prog" to refer to struct
gl_shader_program and "prog" to refer to struct gl_program.
- Move urb_read_length and urb_entry_size into brw_vec4_prog_data so
that they can be re-used by ge
On Wed, Apr 10, 2013 at 11:54 AM, Eric Anholt wrote:
> This instruction doesn't update its IR destination, it just moves from
> payload to f0. This caused the dead code elimination pass I'm adding to
> dead-code-eliminate the first step of interpolation.
This was because it had a destination tha
On 04/09/2013 03:11 PM, Paul Berry wrote:
This patch makes the following vec4_visitor functions virtual, since
they will need to be implemented differently for vertex and geometry
shaders. Some of the functions are renamed to reflect their generic
purpose, rather than their VS-specific behaviour
On Wed, Apr 10, 2013 at 11:54 AM, Eric Anholt wrote:
> These checks were all over, and every time I wrote one I had to try to
> decide again what the cases were for partial updates.
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 35
> +++-
> src/mesa/drivers/dri/i
On 04/09/2013 03:11 PM, Paul Berry wrote:
This patch just creates the derived class; later patches will migrate
VS-specific functions and data structures from the base class into the
derived class.
Reviewed-by: Jordan Justen
Reviewed-by: Eric Anholt
---
src/mesa/drivers/dri/i965/brw_vec4.cpp
On 04/10/2013 12:20 PM, Vadim Girlin wrote:
Hi,
It seems there is a bug in the compiler. The problem may be reproduced
with the following shader (complete shader_test file attached):
void main()
{
float f = 0.0;
while (true) {
f = 1.0;
break
https://bugs.freedesktop.org/show_bug.cgi?id=61919
--- Comment #5 from Darxus ---
This is still failing:
2013-03-04-13-14 998d975e38db7478781130b42a4fb68d6b181055 good mesa
2013-03-06-09-57 886c5085e3f78affa524bf12ca406a617219cd68 bad mesa
2013-03-06-14-00 cf0b4a30fc536f3744bce209d4b356fe82f2e6a
vtkRenderingOpenGLCxx-TestTransformCoordinateUseDouble
looks like an llvmpipe issue:
OSMesa-9.1.1 offscreen pass
OSMesa-git softpipe pass
OSMesa-git llvmpipe fail
Mesa-9.1.1 softpipe pass
Mesa-9.1.1 nouveau pass
Mesa-9.1.1 llvmpipe fail
Mesa-git softpipe pass
Mesa-git no
Hi,
It seems there is a bug in the compiler. The problem may be reproduced
with the following shader (complete shader_test file attached):
void main()
{
float f = 0.0;
while (true) {
f = 1.0;
break;
On 6 April 2013 20:25, Paul Berry wrote:
> When transform feedback is active, the driver manually counts the
> number of primitives that run through the pipeline, so that if a batch
> buffer flush happens, the next batch buffer can pick up transform
> feedback where the last batch buffer left off
Kenneth Graunke writes:
> If a region is larger than the estimated aperture size, we map/unmap it
> by copying with the BLT engine. Which means we can't use Y-tiling.
>
> Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my
> recent change to use Y-tiling by default on Gen6+.
On 04/10/2013 11:55 AM, Kenneth Graunke wrote:
We need know this in order to decide what tiling mode to use.
Cc: Eric Anholt
Cc: Paul Berry
Signed-off-by: Kenneth Graunke
For the series,
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-d
These are supposed to be present if both things are available, but we were
enabling them if either one was.
---
src/mesa/main/get.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 8e8d53b..6ec7ef8 100644
--- a/src/mesa
---
src/mesa/main/get.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index b913311..8e8d53b 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -226,7 +226,13 @@ union value {
* extensions or specific gl version
For this multi-page single statement, my thought the end was to that the
next block was mis-indented, rather than that the dropped indentation
actually indicated the end of the loop.
---
src/mesa/main/get.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/get.
In almost all of our cases, getters that are turned on for only some API
variants will have an extension listed as one of the things that can
enable it, and thus api_check gets set. For extra_gl30_es3 (used for
NUM_EXTENSIONS, MAJOR_VERSION, MINOR_VERSION) on a GL 2.1 context, though,
we would che
There's no reason to actually count these things, so the integer ++
behavior was just confusing.
---
src/mesa/main/get.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 6a897cb..8214
This is a poor substitute for proper global dead code elimination that
could replace both our current paths, but it was very easy to write. It
particularly helps with Valve's shaders that are translated out of DX
assembly, which has been register allocated and thus have a bunch of
unrelated uses o
This instruction doesn't update its IR destination, it just moves from
payload to f0. This caused the dead code elimination pass I'm adding to
dead-code-eliminate the first step of interpolation.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
These checks were all over, and every time I wrote one I had to try to
decide again what the cases were for partial updates.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 35 +++-
src/mesa/drivers/dri/i965/brw_fs.h |1 +
.../drivers/dri/i965/brw_fs_
---
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp |2 +-
src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp |3 +--
src/mesa/main/bitset.h|4 ++--
src/mesa/program/register_allocate.c |2 +-
4 files changed, 5 insertions(+
Motivated by some troubles in register allocation on Valve's shaders, I
found a cheap (runtime and development time) way to cut some dead code.
This looked like failure due to losing 16-wide programs, until I updated
more apps in shader-db to use shader_tests (which provide more accurate
simulation
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index ed8e65d..ead7632 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.
If a region is larger than the estimated aperture size, we map/unmap it
by copying with the BLT engine. Which means we can't use Y-tiling.
Fixes Piglit max-texture-size and tex3d-maxsize, which regressed in my
recent change to use Y-tiling by default on Gen6+. This was due to a
botched merge con
We need know this in order to decide what tiling mode to use.
Cc: Eric Anholt
Cc: Paul Berry
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/intel/intel_context.c | 17 +
src/mesa/drivers/dri/intel/intel_context.h | 2 ++
src/mesa/drivers/dri/intel/intel_mipmap
Chad Versace writes:
> From: Ralf Jung
>
> The EGLConfig attributes EGL_MIN/MAX_SWAP_INTERVAL were incorrectly set to
> 0 and 0. This prevented clients from setting the swap interval to a
> reasonable value, like 1 or 2.
>
> Swap interval worked correctly in Mesa 9.0. The commit below introduced
From: Ralf Jung
The EGLConfig attributes EGL_MIN/MAX_SWAP_INTERVAL were incorrectly set to
0 and 0. This prevented clients from setting the swap interval to a
reasonable value, like 1 or 2.
Swap interval worked correctly in Mesa 9.0. The commit below introduced
the bug.
commit 7e9bd2b2ed35a
https://bugs.freedesktop.org/show_bug.cgi?id=63393
Chris Wilson changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
|o
https://bugs.freedesktop.org/show_bug.cgi?id=63393
--- Comment #1 from aux...@gmail.com ---
Created attachment 77763
--> https://bugs.freedesktop.org/attachment.cgi?id=77763&action=edit
Xorg.log
I also reproduced this with updated Xorg and Mesa.
--
You are receiving this mail because:
You are
On 04/10/2013 10:51 AM, Eric Anholt wrote:
Chad Versace writes:
v2:
- Rerun Piglit on ivb and hsw.
- Replace
[PATCH 2/8] intel: Add functions for checking if objs have hiz enabled
with
[PATCH 2/7] intel: Add field intel_mipmap_slice::has_hiz
- Remove
https://bugs.freedesktop.org/show_bug.cgi?id=63393
Priority: medium
Bug ID: 63393
Assignee: mesa-dev@lists.freedesktop.org
Summary: Xorg crashes in pack_row_ubyte_ARGB on exporting
graph at 1200 dpi in Mathematica
Severit
Chad Versace writes:
> v2:
> - Rerun Piglit on ivb and hsw.
>
> - Replace
> [PATCH 2/8] intel: Add functions for checking if objs have hiz enabled
> with
> [PATCH 2/7] intel: Add field intel_mipmap_slice::has_hiz
>
> - Remove
> [PATCH 3/8] intel: Mark nee
On Wed, Apr 10, 2013 at 05:59:48PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> 21 more little piglits with radeonsi.
>
> Signed-off-by: Michel Dänzer
> ---
>
> v3: Use constant for and add comments about scaling multiplications
>
> lib/Target/R600/AMDGPUInstructions.td | 1 +
> li
Ralf Jung writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
>>> I am not using GLES, but normal OpenGL through EGL. And I am
>>> pretty sure it's double-buffered - as far as I understood it,
>>> that's the default, and I did not attempt to override it in any
>>> way (like cal
Paul Berry writes:
> This will allow the generic parts to be re-used for geometry shaders.
>
> Reviewed-by: Jordan Justen
>
> v2: Put urb_read_length and urb_entry_size in the generic struct.
It seems like a lot of churn would be avoided if the patch 12 contents
of "actually, let's have two nam
From: Michel Dänzer
21 more little piglits with radeonsi.
Signed-off-by: Michel Dänzer
---
v3: Use constant for and add comments about scaling multiplications
lib/Target/R600/AMDGPUInstructions.td | 1 +
lib/Target/R600/R600Instructions.td | 3 ++-
lib/Target/R600/SIInstructions.td |
Ralf Jung writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
>> If you were testing with front buffer rendering, GLES doesn't
>> support front buffer rendering (because nobody should ever use
>> it). I recommend using a debug build of mesa when developing GL
>> applications, si
https://bugs.freedesktop.org/show_bug.cgi?id=63132
--- Comment #5 from José Fonseca ---
(In reply to comment #4)
> Created attachment 77756 [details]
> ./apitrace trace konqueror
Thanks.
> I hope apitrace was invoked right ...
Yep, it reproduces the issue fine:
$ glretrace konqueror.trace
https://bugs.freedesktop.org/show_bug.cgi?id=63132
--- Comment #4 from Johannes Obermayr ---
Created attachment 77756
--> https://bugs.freedesktop.org/attachment.cgi?id=77756&action=edit
./apitrace trace konqueror
I hope apitrace was invoked right ...
--
You are receiving this mail because:
Chad Versace writes:
> On 04/09/2013 04:15 PM, Eric Anholt wrote:
>> Kenneth Graunke writes:
>>
>>> From: Chad Versace
>>>
>>> Enable hiz by setting intel_context::has_hiz. However, to work around
>>> a hardware bug, we selectively enable hiz for only nicely aligned miptree
>>> slices.
>>>
>>>
Chad Versace writes:
> On 04/09/2013 04:03 PM, Eric Anholt wrote:
>> Kenneth Graunke writes:
>>
>>> From: Chad Versace
>>>
>>> On Haswell, HiZ will selectively be enabled on individual miptree slices
>>> to workaround a hardware bug. The two new functions below will permit us
>>> to detect if h
Ian Romanick writes:
> On 04/09/2013 10:29 AM, Eric Anholt wrote:
>> Ian Romanick writes:
>> I know our hardware doesn't like the swizzling of that bvec compare
>> result and we'd rather just see individual compares as the condition of
>> each if statement. (we basically have to emit a compare
Kenneth Graunke writes:
> On 04/09/2013 03:55 PM, Eric Anholt wrote:
>> Matt Turner writes:
>>
>>> I believe that prog can only be NULL for ARB programs. Neither
>>> brw_fs_fp.cpp nor brw_vec4_vp.cpp call fail(), but not NULL checking
>>> prog is obviously fragile.
>>
>> (shader != NULL) <=> (pr
On 04/10/2013 09:01 AM, Ian Romanick wrote:
From: Ian Romanick
The other dispatch tables (Exec and Save) are freed, but BeginEnd is
never freed. This was found by inspection why investigating the leak of
shared state in _mesa_initialize_context.
NOTE: This is a candidate for stable branches
S
From: Ian Romanick
The other dispatch tables (Exec and Save) are freed, but BeginEnd is
never freed. This was found by inspection why investigating the leak of
shared state in _mesa_initialize_context.
NOTE: This is a candidate for stable branches
Signed-off-by: Ian Romanick
---
src/mesa/mai
From: Ian Romanick
Back up at line 1017 (not shown in patch), we add a reference to the
shared state. Several places after that may divert to the error
handler, but, as far as I can tell, nothing ever unreferences the shared
state.
Fixes issue identified by Klocwork analysis:
Resource acqu
On 04/09/2013 09:01 PM, Paul Berry wrote:
The comment above glsl_type::name claimed that it could sometimes be
NULL. This was wrong--it is never NULL. Many error handling paths
would segfault if it were.
Fix the comment and add assertions to validate that it really is never
NULL.
Right... th
Unlike GEN6, the bits of entry count are distributed like this
width = (entry_count & 0x007f); /* bits [6:0] */
height = (entry_count & 0x001fff80) >> 7; /* bits [20:7] */
depth = (entry_count & 0x7fe0) >> 21; /* bits [30:21] */
The maximum entry count is still limited to 2
The inverse repeat count should taks up bits 31:15 and is in U1.16. Demos
from mesa/demos seem to render correctly with this change, bu piglit
"linestipple" test still fails.
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
Wrong fields were used when dumping width and height.
---
src/mesa/drivers/dri/i965/brw_state_dump.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state_dump.c
b/src/mesa/drivers/dri/i965/brw_state_dump.c
index 9ea3fac..6fc8837 100644
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
> If you were testing with front buffer rendering, GLES doesn't
> support front buffer rendering (because nobody should ever use
> it). I recommend using a debug build of mesa when developing GL
> applications, since it dumps GL error messages t
Hello Ramesh,
currently there is no mesa tree you can fetch, you would need to get the
relevant patches from the maillinglist and apply them manually.
But please be patient, I think I can push the relevant mesa patches to
the master branch today.
Cheers,
Christian.
Am 10.04.2013 06:55, sch
On Mit, 2013-04-10 at 12:59 +0200, Christian König wrote:
> Am 10.04.2013 12:21, schrieb Michel Dänzer:
> > On Mit, 2013-04-10 at 12:07 +0200, Christian König wrote:
> >> Am 10.04.2013 11:46, schrieb Michel Dänzer:
> >>
> >> But why the heck is multiplying with 0x4f80 fixing the result?
> > I'
Am 10.04.2013 12:21, schrieb Michel Dänzer:
On Mit, 2013-04-10 at 12:07 +0200, Christian König wrote:
Am 10.04.2013 11:46, schrieb Michel Dänzer:
From: Michel Dänzer
21 more little piglits with radeonsi.
Signed-off-by: Michel Dänzer
You figured it out, great!
I figured out what? :) This i
On Mit, 2013-04-10 at 12:07 +0200, Christian König wrote:
> Am 10.04.2013 11:46, schrieb Michel Dänzer:
> > From: Michel Dänzer
> >
> > 21 more little piglits with radeonsi.
> >
> > Signed-off-by: Michel Dänzer
> You figured it out, great!
I figured out what? :) This is the same patch I sent ou
Am 10.04.2013 11:46, schrieb Michel Dänzer:
From: Michel Dänzer
21 more little piglits with radeonsi.
Signed-off-by: Michel Dänzer
You figured it out, great! But why the heck is multiplying with
0x4f80 fixing the result?
Cheers,
Christian.
---
v2: Now with lit test.
lib/Target/R6
glsl-fs-loop-nested passes here.
nstack is 3 and adding 4 to it doesn't help.
Marek
On Wed, Apr 10, 2013 at 8:46 AM, Vadim Girlin wrote:
> On 04/10/2013 03:58 AM, Marek Olšák wrote:
>
>> Hi Vadim,
>>
>> your patch does not fix the test.
>>
>
> Hmm, I'm out of ideas then. Thanks for testing.
>
From: Michel Dänzer
21 more little piglits with radeonsi.
Signed-off-by: Michel Dänzer
---
v2: Now with lit test.
lib/Target/R600/SIInstructions.td | 11 +--
test/CodeGen/R600/urecip.ll | 12
2 files changed, 21 insertions(+), 2 deletions(-)
create mode 100644 tes
https://bugs.freedesktop.org/show_bug.cgi?id=63132
--- Comment #3 from José Fonseca ---
I forgot to say: it's trivial to increase the gallivm TEMP limit from 256 to
anything above, but that will do nothing for other non LLVM drivers, e.g.,
svga.
--
You are receiving this mail because:
You are t
1 - 100 of 105 matches
Mail list logo
