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
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 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 ++
>
- 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
https://bugs.freedesktop.org/show_bug.cgi?id=64745
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
---
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
---
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
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
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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=64733
Brian Paul changed:
What|Removed |Added
Summary|Asked To Report Here|unexpected format
|
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
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 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 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 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
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 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
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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
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
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,
* 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 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
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
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
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
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
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
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
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
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
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
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 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.
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
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
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 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
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
---
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
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
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
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
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
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
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
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
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
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
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
---
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/
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
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:
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
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
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
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
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 |
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
- 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
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
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
66 matches
Mail list logo
