On 10/02/2013 12:51 PM, Matt Turner wrote:
> On Wed, Oct 2, 2013 at 11:02 AM, Ian Romanick wrote:
>> (Adding Alan to the CC list.)
>>
>> On 10/01/2013 10:51 PM, Vinson Lee wrote:
>>> On Mon, Sep 30, 2013 at 10:21 PM, Kenneth Graunke
>>> wrote:
On 09/27/2013 06:24 PM, Emil Velikov wrote:
>>>
On 10/01/2013 04:48 PM, Ben Widawsky wrote:
On Tue, Oct 01, 2013 at 01:06:02PM -0700, Chad Versace wrote:
On 09/30/2013 12:35 PM, Ben Widawsky wrote:
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index da523e5..fc3a331 100644
--- a/src/mesa/
On 10/01/2013 04:36 PM, Ben Widawsky wrote:
On Tue, Oct 01, 2013 at 01:06:02PM -0700, Chad Versace wrote:
On 09/30/2013 12:35 PM, Ben Widawsky wrote:
Starting with Ivybridge, the hierarchical had relaxed requirements for
its allocation. Following a "simple" formula in the bspec was all you
need
Reviewed-by: Marek Olšák
Marek
On Thu, Oct 3, 2013 at 11:39 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 4
> src/gallium/drivers/radeonsi/radeonsi_shader.c | 4 ++--
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --
Am 03.10.2013 21:39, schrieb Brian Paul:
> On 10/03/2013 09:42 AM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> They need some special handling. Quite complicated.
>> Additionally, use the same code for implicit derivatives too if
>> no_rho_approx
>> and no_quad_lod is set, because
With commit cb1febb07, I have incorrectly removed HAVE_COMMON_DRI
assuming that swrast does not need to build the translations for
driconf options, as effectively swrast/drisw does not use them.
With the incoming unification work of dri and drisw, it makes
sense just to revert the offending hunk.
On Wed, Oct 2, 2013 at 3:45 PM, Emil Velikov wrote:
> With commit cb1febb07, I have incorrectly removed HAVE_COMMON_DRI
> assuming that swrast does not need to build the translations for
> driconf options, as effectively swrast/drisw does not use them.
>
> With the incoming unification work of dri
From: Tom Stellard
---
src/gallium/drivers/radeon/r600_pipe_common.c | 4
src/gallium/drivers/radeonsi/radeonsi_shader.c | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
i
On 10/03/2013 09:42 AM, srol...@vmware.com wrote:
From: Roland Scheidegger
Not used since ages, and it wouldn't work at all with explicit derivatives now
(not that it did before as it ignored them but now the code would just use
the derivs pre-projected which would be quite random numbers).
---
On 10/03/2013 09:42 AM, srol...@vmware.com wrote:
From: Roland Scheidegger
There's two reasons for this:
1) even when ignoring rho approximation for cube maps, the result is still
not correct, but it's better as the max error at edges is now sqrt(2) instead
of 2 (which was a full mip level), sa
On 10/03/2013 09:42 AM, srol...@vmware.com wrote:
From: Roland Scheidegger
They need some special handling. Quite complicated.
Additionally, use the same code for implicit derivatives too if no_rho_approx
and no_quad_lod is set, because it seems while generally it should be ok
to use per quad l
Niels Ole Salscheider writes:
>> Do you have any example of a real world application that relies on this?
>> Or at least some reasonable use case?
>
> The problem is that the queue is only cleared from already signalled events
> when we flush it. And we might not do this if the user only calls
v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
v3: Store the bool emitted_addc_or_subb in the class, not static.
---
src/mesa/drivers/dri/i965/brw_vec4.h | 3 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 104 -
2 files changed, 106 insertions(+), 1 d
v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.
v3: Store the bool emitted_addc_or_subb in the class, not static.
---
src/mesa/drivers/dri/i965/brw_fs.h | 3 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 104 +++
2 files changed, 107 insertions(+)
diff
It would be good to test HSW too.
Reviewed-by: Jordan Justen
On Wed, 2013-10-02 at 17:50 -0700, Chad Versace wrote:
> In 3DSTATE_DEPTH_BUFFER, we set Width and Height to the miptree slice's
> physical dimensions. (Logical and physical dimensions may differ for
> multisample surfaces).
>
> Howev
From: Roland Scheidegger
Not used since ages, and it wouldn't work at all with explicit derivatives now
(not that it did before as it ignored them but now the code would just use
the derivs pre-projected which would be quite random numbers).
---
src/gallium/auxiliary/gallivm/lp_bld_sample.c | 7
From: Roland Scheidegger
They need some special handling. Quite complicated.
Additionally, use the same code for implicit derivatives too if no_rho_approx
and no_quad_lod is set, because it seems while generally it should be ok
to use per quad lod for implicit derivatives there's at least some te
From: Roland Scheidegger
There's two reasons for this:
1) even when ignoring rho approximation for cube maps, the result is still
not correct, but it's better as the max error at edges is now sqrt(2) instead
of 2 (which was a full mip level), same as it is for ordinary 2d maps when
doing rho appr
> Do you have any example of a real world application that relies on this?
> Or at least some reasonable use case?
The problem is that the queue is only cleared from already signalled events
when we flush it. And we might not do this if the user only calls
clWaitForEvents once the corresponding
> I don't think this is right, with this patch we remove *all* events from
> the command queue, signalled or not, every time the command queue is
> flushed.
You are right, I got the logic wrong here (see also
http://lists.freedesktop.org/archives/mesa-dev/2013-September/044363.html).
The problem
I believe depth clears should not be affected by pipe_depth_state::writemask.
I suspect that the only reason depth mask is not explicitly enable is because
it is a boolean, unlike color/stencil write mask which are proper bitmasks.
Therefore there is no additional information in depth write mask
https://bugs.freedesktop.org/show_bug.cgi?id=70054
Chris Forbes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 10/02/2013 06:11 PM, Chris Forbes wrote:
> Clean up inconsistency in enum decoration:
> - Use the undecorated enums where possible.
> - MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB remains decorated, since it
> has no undecorated equivalent in GL4.
>
> Signed-off-by: Chris Forbes
Bugzilla: htt
23 matches
Mail list logo
