Marek Olšák writes:
> 1) The tabs are used in the entire file. They might have got there
> while I was moving some of the bits of code around. I don't really use
> tabs for core Mesa work. I can change the tabs to spaces unless you
> mean I should change everything to tabs (you didn't make that c
On Tue, May 21, 2013 at 10:11:17PM -0700, Chad Versace wrote:
> On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
> >No functional change in preparation for supporting multiple planes
> >per image each having its own region.
> >
> >Signed-off-by: Topi Pohjolainen
> >---
> > src/mesa/drivers/dri/int
- Original Message -
> Hi Jose,
>
> Thanks for the review.
>
> Jose Fonseca writes:
> > - Original Message -
> >> From: Richard Sandiford
> >>
> >> RGBA has R at byte 0 and A at byte 3, regardless of platform
> >> endianness.
> >
> > Maybe I'm missing something, but this
Sounds definitely an improvement.
Long term I think the cache is probably not worth to keep any texture cache at
all.
Jose
- Original Message -
> From: Roland Scheidegger
>
> Initially we had NUM_TEX_TILE_ENTRIES of 50, however this was using too much
> memory (mostly because the tile
On 05/02/2013 12:08 AM, Topi Pohjolainen wrote:
No functional change in preparation for supporting multiple planes
per image each having its own region.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/intel/intel_fbo.c | 6 +--
src/mesa/drivers/dri/intel/intel_regions.h |
Rather than pointing the surface_state directly at a single
sub-image of the texture for rendering, we now point the
surface_state at the top level of the texture, and configure
the surface_state as needed based on this.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_defines.h
OK, I'll add the spec quote and fixup the two piglits which are
asserting the old behavior, and push it all tonight.
-- Chris
On Wed, May 22, 2013 at 9:33 AM, Ian Romanick wrote:
> On 05/18/2013 11:18 PM, Chris Forbes wrote:
>>
>> Relaxes the validation of
>>
>> OPTION ARB_precision_hint_{ni
From: Roland Scheidegger
Initially we had NUM_TEX_TILE_ENTRIES of 50, however this was using too much
memory (mostly because the tile cache is operating on fixed max current
sampler views which could be fixed but that's another topic). So it was
decreased to 4. However this is a ridiculously low
From: Roland Scheidegger
These can be different (just like NUM_TEX_TILE_ENTRIES / NUM_ENTRIES),
though currently they aren't.
---
src/gallium/drivers/softpipe/sp_tex_sample.c | 28 +++---
src/gallium/drivers/softpipe/sp_tex_tile_cache.c | 28 +++---
src/ga
We were expanding the live range too far, breaking register_coalesce_2()
and compute_to_mrf() on 16-wide shaders. Turning it back on improves
GLB2.7 performance by 0.239355% +/- 0.0850649% (n=398), though some
16-wide shaders are lost. shader-db stats are:
total instructions in shared programs:
The scheduler didn't know about uniform-type accesses, and if a uniform
access was last in a 16-wide, we'd walk off the end of the array. This
never happened, because we'd never coalesce out all the GRFs, due to a bug
to be fixed in the next commit.
---
src/mesa/drivers/dri/i965/brw_schedule_inst
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index b7bbaab..36d9cf0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/
i965 and radeon use ra_set_node_reg() to force payload registers to
specific registers while exposing those registers to the allocator still.
We were treating those register nodes as unsuccessfully allocated in the
ra_simplify() step, leading to walking the registers again to do
optimistic coloring
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59440
---
src/mesa/drivers/dri/intel/intel_pixel_bitmap.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
b/src/mesa/drivers/dri/intel/intel_pixel_bitma
On 21 May 2013 16:52, Paul Berry wrote:
> This series implements fast color clears, a Gen7+ feature which
> reduces memory bandwidth by deferring the memory writes involved in a
> glClear() until the same memory is later touched during rendering.
>
> From a broad overview point of view, fast colo
In certain circumstances the memory region underlying a miptree is
shared with other miptrees, or with other code outside Mesa's control.
This happens, for instance, when an extension like GL_OES_EGL_image or
GLX_EXT_texture_from_pixmap extension is used to associate a miptree
with an image existin
This patch adds code to place mcs_state into INTEL_MCS_STATE_RESOLVED
for miptrees that are capable of supporting fast color clears. This
will have no effect on buffers that don't undergo a fast color clear;
however, for buffers that do undergo a fast color clear, an MCS
miptree will be allocated
Resolve color buffers that have been fast-color cleared:
1. before texturing from the buffer
2. before using the buffer as the source in a blorp blit
3. before mapping the buffer's miptree
4. before accessing the buffer using the hardware blitter
Cases 1 and 2 happen in the functio
We already had code in intel_downsample_for_dri2_flush() for
downsampling front and back buffers when multisampling was in use.
This patch extends that function to perform fast color clear resolves
when necessary.
To account for the additional functionality, the function is renamed
to simply intel
This patch implements the "render target resolve" blorp operation.
This will be needed when a buffer that has experienced a fast color
clear is later used for a purpose other than as a render target
(texturing, glReadPixels, or swapped to the screen). It resolves any
remaining deferred clear opera
The fragment shaders that to do color clears will be re-used to
perform so-called "render target resolves" (the resolves associated
with fast color clears). To prepare for that, this patch expands the
class hierarchy for blorp params by adding
brw_blorp_const_color_params (which will be used for a
Since we defer allocation of the MCS miptree until the time of the
fast clear operation, this patch also implements creation of the MCS
miptree.
In addition, this patch adds the field
intel_mipmap_tree::fast_clear_color_value, which holds the most recent
fast color clear value, if any. We use it t
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 123 +
src/mesa/drivers/dri/intel/intel_mipmap_tree.h | 7 ++
2 files changed, 130 insertions(+)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index a3668
On Gen7+, MCS buffers are used both for compressed multisampled color
buffers and for "fast clear" of single-sampled color buffers.
Previous to this patch series, we didn't support fast clear, so we
only used MCS with multisampled bolor buffers.
As a first step to implementing fast clears, this p
This patch includes code to update the fast color clear state
appropriately when rendering occurs. The state will also need to be
updated when a fast clear or a resolve operation is performed; those
state updates will be added when the fast clear and resolve operations
are added.
---
src/mesa/dri
This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915
(pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there
is no need for this field in the i915 driver). This should make it a
bit easier to implement fast color clears without undue risk to i915.
---
src/mesa/drive
This series implements fast color clears, a Gen7+ feature which
reduces memory bandwidth by deferring the memory writes involved in a
glClear() until the same memory is later touched during rendering.
>From a broad overview point of view, fast color clears work in a
similar way to HiZ: an auxiliar
1) The tabs are used in the entire file. They might have got there
while I was moving some of the bits of code around. I don't really use
tabs for core Mesa work. I can change the tabs to spaces unless you
mean I should change everything to tabs (you didn't make that clear).
2) _mesa_get_sampler_u
On 05/21/2013 02:55 PM, Eric Anholt wrote:
The hardware does it, so no need for this workaround.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 64 +-
1 file changed, 33 insertions(+), 31 deletions(-)
Looks like roughly a 6% speedup, and no regressions. Pushed.
Hi,
seems this was missed for 9.1.3. Could someone cherrypick it to the 9.1
branch?
- Lauri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, May 21, 2013 at 6:12 PM, wrote:
> From: Roland Scheidegger
>
> This optimization disabled mask checks if the shader is simple enough.
> While this should work correctly, the problem is that it can hide real issues
> because shaders in practice are usually complex enough (8 instructions o
From: Roland Scheidegger
This optimization disabled mask checks if the shader is simple enough.
While this should work correctly, the problem is that it can hide real issues
because shaders in practice are usually complex enough (8 instructions or 1
texture is already enough) so this doesn't get
From: Roland Scheidegger
We actually did early depth/stencil test and late depth/stencil write even
when the shader could kill the fragment (alpha test or discard). Since it
matters for the new stencil value if the fragment is killed by depth/stencil
test or by the shader (in which case it will n
From: Roland Scheidegger
We did mask checks between depth/stencil testing and depth/stencil write.
This meant that if the depth/stencil test killed off all fragments we never
actually wrote the new stencil value. This issue affected all early/late
test/write combinations.
So move the mask check a
From: Roland Scheidegger
This was meant to disable some code which isn't needed when depth/stencil
isn't written. However, there's more code which wouldn't be needed in that
case so having the condition there was just odd (llvm will drop all the code
anyway).
---
src/gallium/drivers/llvmpipe/lp_
From: Roland Scheidegger
Using wrong type if the format was less than 32bits.
No piglit changes as it doesn't hit that path.
---
src/gallium/drivers/llvmpipe/lp_bld_depth.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_bld_dep
The hardware does it, so no need for this workaround.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 64 +-
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
Marek Olšák writes:
> The problem is the sampler units are allocated from the same pool for all
> shader stages, so if a vertex shader uses 12 samplers (0..11), the fragment
> shader samplers start at index 12, leaving only 4 sampler units
> for the fragment shader. The main cause is probably the
On 05/18/2013 11:18 PM, Chris Forbes wrote:
Relaxes the validation of
OPTION ARB_precision_hint_{nicest,fastest};
to allow duplicate options. The spec says that both /nicest/ and
/fastest/ cannot be specified together, but could be interpreted
either way for respecification of the same opti
On 05/18/2013 11:20 AM, Marek Olšák wrote:
Ping. This patch allows more than 16 samplers in all shaders combined
(MAX_COMBINED_TEXTURE_IMAGE_UNITS), which has never been possible with
current Mesa git. GL 3.1 requires 32 combined texture image units and
GL 3.2 requires 48, so I think this patch d
* We generate a static library for Haiku
Gallium targets as our port system combines
the compiled rendering code into a modular
ar for each module (for example, our port
system combines llvm libsoftpipe.a libllvmpipe.a
into a single ar for the Haiku build system.
I'd like the Gallium hg
On Tue, May 21, 2013 at 1:33 PM, Eric Anholt wrote:
> Paul Berry writes:
>
>> On 17 May 2013 21:44, Chia-I Wu wrote:
>>
>>> On Sat, May 18, 2013 at 10:11 AM, Jordan Justen
>>> wrote:
>>> > Rather than pointing the surface_state directly at a single
>>> > sub-image of the texture for rendering,
Chris Forbes writes:
> Relaxes the validation of
>
>OPTION ARB_precision_hint_{nicest,fastest};
>
> to allow duplicate options. The spec says that both /nicest/ and
> /fastest/ cannot be specified together, but could be interpreted
> either way for respecification of the same option.
>
> Othe
Paul Berry writes:
> On 17 May 2013 21:44, Chia-I Wu wrote:
>
>> On Sat, May 18, 2013 at 10:11 AM, Jordan Justen
>> wrote:
>> > Rather than pointing the surface_state directly at a single
>> > sub-image of the texture for rendering, we now point the
>> > surface_state at the top level of the te
Kenneth Graunke writes:
> This series deletes all the software primitive counting used to compute
> transform feedback buffer offsets, and generally cleans up all of that
> code. Now that we require hardware contexts on Gen6+, we can just
> initialize the counters to 0 and let the hardware do th
Mesa 9.1.3 has been released. Mesa 9.1.3 is a bug fix release which
fixes bugs fixed since the 9.1.2 release.
The tag in the GIT repository for Mesa 9.1.3 is 'mesa-9.1.3'.
Mesa 9.1.3 is available for download at
ftp://freedesktop.org/pub/mesa/9.1.3/
md5sums:
952ccd03547ed72333b64e1746cf8ada
https://bugs.freedesktop.org/show_bug.cgi?id=64733
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 05/21/2013 11:44 AM, Jordan Justen wrote:
On Tue, May 21, 2013 at 12:11 AM, Kenneth Graunke wrote:
On 05/16/2013 05:44 PM, Jordan Justen wrote:
Verify that interface blocks match when linking separate shader
stages into a program.
Fixes piglit glsl-1.50 tests:
* linker/interface-blocks-vs
https://bugs.freedesktop.org/show_bug.cgi?id=64733
--- Comment #3 from Ian Romanick ---
I'm 99% sure that this bug is already fixed in Mesa. That message sounds
really familiar... I could only find bug #53562, but I would swear there was
something else.
I second Brian's suggestion of using newe
On Tue, May 21, 2013 at 12:11 AM, Kenneth Graunke wrote:
> On 05/16/2013 05:44 PM, Jordan Justen wrote:
>>
>> Verify that interface blocks match when linking separate shader
>> stages into a program.
>>
>> Fixes piglit glsl-1.50 tests:
>> * linker/interface-blocks-vs-fs-member-count-mismatch.shade
On 21 May 2013 11:09, Jordan Justen wrote:
> On Tue, May 21, 2013 at 10:27 AM, Paul Berry
> wrote:
> > On 17 May 2013 19:11, Jordan Justen wrote:
> >>
> >> Rather than pointing the surface_state directly at a single
> >> sub-image of the texture for rendering, we now point the
> >> surface_stat
On Tue, May 21, 2013 at 10:27 AM, Paul Berry wrote:
> On 17 May 2013 19:11, Jordan Justen wrote:
>>
>> Rather than pointing the surface_state directly at a single
>> sub-image of the texture for rendering, we now point the
>> surface_state at the top level of the texture, and configure
>> the sur
On 17 May 2013 19:11, Jordan Justen wrote:
> Rather than pointing the surface_state directly at a single
> sub-image of the texture for rendering, we now point the
> surface_state at the top level of the texture, and configure
> the surface_state as needed based on this.
>
> We now also need to s
On 17 May 2013 19:11, Jordan Justen wrote:
> Signed-off-by: Jordan Justen
>
Patches 1-4 are
Reviewed-by: Paul Berry
> ---
> src/mesa/main/texformat.c | 13 +
> src/mesa/main/texformat.h |2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/src/mesa/main/texformat.c
https://bugs.freedesktop.org/show_bug.cgi?id=64733
Brian Paul changed:
What|Removed |Added
Summary|Asked To Report Here|unexpected format
|
https://bugs.freedesktop.org/show_bug.cgi?id=64733
--- Comment #1 from Brian Paul ---
Mesa 8.0.4 is getting a bit old. Can you possibly test a newer version?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailin
On 20 May 2013 20:13, Chia-I Wu wrote:
> On Tue, May 21, 2013 at 5:08 AM, Paul Berry
> wrote:
> > On 17 May 2013 21:44, Chia-I Wu wrote:
> >>
> >> On Sat, May 18, 2013 at 10:11 AM, Jordan Justen
> >> wrote:
> >> > Rather than pointing the surface_state directly at a single
> >> > sub-image of
On 20 May 2013 15:54, Kenneth Graunke wrote:
> Most of the work in BeginTransformFeedback is only necessary on Gen6.
> We may as well just skip it on Gen7+.
>
> Signed-off-by: Kenneth Graunke
> Cc: Eric Anholt
> Cc: Paul Berry
> ---
> src/mesa/drivers/dri/i965/brw_context.c| 8 +++---
>
On 05/20/2013 08:59 PM, Kenneth Graunke wrote:
On 05/20/2013 04:19 PM, Brian Paul wrote:
On 05/13/2013 05:10 AM, Chris Forbes wrote:
Signed-off-by: Chris Forbes
---
src/mesa/main/get.c | 6 +-
src/mesa/main/get_hash_params.py | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --gi
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 3f7e79f..f49170d 100644
--- a/src/gallium/drivers/radeon/ra
---
src/gallium/drivers/r600/r600_llvm.c | 7 +--
src/gallium/drivers/r600/r600_shader.c | 1 +
src/gallium/drivers/radeon/radeon_llvm.h | 1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
inde
https://bugs.freedesktop.org/show_bug.cgi?id=64745
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
- Original Message -
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64745
> Note: This is a candidate for the stable branches.
> ---
> src/mesa/drivers/x11/fakeglx.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/drivers/x11/fakeglx.c b
On Sam, 2013-05-18 at 00:28 -0700, Vinson Lee wrote:
> 'type' was not fully initialized when calling lp_build_context_init.
>
> Fixes "Uninitialized scalar variable" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
> ---
> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 2 ++
>
On 05/16/2013 05:44 PM, Jordan Justen wrote:
Verify that interface blocks match when linking separate shader
stages into a program.
Fixes piglit glsl-1.50 tests:
* linker/interface-blocks-vs-fs-member-count-mismatch.shader_test
* linker/interface-blocks-vs-fs-member-order-mismatch.shader_test
S
On Mon, May 20, 2013 at 11:30 PM, Pohjolainen, Topi
wrote:
> On Fri, May 17, 2013 at 07:11:36PM -0700, Jordan Justen wrote:
>> Set the renderbuffer's Depth field to match the texture's
>> Depth when rendering to a texture.
>>
>> Signed-off-by: Jordan Justen
>> ---
>> src/mesa/drivers/dri/intel/i
66 matches
Mail list logo
