Yes please. Thanks!
-Original Message-
Date: Fri, 11 Apr 2014 08:06:42 -0600
From: Brian Paul bri...@vmware.com
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] softpipe: fix shadow sampling and
remove nonsensical approximation of linear interpolation behavior
Thanks for reviewing and sorry for the huge patch, unfortunately
indentation was wrong all over the place, so it was this or a large number
of smaller patches :-(
I fixed the issues you found and completed the patch to fix some other things
that I missed in my previous patch, mostly about wrong
https://bugs.freedesktop.org/show_bug.cgi?id=73106
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Nothing was bothering to clip the blit. If the src rect was partially
outside the framebuffer, we'd end up picking up more copies of the
edge texels due to clamping.
Note that this is slight overkill -- we could get away with clipping src
only, since fragments outside the destination surface will
For scaled blits, this is not correct. For example, if you blit a
10x10 texture to another 10x10 texture with horizontal scaling of
1.5x, the X texture coordinate of the rightmost pixel should be
6.66. Mesa clip blit doesn't return floating-point coordinates of
the source, so you can't use
Yes, I will remove the flag in the next patch series.
Marek
On Sun, Apr 13, 2014 at 10:45 AM, Christian König
deathsim...@vodafone.de wrote:
For this series: Reviewed-by: Christian König christian.koe...@amd.com
BTW: Can we get rid of RADEON_FLUSH_ASYNC and always flush asynchronously?
Just
On Mon, Apr 14, 2014 at 1:04 PM, Kenneth Graunke kenn...@whitecape.org wrote:
We originally thought that GL 3.0 required GL_DEPTH_COMPONENT16 to map
exactly to Z16. However, we misread the specification, thanks in part
to LaTeX reordering the tables in the PDF.
Page 180 of the GL 3.0
From: José Fonseca jfons...@vmware.com
For Clang static code analyzer, the scan-build script will produce more
comprehensive output. Nevertheless you can invoke it as
CC=clang CXX=clang++ scons analyze=1
For MSVC this is the best way to use its static code analysis. Simply
invoke as
From: José Fonseca jfons...@vmware.com
By accurately detecting gcc/clang through --version option instead
of executable name.
Clang Static Analyzer reports many issues, most false positives, but it
found at least one real and subtle use-after-free issue
in st_texture_get_sampler_view():
From: José Fonseca jfons...@vmware.com
As recommended by
http://clang-analyzer.llvm.org/annotations.html#attr_noreturn
---
src/gallium/auxiliary/util/u_debug.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_debug.h
This unit test demonstrates a subtle bug fixed by
4ddf51db6af36736d5d42c1043eeea86e47459ce.
Signed-off-by: Chia-I Wu o...@lunarg.com
Cc: Eric Anholt e...@anholt.net
---
.../dri/i965/test_vec4_copy_propagation.cpp| 30 ++
1 file changed, 30 insertions(+)
diff --git
From reviewing api/transfer.cpp, it looks like all of the API calls that have
a blocking parameter do not have anything that implement blocking
functionality.
clEnqueueReadBuffer(), clEnqueueWriteBuffer(),
clEnqueueReadBufferRect(), clEnqueueWriteBufferRect(),
clEnqueueReadImage(),
Am 11.04.2014 09:14, schrieb Janzing, Heinrich:
Shadow sampling appeared to be fundamentally broken; fix in
attachment.
This looks ok to me (I put in the comment about this not making sense in
the first place...).
It should be noted though and I'd have preferred if a comment would
still say
Are you saying that the nearest neighbour sampling implementation is still not
entirely correct now? For the linear interpolation case I much prefer the
current imperfect behavior over the previous behavior, though a comment might
still have been in order to highlight the remaining work in that
Dorrington, Albert albert.dorring...@lmco.com writes:
From reviewing api/transfer.cpp, it looks like all of the API calls that have
a blocking parameter do not have anything that implement blocking
functionality.
clEnqueueReadBuffer(), clEnqueueWriteBuffer(),
clEnqueueReadBufferRect(),
I am not too familiar with translate sse code, so someone else should
probably look at it. The rest of the series looks good to me, a comment
inline.
Am 13.04.2014 22:29, schrieb Andreas Hartmetz:
From: Andreas Hartmetz andreas.hartm...@kdab.com
---
Am 14.04.2014 16:32, schrieb Janzing, Heinrich:
Are you saying that the nearest neighbour sampling implementation is
still not entirely correct now?
No this is correct indeed.
For the linear interpolation case I
much prefer the current imperfect behavior over the previous
behavior, though
On 04/14/2014 07:32 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
By accurately detecting gcc/clang through --version option instead
of executable name.
Clang Static Analyzer reports many issues, most false positives, but it
found at least one real and subtle
Fixes crash for r600g in piglit tests
fbo-generatemipmap-3d RGB9_E5
fbo-generatemipmap-array RGB9_E5
Signed-off-by: Sebastian Wick sebast...@sebastianwick.net
---
src/mesa/state_tracker/st_texture.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On 04/14/2014 10:17 AM, Sebastian Wick wrote:
Fixes crash for r600g in piglit tests
fbo-generatemipmap-3d RGB9_E5
fbo-generatemipmap-array RGB9_E5
Signed-off-by: Sebastian Wick sebast...@sebastianwick.net
---
src/mesa/state_tracker/st_texture.c | 3 ++-
1 file changed, 2 insertions(+), 1
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Sent: Monday, April 14, 2014 11:21 AM
To: Dorrington, Albert; mesa-dev@lists.freedesktop.org
Subject: EXTERNAL: Re: [Mesa-dev] Clover clEnqueue* function don't
implement blocking?
Dorrington, Albert
Hi, the tests have already been fixed in the master branch. You seem
to use Mesa code that is quite old. This patch won't apply.
Marek
On Mon, Apr 14, 2014 at 6:17 PM, Sebastian Wick
sebast...@sebastianwick.net wrote:
Fixes crash for r600g in piglit tests
fbo-generatemipmap-3d RGB9_E5
https://bugs.freedesktop.org/show_bug.cgi?id=77443
Priority: medium
Bug ID: 77443
Assignee: mesa-dev@lists.freedesktop.org
Summary: Potential regressions from 1afe3359258a9
Severity: normal
Classification: Unclassified
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=77443
Carl Worth cwo...@cworth.org changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |kenn...@whitecape.org
Dylan Baker baker.dyla...@gmail.com writes:
Carl, the 10.1 branch does not currently build for r600, I get the following
message:
Thanks for testing, Dylan!
As part of my standard list of release steps, I do generally do a build
of all drivers. I guess I just need to get in the habit of doing
On Sat, Apr 12, 2014 at 5:37 PM, Chris Forbes chr...@ijw.co.nz wrote:
This gives us a better bound for some hot loops in the drivers than
MAX_COMBINED_TEXTURE_IMAGE_UNITS, which is ridiculously large on modern
hardware, and only getting worse as more shader stages are added.
Signed-off-by:
Marek Olšák mar...@gmail.com writes:
The patch is probably not necessary. The same applies to patch 2.
Thanks. I've dropped both, and this seems to have fixed the build
problem I had introduced.
I also just force-pushed this new 10.1 branch without the cherry-picked
commit that was causing the
Right, that makes good sense.
On Mon, Apr 14, 2014 at 11:28 PM, Marek Olšák mar...@gmail.com wrote:
For scaled blits, this is not correct. For example, if you blit a
10x10 texture to another 10x10 texture with horizontal scaling of
1.5x, the X texture coordinate of the rightmost pixel should
Dorrington, Albert albert.dorring...@lmco.com writes:
[...]
But when these events are queued, if there isn't a wait(), then what
triggers their flush from the queued_events list? That seems to only
happen when the hard_event::wait() is called (assuming the status is
queued)
Yes, that's
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Depends on||76858
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Priority: medium
Bug ID: 77449
CC: court...@lunarg.com, j...@lunarg.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: Tracker bug for all bugs related to Steam titles
On Sat, Apr 12, 2014 at 10:25 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
Hi everyone,
Some time ago I sent patches to enable the swrast driver on
GBM/DRM, and I did them in the dumbest way possible (that is,
having GBM implement the dri-swrast interface), to make sure
it would
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Sent: Monday, April 14, 2014 4:04 PM
To: Dorrington, Albert; mesa-dev@lists.freedesktop.org
Subject: RE: EXTERNAL: Re: [Mesa-dev] Clover clEnqueue* function don't
implement blocking?
Dorrington, Albert
One program affected:
instructions in affected programs: 246 - 244 (-0.81%)
---
src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
In the process of doing other things, dead code elimination got in my way.
So I killed it.
The new dead code elimination pass uses the liveout set from dataflow
analysis to remove dead instructions. Neither of the two old passes
could, for instance remove a dead write if it was later overwritten
Subsumed by the new dead_code_eliminate() function. No shader-db
changes.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 158 ---
src/mesa/drivers/dri/i965/brw_fs.h | 1 -
2 files changed, 159 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
total instructions in shared programs: 1653399 - 1651790 (-0.10%)
instructions in affected programs: 92157 - 90548 (-1.75%)
GAINED:2
LOST: 2
Also significantly reduces the number of optimization loop iterations:
total loop
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Tapani Pälli lem...@gmail.com changed:
What|Removed |Added
CC||lem...@gmail.com
--
You
Dorrington, Albert albert.dorring...@lmco.com writes:
-Original Message-
From: Francisco Jerez [mailto:curroje...@riseup.net]
Sent: Monday, April 14, 2014 4:04 PM
To: Dorrington, Albert; mesa-dev@lists.freedesktop.org
Subject: RE: EXTERNAL: Re: [Mesa-dev] Clover clEnqueue* function
From: Kenneth Graunke kenn...@whitecape.org
The pass breaks live ranges of virtual registers by allocating new
registers when it sees an assignment to a virtual GRF it's already seen
written.
total instructions in shared programs: 1656292 - 1651898 (-0.27%)
instructions in affected programs:
On Mon, Apr 14, 2014 at 3:01 PM, Matt Turner matts...@gmail.com wrote:
From: Kenneth Graunke kenn...@whitecape.org
The pass breaks live ranges of virtual registers by allocating new
registers when it sees an assignment to a virtual GRF it's already seen
written.
total instructions in shared
Actually, I take it back. There are several reasons for having an explicit flag.
1) Flushes from the state tracker are always synchronous. It's because
the CS ioctl must be finished before libGL sends the SwapBuffers
request to the X server.
2) Flushes before calling buffer_map where
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/drivers/dri/i965/gen7_sol_state.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c
b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index 1b58efb..06a4cdf
gl_ViewportIndex doesn't get its own varying slot. It is stored
in VARYING_SLOT_PSIZ.z. This patch fixes the issue for both gen7
and gen8 because gen7_upload_3dstate_so_decl_list() is shared
between them.
Fixes failures in OpenGL Khronos CTS test transform_feedback_builtins.
Makes new piglit test
gl_Layer doesn't get its own varying slot. It is stored in
VARYING_SLOT_PSIZ.y. This patch fixes the issue for both gen7
and gen8 because gen7_upload_3dstate_so_decl_list() is shared
between them.
Fixes failures in OpenGL Khronos CTS test transform_feedback_builtins.
Makes new piglit test
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the X
Server. Today we decided that the problem in compositors was equivalent
to a corruption bug we'd noticed recently in resizing MSAA-visual
glxgears, and
Matt Turner matts...@gmail.com writes:
One program affected:
instructions in affected programs: 246 - 244 (-0.81%)
---
src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git
From: Andreas Hartmetz andreas.hartm...@kdab.com
---
src/gallium/auxiliary/translate/translate_sse.c | 35 -
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/translate/translate_sse.c
b/src/gallium/auxiliary/translate/translate_sse.c
+ /* right shift convert, losing the low bit - must clear
+* high bit because there is no unsigned convert
instruction */
sse2_psrld_imm(p-func, dataXMM, 1);
+ sse2_cvtdq2ps(p-func, dataXMM, dataXMM);
+
+
Matt Turner matts...@gmail.com writes:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
new file mode 100644
index 000..6addbb3
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
On 04/14/2014 05:33 PM, Eric Anholt wrote:
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the X
Server. Today we decided that the problem in compositors was equivalent
to a corruption bug we'd noticed
Are the streamout values allowed to be restricted to the ranges of the
vertex header fields, or do they have to reflect exactly what the
shader wrote?
(I ran into a similar issue with ARB_fragment_layer_viewport, and
while nothing has been done about it, the consensus was that the FS
had to see
On Mon, Apr 14, 2014 at 5:50 PM, Eric Anholt e...@anholt.net wrote:
Matt Turner matts...@gmail.com writes:
One program affected:
instructions in affected programs: 246 - 244 (-0.81%)
---
src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 7 +++
1 file changed, 7
On Mon, Apr 14, 2014 at 5:59 PM, Eric Anholt e...@anholt.net wrote:
Matt Turner matts...@gmail.com writes:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
new file mode 100644
index 000..6addbb3
---
On 04/14/2014 05:33 PM, Eric Anholt wrote:
This manifested as rendering failures or sometimes GPU hangs in
compositors when they accidentally got MSAA visuals due to a bug in the X
Server. Today we decided that the problem in compositors was equivalent
to a corruption bug we'd noticed
From: Michel Dänzer michel.daen...@amd.com
The transfer staging texture is always freshly allocated, so for write-only
transfers we don't need to explicitly wait for the BO to become idle.
Squeezes a few hundered MB/s more out of x11perf -shmput500 with glamor.
Signed-off-by: Michel Dänzer
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Nicholas Miell nmi...@gmail.com changed:
What|Removed |Added
Depends on||66067
--
You are
57 matches
Mail list logo
