Hi;
This series change ir_variable to include a data container for bitfields and
other variables. This helps in variable cloning and serialization, it makes
serialization easier but also much more maintainable.
I divided the moving of variables as multiple patches to not exceed maximum
patch s
This patch moves following bitfields in to the data structure:
explicit_location, explicit_index, explicit_binding,
has_initializer, is_unmatched_generic_inout, location_frac
Signed-off-by: Tapani Pälli
---
src/glsl/ast_to_hir.cpp | 12 ++---
src/glsl/builtin_variables.cpp
Data section helps serialization and cloning of a ir_variable. This
patch includes the helper bits used for read only ir_variables.
Signed-off-by: Tapani Pälli
---
src/glsl/ast_function.cpp | 2 +-
src/glsl/ast_to_hir.cpp | 28 ++--
src/
Patch copies the whole data structure at once instead of
assigning individual variables.
Signed-off-by: Tapani Pälli
---
src/glsl/ir_clone.cpp | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
index d98ed95..
I wanted to keep the old behavior for R600, because it doesn't have
the issue as far as I know.
Marek
On Wed, Dec 4, 2013 at 5:16 AM, Michel Dänzer wrote:
> On Fre, 2013-11-29 at 19:08 +0100, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> If we assume that all buffers allocated by the DDX are sc
---
src/gallium/drivers/radeon/radeon_llvm.h | 5 +++
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 41 +++---
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/radeon_llvm.h
inde
On 11/29/2013 02:52 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> Cc: "10.0"
> ---
>
> Found with valgrind. Don't have the hardware to test a real implementation,
> but with nv50 it seemed to work in that valgrind was no longer marking the
> hash table as leaked.
Reviewed-by: Kenneth Gr
The "layer" parameters used in blorp, and the
intel_renderbuffer::mt_layer field, represent a physical layer rather
than a logical layer. This is important for 2D multisample arrays on
Gen7+ because the UMS and CMS multisample layouts use N physical
layers to represent each logical layer, where N
This will make it easier to add fast color clear support to MSAA
buffers, since they have different alignment and scaling requirements.
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 42 +++
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drive
The hardware blitter doesn't understand multisampled layouts, so
there's no way this could possibly succeed.
---
src/mesa/drivers/dri/i965/intel_pixel_copy.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_copy.c
b/src/mesa/drivers/dri/i965/intel_pix
This patch renames the enum that's used to keep track of fast clear
state from "mcs_state" to "fast_clear_state", and it removes the enum
value INTEL_MCS_STATE_MSAA (which previously meant, "this is an MSAA
buffer, so we're not keeping track of fast clear state"). The only
real purpose that enum v
This series extends the gen7+ fast color clear capability to work with
multisample (MSAA) buffers.
Patch 1 documents some conventions about layer counting that I had to
sleuth out in order to write patch 5. Patch 2 fixes a pre-existing
bug that was previously inadequately piglit tested, but which
Previously, we didn't do multisample blorp clears because we couldn't
figure out how to get them to work. The reason for this was because
we weren't setting the brw_blorp_params num_samples field consistently
with dst.num_samples. Now that those two fields have been collapsed
down into one, we ca
Fast color clears of MSAA buffers work just like fast color clears
with non-MSAA buffers, except that the alignment and scaledown
requirements are different.
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131 +-
1 file changed, 87 insertions(+), 44 deletions(-)
diff
Previously, brw_blorp_params contained two fields for determining
sample count: num_samples (which determined the multisample
configuration of the rendering pipeline) and dst.num_samples (which
determined the multisample configuration of the render target
surface). This was redundant, since both f
On 12/03/2013 09:50 PM, Siavash Eliasi wrote:
Revision 2:
- Avoiding compile error on MSVC and possible warnings on other compilers.
- Added comment regards passing NULL pointer being safe.
---
src/mesa/main/imports.c| 14 +-
src/mesa/math/m_matrix.c |
On 11/23/2013 05:00 PM, Ian Romanick wrote:
Patches 1 through 6 and 9 are
Reviewed-by: Ian Romanick .
I actually wonder if in non-debug builds we should use function aliasing
(or similar) to use generic_noop for all these functions that just set
GL_INVALID_OPERATION. That might be a good newbi
On Tue, Dec 3, 2013 at 11:38 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeonsi/radeonsi_pipe.c | 1 -
> src/gallium/drivers/radeonsi/radeonsi_shader.c | 5 +
> 2 files changed, 1 insertion(+),
May I ask if those fixmes are actually fixed? Otherwise, wouldn't it be
wiser to keep them pointing out this problems?
2013/12/4 Alex Deucher
> On Tue, Dec 3, 2013 at 11:38 PM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > Signed-off-by: Michel Dänzer
>
> Reviewed-by: Alex Deucher
>
On Wed, Dec 4, 2013 at 11:20 AM, Mario Rugiero wrote:
> May I ask if those fixmes are actually fixed? Otherwise, wouldn't it be
> wiser to keep them pointing out this problems?
They are no longer relevant or we'd leave them in. The first hunk,
for example, was just a copy and paste leftover from
Oh, OK then. I thought they maybe were there for a reason other than having
used the other driver as a base.
2013/12/4 Alex Deucher
> On Wed, Dec 4, 2013 at 11:20 AM, Mario Rugiero wrote:
> > May I ask if those fixmes are actually fixed? Otherwise, wouldn't it be
> > wiser to keep them pointin
https://bugs.freedesktop.org/show_bug.cgi?id=70766
--- Comment #5 from Andreas Hartmetz ---
For completeness because I forgot to say it explicitly: Yes, I'm using cmake.
Also hello LLVM, if anybody sees this... that patch is important.
--
You are receiving this mail because:
You are the assigne
On 12/04/2013 06:35 AM, Brian Paul wrote:
> On 11/23/2013 05:00 PM, Ian Romanick wrote:
>> Patches 1 through 6 and 9 are
>>
>> Reviewed-by: Ian Romanick .
>>
>> I actually wonder if in non-debug builds we should use function aliasing
>> (or similar) to use generic_noop for all these functions that
On Sun, Nov 24, 2013 at 9:00 AM, Brian Paul wrote:
> From: Brian Paul
>
> Display lists allocate memory in chunks of 256 tokens (1KB) at a time.
> If an app creates many short display lists or uses glXUseXFont() this
> can waste quite a bit of memory.
>
> This patch uses realloc() to trim short
On Mon, Dec 2, 2013 at 9:46 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> CC: "9.2" "10.0"
For the series:
Reviewed-by: Alex Deucher
> ---
> .../r300/compiler/tests/radeon_compiler_regalloc_tests.c | 11
> +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git
On Wed, Dec 04, 2013 at 03:11:16PM +0100, Vincent Lejeune wrote:
> ---
> src/gallium/drivers/radeon/radeon_llvm.h | 5 +++
> .../drivers/radeon/radeon_setup_tgsi_llvm.c| 41
> +++---
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/src/galli
Reviewed-by: Marek Olšák
Marek
On Wed, Dec 4, 2013 at 5:38 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
> src/gallium/drivers/radeonsi/radeonsi_pipe.c | 1 -
> src/gallium/drivers/radeonsi/radeonsi_shader.c | 5 +
> 2 files changed, 1 insertion(
+ } else {
+ /* From the Ivy Bridge PRM, Vol2 Part1 11.7 "MCS Buffer for Render
+ * Target(s)", beneath the "MSAA Compression" bugget (p326):
bullet?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.
https://bugs.freedesktop.org/show_bug.cgi?id=72230
--- Comment #5 from Matt Turner ---
(In reply to comment #4)
> Would it be possible to provide updated tarballs including this fix?
Doesn't seem worth it.
--
You are receiving this mail because:
You are the assignee for the bug.
__
Matt Turner writes:
> Previously we made the basic block following an ENDIF instruction a
> successor of the basic blocks ending with IF and ELSE. The PRM says that
> IF and ELSE instructions jump *to* the ENDIF, rather than over it.
>
> This should be immaterial to dataflow analysis, except for
Ping.
Just to clarify unsized arrays cannot be assigned so
var->max_array_access will always be 0 as redecorations are already
handled before this point by get_variable_being_redeclared()
This patch is needed as a cleanup for ARB_arrays_of_arrays work. I have
run all glsl piglit tests without reg
https://bugs.freedesktop.org/show_bug.cgi?id=72230
--- Comment #6 from Ian Romanick ---
(In reply to comment #5)
> (In reply to comment #4)
> > Would it be possible to provide updated tarballs including this fix?
>
> Doesn't seem worth it.
...because 10.0.1 will be along shortly.
--
You are r
On 11/24/2013 08:00 AM, Brian Paul wrote:
> From: Brian Paul
>
> Display lists allocate memory in chunks of 256 tokens (1KB) at a time.
> If an app creates many short display lists or uses glXUseXFont() this
> can waste quite a bit of memory.
>
> This patch uses realloc() to trim short lists and
unsubscribe
2013/12/4 Ian Romanick :
> On 11/24/2013 08:00 AM, Brian Paul wrote:
>> From: Brian Paul
>>
>> Display lists allocate memory in chunks of 256 tokens (1KB) at a time.
>> If an app creates many short display lists or uses glXUseXFont() this
>> can waste quite a bit of memory.
>>
>> This
On 11/20/2013 03:41 AM, Timothy Arceri wrote:
> Left over from bug #34376.
I think this shader hits this error message:
#version 120
int x[];
void foo() { x[3] = 2; }
int x[] = int[2](1,2);
do_assignment is also used for initializers. Initializers can be used
to (explicitly)
https://bugs.freedesktop.org/show_bug.cgi?id=72325
Priority: medium
Bug ID: 72325
Keywords: regression
CC: airl...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit glean fbo regression
S
It's come to my attention that Mesa's handling of GL_TEXTURE_BASE_LEVEL and
GL_TEXTURE_MAX_LEVEL in glTexParameter and glGetTexParameter may be
incorrect. The issue happens with the following sequence:
glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE
On 12/04/2013 06:30 AM, Paul Berry wrote:
Fast color clears of MSAA buffers work just like fast color clears
with non-MSAA buffers, except that the alignment and scaledown
requirements are different.
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131 +-
1 file cha
On Wed, Dec 4, 2013 at 1:17 PM, Eric Anholt wrote:
> Matt Turner writes:
>
>> Previously we made the basic block following an ENDIF instruction a
>> successor of the basic blocks ending with IF and ELSE. The PRM says that
>> IF and ELSE instructions jump *to* the ENDIF, rather than over it.
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=72326
Priority: medium
Bug ID: 72326
Keywords: regression
CC: airl...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit glean pbo regression
S
https://bugs.freedesktop.org/show_bug.cgi?id=72327
Priority: medium
Bug ID: 72327
Keywords: regression
CC: airl...@freedesktop.org
Assignee: mesa-dev@lists.freedesktop.org
Summary: [swrast] piglit glean pointSprite regression (ma
https://bugs.freedesktop.org/show_bug.cgi?id=72327
Vinson Lee changed:
What|Removed |Added
Summary|[swrast] piglit glean |[swrast] piglit glean
|po
On Wed, Dec 4, 2013 at 6:30 AM, Paul Berry wrote:
> Fast color clears of MSAA buffers work just like fast color clears
> with non-MSAA buffers, except that the alignment and scaledown
> requirements are different.
> ---
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131
> +---
On 11/20/2013 01:15 PM, Jonas 'Sortie' Termansen wrote:
> POSIX 2008 mandates fpclassify, FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL,
And C99.
> and FP_ZERO are all macros and we can therefore detect them through simple
> preprocessor conditionals on compliant platforms. This avoids further gro
On 12/04/2013 06:30 AM, Paul Berry wrote:
> Fast color clears of MSAA buffers work just like fast color clears
> with non-MSAA buffers, except that the alignment and scaledown
> requirements are different.
> ---
> src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 131
> +-
>
On 12/04/2013 03:07 PM, Chad Versace wrote:
> On 12/04/2013 06:30 AM, Paul Berry wrote:
>> Fast color clears of MSAA buffers work just like fast color clears
>> with non-MSAA buffers, except that the alignment and scaledown
>> requirements are different.
>> ---
>> src/mesa/drivers/dri/i965/brw_bl
From: Dave Airlie
This readback from the frontbuffer with swrast was broken, that bug
just made it more obviously broken, this fixes it by inverting the
sub image gets. Also fixes a few other piglits.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72327
Fixes: https://bugs.freedesktop.org/s
---
src/glx/dri3_glx.c | 4 ++--
src/glx/dri3_priv.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b047cc8..1834c6d 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -676,7 +676,7 @@ dri3_alloc_render_buffer(struct g
On Wed, 2013-12-04 at 14:32 -0800, Ian Romanick wrote:
> On 11/20/2013 03:41 AM, Timothy Arceri wrote:
> > Left over from bug #34376.
>
> I think this shader hits this error message:
>
> #version 120
>
> int x[];
>
> void foo() { x[3] = 2; }
>
> int x[] = int[2](1,2);
>
> do_a
https://bugs.freedesktop.org/show_bug.cgi?id=72335
Priority: medium
Bug ID: 72335
Assignee: mesa-dev@lists.freedesktop.org
Summary: Requesting git commit access to mesa
Severity: normal
Classification: Unclassified
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=72335
--- Comment #1 from Timothy Arceri ---
Created attachment 90291
--> https://bugs.freedesktop.org/attachment.cgi?id=90291&action=edit
Whoops this is the SSH key other attachment was PGP
--
You are receiving this mail because:
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=72335
Timothy Arceri changed:
What|Removed |Added
Attachment #90291|0 |1
is obsolete|
52 matches
Mail list logo
