On 08.04.2014 00:31, Timo Aaltonen wrote:
> On 12.03.2014 10:43, Kenneth Graunke wrote:
>> arekm reported that using Chrome with GPU acceleration enabled on GM45
>> triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.
>>
>> We definitely do not want to advertise reset notificati
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Nicholas Miell changed:
What|Removed |Added
Depends on||66067
--
You are receiving this mail b
From: Michel Dänzer
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
---
src/gallium/drivers/r
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 rece
On Mon, Apr 14, 2014 at 5:59 PM, Eric Anholt wrote:
> Matt Turner 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/dr
On Mon, Apr 14, 2014 at 5:50 PM, Eric Anholt wrote:
> Matt Turner 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 --gi
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 ex
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 rece
Matt Turner 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
> +
> +/** @fi
From: Andreas Hartmetz
---
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
index dace722..2a0d3c1 1006
> > + /* 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 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 a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>
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 debuggin
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 glsl-1.5
Cc:
Signed-off-by: Anuj Phogat
---
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 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.
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 synchronizat
On Mon, Apr 14, 2014 at 3:01 PM, Matt Turner wrote:
> From: Kenneth Graunke
>
> 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
From: Kenneth Graunke
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: 466836 -> 462442 (-0
"Dorrington, Albert" 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 don't
>> impleme
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Tapani Pälli changed:
What|Removed |Added
CC||lem...@gmail.com
--
You are receiving th
On 04/14/2014 06:30 AM, Chia-I Wu wrote:
> On Mon, Apr 14, 2014 at 1:04 PM, Kenneth Graunke
> 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.
>>
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
b/src/me
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 ite
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
u
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
b/src/mesa/drivers/dri/i965/brw_fs_dea
> -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, Albe
On Sat, Apr 12, 2014 at 10:25 AM, Giovanni Campagna
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 work without kernel su
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
Severit
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Ian Romanick changed:
What|Removed |Added
Depends on||76858
--
You are receiving this mail bec
"Dorrington, Albert" 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 right, or when clFlush(
Right, that makes good sense.
On Mon, Apr 14, 2014 at 11:28 PM, Marek Olšák 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 be
> 6.66.
Marek Olšák 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 build failure. I
On Sat, Apr 12, 2014 at 5:37 PM, Chris Forbes 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: Chris Forbes
Dylan Baker 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 this
before pushing t
https://bugs.freedesktop.org/show_bug.cgi?id=77443
Carl Worth changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |kenn...@whitecape.org
|or
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: Al
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
wrote:
> Fixes crash for r600g in piglit tests
> fbo-generatemipmap-3d RGB9_E5
> fbo-generatemipmap-array RGB9_E5
> -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"
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
---
src/mesa/state_tracker/st_texture.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/m
Fixes crash for r600g in piglit tests
fbo-generatemipmap-3d RGB9_E5
fbo-generatemipmap-array RGB9_E5
Signed-off-by: Sebastian Wick
---
src/mesa/state_tracker/st_texture.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_texture.c
b/src/mesa/state_t
On 04/14/2014 07:32 AM, jfons...@vmware.com wrote:
From: José Fonseca
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_tex
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, thou
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
>
> ---
> src/gallium/auxiliary/translate/translate_sse.c | 35
> ++
"Dorrington, Albert" 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(), clEnqueueWriteBufferR
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
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
>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(), clEnqueueW
This unit test demonstrates a subtle bug fixed by
4ddf51db6af36736d5d42c1043eeea86e47459ce.
Signed-off-by: Chia-I Wu
Cc: Eric Anholt
---
.../dri/i965/test_vec4_copy_propagation.cpp| 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/test_
From: José Fonseca
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
b/src/gallium/auxiliary/util/u_debug.h
index
From: José Fonseca
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():
http://people.freedeskto
From: José Fonseca
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
scons analyze=1
---
com
On Mon, Apr 14, 2014 at 1:04 PM, Kenneth Graunke 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 specification (glspec30.
Yes, I will remove the flag in the next patch series.
Marek
On Sun, Apr 13, 2014 at 10:45 AM, Christian König
wrote:
> For this series: Reviewed-by: Christian König
>
> BTW: Can we get rid of RADEON_FLUSH_ASYNC and always flush asynchronously?
> Just calling cs_sync_flush directly after the flu
Dear colleagues,
I am proud to announce the publication of my latest book:
"Digital Video and Television", by Prof Ioannis Pitas, 2013.
The book provides the most up-to-date introduction to digital video and
television. The entire process is covered, from video production, to its
delivery
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 them
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
https://bugs.freedesktop.org/show_bug.cgi?id=73106
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 in
Yes please. Thanks!
-Original Message-
Date: Fri, 11 Apr 2014 08:06:42 -0600
From: Brian Paul
To: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] softpipe: fix shadow sampling and
remove nonsensical approximation of linear interpolation behavior for
shadow s
60 matches
Mail list logo
