https://bugs.freedesktop.org/show_bug.cgi?id=65514
Karl Tomlinson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Jun 11, 2013 at 5:08 PM, Eric Anholt wrote:
> The is_power_of_two() inline function has been used instead.
> ---
> src/mesa/drivers/dri/intel/intel_context.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_context.h
> b/src/mesa/drivers/dri/inte
Am 11.06.2013 05:39, schrieb Zack Rusin:
> There are strict limits on those registers. Define the maximums
> and use them instead of magic numbers. Also allows us to add
> some extra sanity checks.
> Suggested by Brian.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/draw/draw_contex
The is_power_of_two() inline function has been used instead.
---
src/mesa/drivers/dri/intel/intel_context.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 5420e76..1002dcb 100644
--- a/src/mesa/dri
There are strict limits on those registers. Define the maximums
and use them instead of magic numbers. Also allows us to add
some extra sanity checks.
Suggested by Brian.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c |2 ++
src/gallium/auxiliary/draw/draw_gs.c
We don't need the clamped variable, because we can just
return early. We should also do the regular culling after
the distance culling passes.
All spotted by Brian.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_pipe_cull.c | 79 ---
1 file changed, 36 in
Paul Berry writes:
> Changes since the previous version:
>
> - Because of objections, I've dropped the patch "intel: Create
> intel_miptree_get_region() to prepare for fast color clear."
> Instead of using an accessor function to ensure that appropriate
> resolves are performed before any a
On 11 June 2013 16:11, Eric Anholt wrote:
> Paul Berry writes:
>
> > +/**
> > + * Determine if fast color clear supports the given clear color.
> > + *
> > + * Fast color clear can only clear to color values of 1.0 or 0.0. At
> the
> > + * moment we only support floating point buffers.
>
> floa
Paul Berry writes:
> +/**
> + * Determine if fast color clear supports the given clear color.
> + *
> + * Fast color clear can only clear to color values of 1.0 or 0.0. At the
> + * moment we only support floating point buffers.
floating point, unorm, or snorm buffers, right?
> diff --git a/sr
On 06/11/2013 01:57 PM, Chad Versace wrote:
On 06/11/2013 01:39 PM, Ian Romanick wrote:
On 06/11/2013 01:27 PM, Chad Versace wrote:
On 06/08/2013 01:05 PM, Ian Romanick wrote:
From: Ian Romanick
This has the (intended!) side effect that vertex shader inputs and
fragment shader outputs will a
On 06/10/2013 10:52 AM, Ian Romanick wrote:
From: Ian Romanick
This will be used in the next commit.
NOTE: This is a candidate for stable release branches.
Signed-off-by: Ian Romanick
---
src/mesa/main/uniform_query.cpp| 2 +-
src/mesa/main/uniforms.c | 2 +-
Allows MSAA colorbuffers, which have a CMASK automatically and don't
need any further special handling, to be fast cleared. Instead
of clearing the buffer, set the clear color and the CMASK to the
cleared state.
Fast clear is used only when all bound colorbuffers fulfill certain
conditions: a CMAS
Kenneth Graunke writes:
> Previously, we would:
> 1. Emit the new indirect state.
> 2. Flag CACHE_NEW_BLEND_STATE.
> 3. Rely on later state atoms to notice CACHE_NEW_BLEND_STATE and emit a
>pointer to the new indirect state.
>
> This is rather cumbersome: it requires two state atoms instead o
Roland, that was great, you caught a lot of stuff, thanks!
- Original Message -
> Am 10.06.2013 16:31, schrieb Zack Rusin:
> > Works similarly to clip distance. If the cull distance is negative
> > for all vertices against a specific plane then the primitive
> > is culled.
> >
> > Signed-
Thanks a lot for the reviews Brian!
- Original Message -
> On 06/10/2013 08:31 AM, Zack Rusin wrote:
> > Works similarly to clip distance. If the cull distance is negative
> > for all vertices against a specific plane then the primitive
> > is culled.
> >
> > Signed-off-by: Zack Rusin
> >
On 06/11/2013 01:39 PM, Ian Romanick wrote:
On 06/11/2013 01:27 PM, Chad Versace wrote:
On 06/08/2013 01:05 PM, Ian Romanick wrote:
From: Ian Romanick
This has the (intended!) side effect that vertex shader inputs and
fragment shader outputs will appear in the IR in the same order that
they a
On 06/10/2013 03:54 PM, Fredrik Höglund wrote:
On Monday 10 June 2013, Brian Paul wrote:
On 06/10/2013 11:52 AM, Ian Romanick wrote:
From: Ian Romanick
Previously we would generate uniform locations as (slot << 16) +
array_index. We do this two handle applications that assume the
to handle
On 06/11/2013 01:27 PM, Chad Versace wrote:
On 06/08/2013 01:05 PM, Ian Romanick wrote:
From: Ian Romanick
This has the (intended!) side effect that vertex shader inputs and
fragment shader outputs will appear in the IR in the same order that
they appeared in the shader code. This results in
On 06/08/2013 01:05 PM, Ian Romanick wrote:
From: Ian Romanick
This has the (intended!) side effect that vertex shader inputs and
fragment shader outputs will appear in the IR in the same order that
they appeared in the shader code. This results in the locations being
assigned in the declared
Yes, it is fixed now. I had to revert the proposed patch from
beginning of this thread too.
Thank you,
Vedran
On Tue, Jun 11, 2013 at 7:54 PM, Kenneth Graunke wrote:
> On 06/10/2013 10:55 PM, Vedran Rodic wrote:
>>
>> On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke
>> wrote:
>>>
>>>
>>> Vedra
> > + unsigned clipdistance_output[2];
>
> Why 2? Are there four clip distances per register, and we need 8 (or
> 6?) of them? Maybe add some comments.
Hmm, I thought we already had a documentation for it. It's the same code that
we already have in the vertex shader, just extending it to geo
On 06/10/2013 10:55 PM, Vedran Rodic wrote:
On Tue, Jun 11, 2013 at 1:03 AM, Kenneth Graunke wrote:
Vedran,
Can you try this patch and see if it solves your GPU hang issues? I still
haven't been able to reproduce it, but I believe I may just be getting lucky.
Nope, with this one it's even
Frank Henigman writes:
> Replace the one texture lock with a lock per texture. This allows
> uploading textures from one thread concurrently with drawing in another
> thread. _mesa_lock_context_textures() was used to check for texture
> updates from other contexts and also to acquire the textur
Am 10.06.2013 16:31, schrieb Zack Rusin:
> Works similarly to clip distance. If the cull distance is negative
> for all vertices against a specific plane then the primitive
> is culled.
>
> Signed-off-by: Zack Rusin
> ---
> src/gallium/auxiliary/draw/draw_context.c | 17
> src/galli
On 06/10/2013 02:35 PM, Frank Henigman wrote:
Replace the one texture lock with a lock per texture. This allows
uploading textures from one thread concurrently with drawing in another
thread. _mesa_lock_context_textures() was used to check for texture
updates from other contexts and also to acq
Am 10.06.2013 16:31, schrieb Zack Rusin:
> cull distance is analogous to clip distance. If a register is
> given this semantic, then the values in it are assumed to be a
> float32 distance to a plane. Primitives will be completely
> discarded if the plane distance for all of the vertices in
> the p
Am 10.06.2013 16:31, schrieb Zack Rusin:
> We need to figure out the number of invocations of the clipper
> before the emit, because in the emit we are after clipping
> where the number of primitives will be equal to number of clipper
> invocations minus the clipped primitives. So our computations
Am 10.06.2013 16:31, schrieb Zack Rusin:
> Draw depended on clip_plane_enable being set in the rasterizer
> to use clipdistance registers for clipping. That's really
> unfriendly because it requires that rasterizer state to have
> variants for every shader out there. Instead of depending on
> the r
On 06/10/2013 08:31 AM, Zack Rusin wrote:
Works similarly to clip distance. If the cull distance is negative
for all vertices against a specific plane then the primitive
is culled.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c | 17
src/gallium/auxiliar
On 06/10/2013 08:31 AM, Zack Rusin wrote:
cull distance is analogous to clip distance. If a register is
given this semantic, then the values in it are assumed to be a
float32 distance to a plane. Primitives will be completely
discarded if the plane distance for all of the vertices in
the primitiv
On 06/10/2013 08:31 AM, Zack Rusin wrote:
We need to figure out the number of invocations of the clipper
before the emit, because in the emit we are after clipping
where the number of primitives will be equal to number of clipper
invocations minus the clipped primitives. So our computations
were
On 06/10/2013 08:31 AM, Zack Rusin wrote:
Draw depended on clip_plane_enable being set in the rasterizer
to use clipdistance registers for clipping. That's really
unfriendly because it requires that rasterizer state to have
variants for every shader out there. Instead of depending on
the rasteriz
On 06/10/2013 08:31 AM, Zack Rusin wrote:
we were always fetching the info from the vertex shader, but if
geometry shader is present it should be used as the source of
that info.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_cliptest_tmp.h |3 ++-
src/gallium/auxiliary/dr
On Tue, Jun 11, 2013 at 4:52 PM, Grigori Goronzy wrote:
> On 11.06.2013 02:41, Marek Olšák wrote:
>>> +
>>> + /* cannot pack color, needs support in u_format */
>>> + if (desc->pack_rgba_float == NULL) {
>>> + return false;
>>> + }
>>
On 11.06.2013 02:41, Marek Olšák wrote:
>> +
>> + /* cannot pack color, needs support in u_format */
>> + if (desc->pack_rgba_float == NULL) {
>> + return false;
>> + }
>
> Hi Grirogi,
>
> Is this for disallowing integer textures? You
https://bugs.freedesktop.org/show_bug.cgi?id=64935
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Jun 11, 2013 at 3:16 AM, Roland Scheidegger wrote:
> Am 11.06.2013 02:41, schrieb Marek Olšák:
>>
>> Hi Grirogi,
>>
>> Is this for disallowing integer textures? You probably wanted to use
>> util_format_is_pure_integer, which is more clear. pack_rgba_float
>> should be non-NULL for every n
Kenneth Graunke writes:
> Previously, we would:
> 1. Emit the new indirect state.
> 2. Flag CACHE_NEW_BLEND_STATE.
> 3. Rely on later state atoms to notice CACHE_NEW_BLEND_STATE and emit a
>pointer to the new indirect state.
>
> This is rather cumbersome: it requires two state atoms instead o
38 matches
Mail list logo
