On 10/07/2012 06:34 PM, Kenneth Graunke wrote:
On 10/07/2012 06:06 PM, Paul Berry wrote:
On 7 October 2012 15:38, Kenneth Graunke mailto:kenn...@whitecape.org>> wrote:
On 10/07/2012 02:40 PM, Daniel Vetter wrote:
On Fri, Oct 05, 2012 at 05:08:04PM -0700, Kenneth Graunke wrote:
On 10/07/2012 08:33 PM, Ian Romanick wrote:
On 10/05/2012 05:36 PM, Kenneth Graunke wrote:
On 10/05/2012 03:56 PM, Ian Romanick wrote:
From: Ian Romanick
The diff looks weird, but this moves the code from the first 'if
(ctx->Const.GLSLVersion < 130)' block down into the second block. It
also
On 10/05/2012 05:36 PM, Kenneth Graunke wrote:
On 10/05/2012 03:56 PM, Ian Romanick wrote:
From: Ian Romanick
The diff looks weird, but this moves the code from the first 'if
(ctx->Const.GLSLVersion < 130)' block down into the second block. It
also moves some variable decalarations closer to
On 09/22/2012 02:04 PM, Eric Anholt wrote:
Use a simple chaining hash table for the ACP. This is not really very good,
because we still do a full walk of the tree per destination write, but it
still reduces fp-long-alu runtime from 5.3 to 3.9s.
---
src/mesa/drivers/dri/i965/brw_fs.h
On 09/22/2012 02:04 PM, Eric Anholt wrote:
This means that we don't get constant prop across into the first block after a
BRW_OPCODE_IF or a BRW_OPCODE_DO, but we have hope for properly doing it
across control flow at some point. More importantly, it avoids the O(n^2)
with instruction count runt
On 10/07/2012 06:06 PM, Paul Berry wrote:
On 7 October 2012 15:38, Kenneth Graunke mailto:kenn...@whitecape.org>> wrote:
On 10/07/2012 02:40 PM, Daniel Vetter wrote:
On Fri, Oct 05, 2012 at 05:08:04PM -0700, Kenneth Graunke wrote:
According to internal bug reports, guar
On 7 October 2012 15:38, Kenneth Graunke wrote:
> On 10/07/2012 02:40 PM, Daniel Vetter wrote:
>
>> On Fri, Oct 05, 2012 at 05:08:04PM -0700, Kenneth Graunke wrote:
>>
>>> According to internal bug reports, guardband clipping sometimes
>>> incorrectly discards triangles unless bit 5 of 3D_CHICKEN
On 10/02/2012 07:52 PM, Eric Anholt wrote:
Based on split_virtual_grfs(), we choose the same set every time, so set it in
stone. This will help us avoid regenerating the somewhat expensive
class/register set setup every compile.
---
src/mesa/drivers/dri/i965/brw_fs.h|1 +
On 10/03/2012 10:30 AM, Eric Anholt wrote:
Without this, we'd spill one reg, then continue on without actually register
allocating, then assertion fail when we tried to use a vgrf number as a
register number.
---
src/mesa/drivers/dri/i965/brw_vec4.h|4 ++--
src/mesa/drivers
On 10/04/2012 04:07 PM, Eric Anholt wrote:
This is derived from the FS visitor code for the same, but tracks each channel
separately (otherwise, some typical fill-a-channel-at-a-time patterns would
produce excessive live intervals across loops and produce spilling).
---
src/mesa/drivers/dri/i96
On 10/04/2012 04:07 PM, Eric Anholt wrote:
For tracking live variables, we want to know when a register is completely
rewritten, so we need to be able to compare a writemask to the size of the
register. There's also potential use for this in register coalescing.
Two comments:
1. Please move t
This improves performance a little bit if there are lots of small indexed
draw commands.
---
src/gallium/drivers/r600/r600_state_common.c | 41 +-
src/gallium/drivers/r600/r600d.h |1 +
2 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/src/g
---
src/gallium/drivers/r600/Makefile.sources|1 -
src/gallium/drivers/r600/r600_pipe.h |5 ---
src/gallium/drivers/r600/r600_state_common.c | 28 +++---
src/gallium/drivers/r600/r600_translate.c| 53 --
4 files changed, 22 insertions(+),
On 10/04/2012 04:07 PM, Eric Anholt wrote:
This should improve our ability to register allocate without spilling.
Unfortuantely, due to the live variable analysis being ignorant of loops, we
still have register allocation failures on some programs.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp
On 10/04/2012 04:07 PM, Eric Anholt wrote:
We're always doing it for an immediately preceding instruction, and we can
make that instruction write directly into the MRF instead of using a
temporary.
Along with reducing instructions, it avoids confusing the upcoming live
variables code (which saw
On 10/04/2012 04:07 PM, Eric Anholt wrote:
This is super basic, but it let me visualize a problem I had with
opt_compute_to_mrf().
---
src/mesa/drivers/dri/i965/brw_context.h |8 +++
src/mesa/drivers/dri/i965/brw_disasm.c |7 +--
src/mesa/drivers/dri/i965/brw_vec4.cpp | 83 +++
On 10/07/2012 02:40 PM, Daniel Vetter wrote:
On Fri, Oct 05, 2012 at 05:08:04PM -0700, Kenneth Graunke wrote:
According to internal bug reports, guardband clipping sometimes
incorrectly discards triangles unless bit 5 of 3D_CHICKEN3 ("SF Disable
fastclip optimization when culled") is set.
Exper
On Wed, Jul 18, 2012 at 8:35 AM, Jose Fonseca wrote:
>
>
> - Original Message -
>> Am 18.07.2012 07:11, schrieb Marek Olšák:
>> > On Wed, Jul 18, 2012 at 1:58 AM, Roland Scheidegger
>> > wrote:
>> >> Am 17.07.2012 23:49, schrieb Stéphane Marchesin:
>> >>> On Mon, Jul 16, 2012 at 11:43 AM,
On Fri, Oct 05, 2012 at 05:08:04PM -0700, Kenneth Graunke wrote:
> According to internal bug reports, guardband clipping sometimes
> incorrectly discards triangles unless bit 5 of 3D_CHICKEN3 ("SF Disable
> fastclip optimization when culled") is set.
>
> Experimentally, this appears to be true. W
---
src/gallium/drivers/r600/eg_asm.c| 17
src/gallium/drivers/r600/r600_asm.c | 17
src/gallium/drivers/r600/r600_asm.h | 2 +
src/gallium/drivers/r600/r600_llvm.c | 66
src/gallium/drivers/r600/r600_shader.c | 53 +++
---
src/gallium/drivers/radeon/AMDGPUISelLowering.cpp | 1 +
src/gallium/drivers/radeon/AMDGPUISelLowering.h| 1 +
.../radeon/MCTargetDesc/R600MCCodeEmitter.cpp | 11 +-
src/gallium/drivers/radeon/R600ISelLowering.cpp| 68
src/gallium/drivers/radeon/R600Instruction
---
src/gallium/drivers/r600/r600_hw_context.c | 10 +-
src/gallium/drivers/r600/r600_pipe.h |8 +++-
src/gallium/drivers/r600/r600_state.c | 18 ++
3 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw_cont
Also update the register value in more appropriate places
than r600_update_derived_state.
---
src/gallium/drivers/r600/evergreen_hw_context.c |2 --
src/gallium/drivers/r600/evergreen_state.c | 24 ++-
src/gallium/drivers/r600/r600_hw_context.c |2 --
src/ga
---
src/gallium/drivers/r600/evergreen_state.c |8
src/gallium/drivers/r600/r600_state.c |4
2 files changed, 12 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index bc3aedb..2e58a28 100644
--- a/src/g
---
src/gallium/drivers/r600/evergreen_hw_context.c |2 --
src/gallium/drivers/r600/evergreen_state.c | 14 ++--
src/gallium/drivers/r600/r600_blit.c|2 +-
src/gallium/drivers/r600/r600_hw_context.c |3 ++-
src/gallium/drivers/r600/r600_pipe.c
---
src/gallium/drivers/r600/evergreen_hw_context.c | 18
src/gallium/drivers/r600/evergreen_state.c | 114 ++---
src/gallium/drivers/r600/r600_blit.c|2 +-
src/gallium/drivers/r600/r600_hw_context.c | 12 +--
src/gallium/drivers/r600/r600_pipe.h
Some variables have been removed from there too.
---
src/gallium/drivers/r600/evergreen_state.c |5 +-
src/gallium/drivers/r600/r600_pipe.h | 144 --
src/gallium/drivers/r600/r600_state.c|5 +-
src/gallium/drivers/r600/r600_state_common.c | 18 +
---
src/gallium/drivers/r600/r600_hw_context.c | 32 --
src/gallium/drivers/r600/r600_state.c | 40 +---
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600
The workaround for R600 lacking VPORT_SCISSOR_ENABLE has also been simplified.
---
src/gallium/drivers/r600/evergreen_hw_context.c |4 --
src/gallium/drivers/r600/evergreen_state.c | 24 ++--
src/gallium/drivers/r600/r600_blit.c|2 +-
src/gallium/drivers/r600/r60
POLY_OFFSET_DB_FMT_CNTL is moved to the framebuffer state, because it only
depends on the zbuffer format.
---
src/gallium/drivers/r600/evergreen_hw_context.c | 10 ---
src/gallium/drivers/r600/evergreen_state.c | 105 ---
src/gallium/drivers/r600/r600_hw_context.c
The state object is actually a buffer, it's literally a buffer containing
the shader code.
---
src/gallium/drivers/r600/evergreen_hw_context.c |2 -
src/gallium/drivers/r600/evergreen_state.c | 25 -
src/gallium/drivers/r600/r600_asm.c | 63 +++
---
src/gallium/drivers/r600/r600_pipe.h |1 -
src/gallium/drivers/r600/r600_shader.c |2 +-
src/gallium/drivers/r600/r600_state_common.c |4 +++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r6
This is not so trivial, because we disable blending if the dual src
blending is turned on and the number of color outputs is less than 2.
I decided to create 2 command buffers in the blend state object and just
switch between them when needed, because there are other states unrelated
to blending (l
---
src/gallium/drivers/r600/evergreen_compute.c |2 +-
src/gallium/drivers/r600/evergreen_state.c | 12
src/gallium/drivers/r600/r600_blit.c |6 ++--
src/gallium/drivers/r600/r600_hw_context.c | 26 +-
src/gallium/drivers/r600/r600_pipe.h |
r600_command_buffer is not an atom.
The "atoms" have evolved into state slots (or groups of state slots) where
you can bind states. There is a fixed amount of atoms (state slots)
in the context.
The command buffers are nothing like that. They represent states, not state
slots.
We could probably
On 10/06/2012 06:44 PM, Mario Kleiner wrote:
The GL_POINT_BIT state attribute GL_POINT_SPRITE_COORD_ORIGIN
is only supported on OpenGL-2.0 or later. Prevent glPopAttrib()
from trying to restore it on OpenGL-1.4 implementations which
support GL_ARB_POINT_SPRITE, as otherwise the sequence...
glPus
36 matches
Mail list logo
