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
> > + /* 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);
> > +
>
From: Andreas Hartmetz
The only loss of precision here due to intrinsic properties of
unsigned int and float.
---
src/gallium/auxiliary/translate/translate_sse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/translate/translate_sse.c
b/src/gallium
From: Andreas Hartmetz
It is possible that there are multiple input buffers but only one is
relevant for translation. Then there will be only a single translation
group, which might need to source data from a buffer index != 0.
Fixes wrong vertex shader inputs as observed while debugging with
From: Andreas Hartmetz
---
src/gallium/auxiliary/translate/translate_sse.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/translate/translate_sse.c
b/src/gallium/auxiliary/translate/translate_sse.c
index e25d450..8dd30c4 100644
--- a/src/gallium
ug fixes in patches 4 and
5. The others are non-functional changes, mostly for readability.
Andreas Hartmetz (7):
translate_sse: Explain what struct translate_buffer_variant is for.
translate_sse: Rename translate_buffer_variant to translate_group.
translate_sse: Make those comments less
From: Andreas Hartmetz
---
src/gallium/auxiliary/translate/translate_sse.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/auxiliary/translate/translate_sse.c
b/src/gallium/auxiliary/translate/translate_sse.c
index ca02b7a..992c5f6 100644
--- a/src/gallium/auxiliary/translate
From: Andreas Hartmetz
It is a better description of what goes on and it's shorter, too.
---
src/gallium/auxiliary/translate/translate_sse.c | 86 -
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/src/gallium/auxiliary/translate/translate_sse.c
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..03d8276
From: Andreas Hartmetz
---
src/gallium/auxiliary/translate/translate_sse.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/auxiliary/translate/translate_sse.c
b/src/gallium/auxiliary/translate/translate_sse.c
index 1b698cd..24d8017 100644
--- a/src/gallium/auxiliary
On Saturday 01 March 2014 17:09:58 Ilia Mirkin wrote:
> This adds enough code to let drivers implement texture clearing, but
> doesn't actually do that for any of them.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> Thought I'd give this a shot. Am I on the right track here? Is the dd API
> reasonable
Sorry, I did apparently not compile-check some part.
And thanks for fixing it.
On Tuesday 14 January 2014 00:06:05 bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=73578
>
> Vinson Lee changed:
>
>What|Removed |Added
> ---
t; Feel free to push this.
>
> Marek
>
> On Sat, Jan 11, 2014 at 4:20 PM, Andreas Hartmetz
wrote:
> > Continuing here because the threads had diverged...
> >
> > I've updated the patch series under the same URL and applied all the
> > suggested improvements.
Continuing here because the threads had diverged...
I've updated the patch series under the same URL and applied all the
suggested improvements. The variable renames are still in, but at the
very end so they are trivial to omit.
On Tuesday 07 January 2014 17:27:56 Andreas Hartmetz wrote:
commonly occurring rctx/r600 to now more suitable sctx."
> "Rename the commonly occurring rscreen to now more suitable sscreen."
>
> It's too much for my eye to handle.
>
> Marek
>
> On Tue, Jan 7, 2014 at 5:27 PM, Andreas Hartmetz
wrote:
> >
s. I can still do it
when I need to change the patch series anyway, among other things for
the commit messages.
> Assuming that we already moved everything that r600 and radeonsi should
> have in common under drivers/radeon the idea looks good to me.
>
> Christian.
>
> Am 07
ry (branch is master):
git git://anongit.kde.org/scratch/ahartmetz/mesa.git
web http://quickgit.kde.org/?p=scratch%2Fahartmetz%2Fmesa.git
On Monday 06 January 2014 15:50:05 Marek Olšák wrote:
> It sounds good, but I'd like the prefix to be si_ everywhere.
>
> Marek
>
> On Mon,
Hello,
many of the files in radeonsi originally came from other places where
they had different names and were never renamed.
Most of them now have names that don't tell what the files are for
(r600 is not actually the first hardware supported by them, they start
at radeonsi), and even those with
On Thursday 02 January 2014 10:56:45 Lauri Kasanen wrote:
> On Thu, 02 Jan 2014 05:57:46 +0100
>
> Andreas Hartmetz wrote:
> > On Wednesday 01 January 2014 16:58:46 Lauri Kasanen wrote:
> > > @@ -257,6 +258,7 @@ struct radeon_winsys {
> > >
> > >
On Wednesday 01 January 2014 16:58:46 Lauri Kasanen wrote:
>
> @@ -257,6 +258,7 @@ struct radeon_winsys {
> unsigned size,
> unsigned alignment,
> boolean use_reusable_pool,
> +
This is not officially documented, but Marek says it is so.
It also means that HiS was already enabled, we just didn't know it.
---
src/gallium/drivers/radeonsi/si_state.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/
---
src/gallium/drivers/radeonsi/si_state.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index d7d8317..5640013 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/
lšák wrote:
> After reading some docs, I think it should only be set for depth
> buffers without stencil, because it also disables stencil compression.
> Would you like to make a new patch?
>
> Marek
>
> On Fri, Dec 13, 2013 at 4:58 PM, Andreas Hartmetz
wrote:
> > Also
Also move a comment that was in the wrong place.
---
src/gallium/drivers/radeonsi/si_state.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index d99cfe8..ee2372f 100644
--- a/src/gallium/
Here:
git://anongit.kde.org/scratch/ahartmetz/mesa.git
On Wednesday 11 December 2013 20:23:58 Marek Olšák wrote:
> This looks good to me. Can you send me a git link pointing to all your
> patches?
>
> Marek
>
> On Wed, Dec 11, 2013 at 6:50 AM, Andreas Hartmetz
wrote:
>
Removed the now unused db_render_override from si_state_dsa.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
---
src/gallium/drivers/radeonsi/si_state.c | 67 +---
src/gallium/drivers/radeonsi/si_state.h | 4 +-
src/gallium/drivers/radeonsi/si_state_draw.c | 7 +--
3 files changed, 65 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
---
src/gallium/drivers/radeonsi/si_state.c | 67 +---
src/gallium/drivers/radeonsi/si_state.h | 5 ++-
src/gallium/drivers/radeonsi/si_state_draw.c | 7 +--
3 files changed, 66 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
Another attempt at patch 3.
I've picked Marek's suggestion 1, do it like CB_TARGET_MASK.
The other option would probably be a lot less code but also a bit more
"ad hoc" because it relies on the fact that state is only emitted
just before drawing anyway (right?).
I do not quite have the hang of git
---
src/gallium/drivers/radeonsi/si_state.c | 38 +++--
src/gallium/drivers/radeonsi/si_state.h | 2 +-
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 7bae72a..67c
Fixed patch 3, the previous one didn't compile and would also have had
a bug where it didn't compile.
The storage location of db_render_override is a bit dubious, any better
ideas? Create si_db_misc_state? Create si_db_framebuffer_state?
___
mesa-dev mai
This should make the differences and similarities between color and
depth buffer handling more clear.
---
src/gallium/drivers/r600/evergreen_state.c| 10 ++---
src/gallium/drivers/r600/r600_blit.c | 6 +--
src/gallium/drivers/r600/r600_state.c | 10 ++---
src/gallium/drivers/
---
src/gallium/drivers/radeon/r600_texture.c | 82 +--
1 file changed, 67 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index e7ce103..99db4df 100644
--- a/src/gallium/drivers/radeon/
Performance numbers are still the same.
I've addressed almost all the concerns. Registers that shouldn't be
used when depth htile is disabled are still written anyway because
I figured it's no big overhead, simpler, and possibly safer.
si_texture_htile_alloc_size() is modeled after
si_texture_get_c
---
src/gallium/drivers/radeonsi/si_state.c | 33 ++---
src/gallium/drivers/radeonsi/si_state.h | 1 -
2 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 7bae72a..68e8
This adds HyperZ support, without fast clear for now.
I got a lot of help from Marek with this.
There seem to be no piglit regressions; about 60 very basic GL1.0 tests
were skipped in my test run for some reason - they looked very
unrelated. There was no change in other tests.
It does seem to make
---
src/gallium/drivers/radeon/r600_texture.c | 84 +--
1 file changed, 68 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers/radeon/r600_texture.c
index 70f21bd..c91fbce 100644
--- a/src/gallium/drivers/radeon/
This should make the differences and similarities between color and
depth buffer handling more clear.
---
src/gallium/drivers/r600/evergreen_state.c| 10 ++---
src/gallium/drivers/r600/r600_blit.c | 6 +--
src/gallium/drivers/r600/r600_state.c | 10 ++---
src/gallium/drivers/
Reduce scope of variables and divide the code more clearly into
sections dealing with one thing.
---
src/gallium/drivers/radeonsi/si_state.c | 38 +++--
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/galliu
---
src/gallium/drivers/radeonsi/si_state.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 24c9cf3..7b1a6df 100644
--- a/src/gallium/drivers/radeonsi/si_state.
Hello,
I've been lurking for a while, this seems to be my first post.
While trying to make some "easy" (ha) improvements in radeonsi I looked
around in all the surrounding code to get a good picture of how things
work. So I noticed something:
All the Gallium drivers need to implement clear_depth_
r600g needs it too, so add ipo in the common radeon_llvm_check().
radeonsi compiled and linked, but it failed at dynamic link time
with a missing symbol.
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index eef4327..521331b 100
---
configure.ac | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index eef4327..486a4e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1786,6 +1786,7 @@ if test "x$with_gallium_drivers" != x; then
gallium_require_drm_loader
GALLIUM_DRIVER
Looks like the radeonsi build setup relies on other parts to pull
in some dependencies. I seem to have a configuration where some
of them aren't compiled. Mesa compiles without this patch, but
radeonsi_dri.so will fail to load at runtime with missing symbol
LLVMPassManagerBuilderCreate.
My mesa con
On Friday 10 May 2013 14:17:47 Eric Anholt wrote:
> Andreas Hartmetz writes:
> > On Wednesday 08 May 2013 13:33:37 Eric Anholt wrote:
> >> Christoph Brill writes:
> >> > Hi list,
> >> >
> >> > I'm trying to follow the patches and p
On Wednesday 08 May 2013 13:33:37 Eric Anholt wrote:
> Christoph Brill writes:
> > Hi list,
> >
> > I'm trying to follow the patches and patchsets sent to mesa-dev and
> > really like the process of how they get reviewed. It's a good way of
> > catching bugs before they get committed. But current
46 matches
Mail list logo
