After modifying the hiz buffer allocation and qpitch calculation, hiz
appears to work in all cases on gen8.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tr
We now skip allocating a hiz miptree for gen8. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 95 ++
This will allow us to treat HiZ and MCS the same when using as an
auxiliary surface buffer.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 +-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 4 +-
src/mesa/drivers/dri/i
1. No longer allocate a miptree structure for hiz on gen7+.
2. Always enable hiz for depth on gen8+.
3. Enable hiz Auxiliary Buffer support on gen8. This support allows
Broadwell to sample from depth using the hiz buffer, and thereby
removing the need to resolve depth to/from the hiz buffer
For some auxiliary buffers the qpitch may be different than the main
miptree. (for example, hiz)
In "i965: Wrap MCS miptree in intel_miptree_aux_buffer" we set
aux_buf->qpitch to mt->qpitch, so for MCS, this should be a no-op.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/
For gen8, we can sample from depth while using the hiz buffer. This
allows us to sample depth without resolving from hiz to the depth
texture.
To do this we must resolve to hiz before drawing so we can use the hiz
buffer to sample while rendering. Hopefully the hiz buffer will
already be resolved
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/gen8_depth_state.c | 6 +++---
1 file changed,
GEN8_SURFACE_AUX_MODE_NONE is 0, so this is a no-op.
Yet, this also makes it clear that we can compare aux_mode to the
other GEN8_SURFACE_AUX_MODE_ values. We will want to compare to
GEN8_SURFACE_AUX_MODE_HIZ.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/
From: Kenneth Graunke
Signed-off-by: Kenneth Graunke
[jordan.l.jus...@intel.com: convert from aux_mt to aux_buf]
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/gen
For gen8+ this will indicate when we should allow hiz based sampling
during rendering.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/
This will allow us to treat HiZ and MCS the same when using them as
auxiliary surface buffers.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 28 +-
1 file changed, 14 insertions(+), 14 deletions(-)
diff -
Currently it indicates that this is never supported, but soon it will
be supported for gen8+.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 ++
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 4
2 files changed, 1
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 97 ++
Today we allocate a miptree's for the hiz buffer. We needed this in
the past because we would point the hardware at offsets of the hiz
buffer. Since the hiz format is not documented, this is not a good
idea.
Since moving to support layered rendering on Gen7+, we no longer point
at an offset into t
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp| 6 +++---
src/mesa/drivers
Both are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #13 from Michel Dänzer ---
(In reply to comment #12)
> If then you add a glClear(GL_COLOR_BUFFER_BIT) after the call to
> glViewport(...), then the problem goes away.
>
> The question is, is it the responsibility of the GL client pro
Largely via copy and paste.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 42 +-
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 045
This will be useful for INTEL_DEBUG=optimizer in the vec4 backend, which
needs to know whether it's currently processing a VS or GS. It isn't
worth adding virtual methods for this case.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 3 ++-
src/mesa/drivers/dri/i96
On Friday, July 18, 2014 07:41:57 AM Dylan Baker wrote:
> Currently mesa searches for two different environment variables,
> LIBGL_DRIVERS_PATH and GBM_DRIVERS_PATH. The first is used for search
> for DRI drivers in every case except GBM, and the latter is used
> exclusively for setting GBM drivers
On Mon, 2014-07-21 at 14:04 -0700, Ian Romanick wrote:
> From: Ian Romanick
>
> There are a bunch of places, especially in the UBO code, where we check
> whether something is a matrix (or record) when we actually want to know
> if it a matrix or an array of matrices (ditto for records).
>
Hi Ia
On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov wrote:
> Giovanni can you test the series that I've not butchered anything else during
> the rebase ?
Oh hey, sorry I missed the bit that I was expected to test the patches.
Unfortunately, something indeed got lost: the logic to choose the
kms_swrast
Reviewed-by: Marek Olšák
Marek
On Tue, Jul 22, 2014 at 2:11 AM, Anuj Phogat wrote:
> because float depth texture data needs clamping to [0.0, 1.0]. Let the
> _mesa_texstore() fallback to slower path.
>
> Fixes Khronos GLES3 CTS tests:
> shadow_execution_vert
> shadow_execution_frag
>
> V2: Move
On Monday, July 14, 2014 03:48:41 PM Ian Romanick wrote:
> From: Ian Romanick
>
> warn_extension_index was moved to improve packing.
>
> Valgrind massif results for a trimmed apitrace of dota2:
>
> ntime(i) total(B) useful-heap(B)
> extra-heap(B)stacks(B
On Monday, July 14, 2014 03:48:38 PM Ian Romanick wrote:
> From: Ian Romanick
>
> All of the GL image enums fit in 16-bits.
>
> Also move the fields from the anonymous "image" structucture to the next
> higher structure. This will enable packing the bits with the other
> bitfield.
>
> Valgrind
On Mon, Jul 21, 2014 at 5:16 PM, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> src/mesa/main/imports.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
> index af780b2..5d6486b 100644
> --- a/src/mesa/main/imports.h
>
Signed-off-by: Jason Ekstrand
---
src/mesa/main/imports.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index af780b2..5d6486b 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -285,6 +285,10 @@ static inline int F_TO
because float depth texture data needs clamping to [0.0, 1.0]. Let the
_mesa_texstore() fallback to slower path.
Fixes Khronos GLES3 CTS tests:
shadow_execution_vert
shadow_execution_frag
V2: Move the check to _mesa_texstore_can_use_memcpy() function.
Add check for floating point data types.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Jul 21, 2014 at 3:39 PM, Matt Turner wrote:
> On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Just a few lines earlier we may have wrapped the index expression with
>> ir_unop_i2u expression. Whenever that happens, as_constant will return
>> NULL, and th
In Piglit's EXT_framebuffer_multisample/alpha-to-coverage-dual-src-blend
test, key->nr_color_regions == 2, but the dual source blend FB write has
ir->target set to 0. So we failed to set "Last Render Target Select" on
any FB write message.
We only emit one FB write per render target, so my commen
On Tue, Jul 22, 2014 at 12:50 AM, Anuj Phogat wrote:
>
>
>
> On Mon, Jul 21, 2014 at 3:27 PM, Marek Olšák wrote:
>>
>> On Tue, Jul 22, 2014 at 12:09 AM, Anuj Phogat
>> wrote:
>> > On Fri, Jul 18, 2014 at 5:54 PM, Marek Olšák wrote:
>> >>
>> >> Shouldn't the function return TRUE for floating-poi
On Mon, Jul 21, 2014 at 3:27 PM, Marek Olšák wrote:
> On Tue, Jul 22, 2014 at 12:09 AM, Anuj Phogat
> wrote:
> > On Fri, Jul 18, 2014 at 5:54 PM, Marek Olšák wrote:
> >>
> >> Shouldn't the function return TRUE for floating-point depth textures
> only?
> >>
> > Depth texture data needs clamping
On Mon, Jul 21, 2014 at 3:17 PM, Matt Turner wrote:
> On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
>> +enum glsl_matrix_layout {
>> + GLSL_MATRIX_LAYOUT_DEFAULT,
>
> Does this mean language-default, or does it really means the inherited
> layout? E.g., for
>
> layout(row_major) uniform
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
> Around the time OpenGL ES 3.1 was released, Khronos made some
> significant updates to the OpenGL ES 3.0 conformance suite. These
> updates uncovered a number of bugs in our implementation of UBOs.
>
> This patch series fixes all 147 failing
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Just a few lines earlier we may have wrapped the index expression with
> ir_unop_i2u expression. Whenever that happens, as_constant will return
> NULL, and that almost always happens.
Are you saying that since we just
Hi Richard,
For anything that changes the shared core code in src/gallium, the
commit message prefix should be "gallium:". You can also use
"gallium/util:" if you just change auxiliary/util.
For anything that changes src/mesa/state_tracker, the prefix should be
"st/mesa:".
For anything that chan
On Mon, Jul 21, 2014 at 3:28 PM, Matt Turner wrote:
> On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Previously if a field of an block with an instance name was marked
>> row-major (but block itself was not), we would think the field (and it's
>> sub-fields) wer
On 17.07.2014 21:24, Tom Stellard wrote:
> On Thu, Jul 17, 2014 at 06:44:25PM +0200, Grigori Goronzy wrote:
>> Accuracy of some operations was recently improved in the R600 backend,
>> at the cost of slower code. This is required for compute shaders,
>> but not for graphics shaders. Add unsafe-fp-m
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Previously if a field of an block with an instance name was marked
> row-major (but block itself was not), we would think the field (and it's
> sub-fields) were column-major.
>
> Fixes gles3conform failures in:
>
> ES3-
On Tue, Jul 22, 2014 at 12:09 AM, Anuj Phogat wrote:
> On Fri, Jul 18, 2014 at 5:54 PM, Marek Olšák wrote:
>>
>> Shouldn't the function return TRUE for floating-point depth textures only?
>>
> Depth texture data needs clamping in following two cases:
> 1. Float texture format supplied with signed
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
> +enum glsl_matrix_layout {
> + GLSL_MATRIX_LAYOUT_DEFAULT,
Does this mean language-default, or does it really means the inherited
layout? E.g., for
layout(row_major) uniform a {
mat4 m;
};
m's .matrix_layout is GLSL_MATRIX_LAYOUT_DEFAU
On Fri, Jul 18, 2014 at 5:54 PM, Marek Olšák wrote:
>
> Shouldn't the function return TRUE for floating-point depth textures only?
>
Depth texture data needs clamping in following two cases:
1. Float texture format supplied with signed data needs clamping to [0.0, 1.0].
2. Fixed point texture form
On Friday, July 18, 2014 02:32:10 PM Matt Turner wrote:
> On Fri, Jul 18, 2014 at 1:19 PM, Kenneth Graunke
> wrote:
> > We might be able to do this without an extra program key field, but this
> > is non-invasive and fixes the bug, for now.
> >
> > This fixes the following Piglit tests on Broadwe
On Mon, Jul 21, 2014 at 5:36 PM, Ian Romanick wrote:
> On 07/21/2014 01:56 PM, Dylan Baker wrote:
>> 3) this is a silly function, all you need is:
>> filter = range(0, filter_bits / 32)
>
> But that will be different... that's the same as
>
> filter = [0, 1, 2, 3, ...]
>
> but I want
>
> f
On 07/21/2014 01:56 PM, Dylan Baker wrote:
> On Monday, July 14, 2014 03:48:58 PM Ian Romanick wrote:
>> From: Ian Romanick
>>
>> The use of the Bloom filter rejects the vast majority of strings that
>> are not in the table before expensive comparisons are performed. This
>> Bloom filter uses two
On Mon, Jul 21, 2014 at 2:04 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Commit 32f32292 (glsl: Allow elimination of uniform block members)
> enabled elimination of unused uniform block members to fix a gles3
> conformance test failure. This went too far the other way.
>
> Section 2.11.6 (U
Am 21.07.2014 17:53, schrieb Richard Sandiford:
> lp_build_iround has a fallback case that tries to emulate a round-to-nearest
> float->int conversion by adding 0.5 and using a truncating fptosi. For odd
> numbers in the range [2^23, 2^24], which are already integral, this has
> the effect of addi
From: Ian Romanick
Just a few lines earlier we may have wrapped the index expression with
ir_unop_i2u expression. Whenever that happens, as_constant will return
NULL, and that almost always happens.
Signed-off-by: Ian Romanick
---
src/glsl/lower_ubo_reference.cpp | 3 ++-
1 file changed, 2 in
From: Ian Romanick
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.nested_structs_arrays_instance_arrays.3
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.13
Causes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.all_per_block_buffers.9
This fail
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/link_uniform_blocks.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/link_uniform_blocks.cpp b/src/glsl/link_uniform_blocks.cpp
index 53a18c9..fef3626 100644
--- a/src/glsl/link_uniform_blocks.cpp
From: Ian Romanick
This code was attemping to align the base of the structure to the required
alignment of the structure. However, it had two problems:
1. It was aligning the target structure member, not the base of the
structure.
2. It was calculating the alignment based on the members previo
From: Ian Romanick
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.single_nested_struct.per_block_buffer_packed
ES3-CTS.shaders.uniform_block.single_nested_struct_array.per_block_buffer_packed
ES3-CTS.shaders.uniform_block.random.scalar_types.7
ES3-CTS.shaders.uniform_block.random.
From: Ian Romanick
For a row-major matrix, the next column starts at the next element.
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.single_basic_array.shared.row_major_mat2
ES3-CTS.shaders.uniform_block.single_basic_array.shared.row_major_mat3
ES3-CTS.shaders.uniform_block.sing
From: Ian Romanick
Previously if a field of an block with an instance name was marked
row-major (but block itself was not), we would think the field (and it's
sub-fields) were column-major.
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.basic_types.7
ES3-CTS.shaders.unifor
From: Ian Romanick
I also considered renaming visit_field(const glsl_struct_field *) to
entry_record and adding an exit_record method. This would be more
similar to the hierarchical visitor.
Signed-off-by: Ian Romanick
---
src/glsl/link_uniform_blocks.cpp | 3 ++-
src/glsl/link_uniforms.cpp
From: Ian Romanick
Commit 32f32292 (glsl: Allow elimination of uniform block members)
enabled elimination of unused uniform block members to fix a gles3
conformance test failure. This went too far the other way.
Section 2.11.6 (Uniform Variables) of the OpenGL ES 3.0.3 spec says:
"All memb
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/ast_to_hir.cpp| 3 +--
src/glsl/glsl_types.cpp| 3 +--
src/glsl/link_uniforms.cpp | 22 +++---
src/glsl/link_varyings.cpp | 6 ++
4 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/src/glsl/
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/ast_to_hir.cpp | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 1fb4274..eeafb44 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -5
From: Ian Romanick
There are a bunch of places, especially in the UBO code, where we check
whether something is a matrix (or record) when we actually want to know
if it a matrix or an array of matrices (ditto for records).
This will be used in later patches in this series.
Signed-off-by: Ian Ro
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/glsl/ast_to_hir.cpp| 8 +++--
src/glsl/builtin_types.cpp | 74 +-
src/glsl/builtin_variables.cpp | 2 +-
src/glsl/glsl_types.cpp| 32 ++
src/glsl/glsl_types.h
From: Ian Romanick
Obvious copy-and-paste bug.
Signed-off-by: Ian Romanick
---
src/mesa/main/uniform_query.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 480bc6f..609d94b 100644
--- a/src/mesa/main
From: Ian Romanick
This causes the thing following the structure to be vec4-aligned.
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.random.nested_structs.2
ES3-CTS.shaders.uniform_block.random.all_shared_buffer.5
Signed-off-by: Ian Romanick
---
src/glsl/glsl_types.cpp
Around the time OpenGL ES 3.1 was released, Khronos made some
significant updates to the OpenGL ES 3.0 conformance suite. These
updates uncovered a number of bugs in our implementation of UBOs.
This patch series fixes all 147 failing tests that I could attribute to
UBO related problems.
With the
From: Ian Romanick
Use the data that is stored in the ir_variable and the glsl_type to
determine whether or not a UBO member is row-major.
Fixes gles3conform failures in:
ES3-CTS.shaders.uniform_block.instance_array_basic_type.shared.row_major_mat2
ES3-CTS.shaders.uniform_block.instance_array_b
On Monday, July 14, 2014 03:48:57 PM Ian Romanick wrote:
> From: Ian Romanick
>
> Valgrind massif results for a trimmed apitrace of dota2:
>
> ntime(i) total(B) useful-heap(B)
> extra-heap(B)stacks(B) Before (32-bit): 52 40,521,071,734
> 66,157,928
On Monday, July 14, 2014 03:48:58 PM Ian Romanick wrote:
> From: Ian Romanick
>
> The use of the Bloom filter rejects the vast majority of strings that
> are not in the table before expensive comparisons are performed. This
> Bloom filter uses two hashes. One is explicit (calculate_hash in the
https://bugs.freedesktop.org/show_bug.cgi?id=81500
--- Comment #26 from Barto ---
Created attachment 103227
--> https://bugs.freedesktop.org/attachment.cgi?id=103227&action=edit
2 outputs of MESA_GLSL=dump
Hi Ian,
here are in attachement the 2 outputs of MESA_GLSL=dump, 2 files in a tar.gz
ar
https://bugs.freedesktop.org/show_bug.cgi?id=64324
--- Comment #1 from Andy Skinner ---
Any chance someone could look at this? We still get it reported as a leak,
though it is in a large system and it would be hard to send a repro case. I
admit we have't updated in a while, but the code is the
On Monday, July 21, 2014 11:42:18 AM Matt Turner wrote:
> ... to eliminate an ELSE instruction followed immediately by an ENDIF.
>
> instructions in affected programs: 704 -> 700 (-0.57%)
> ---
> .../drivers/dri/i965/brw_dead_control_flow.cpp | 25
> +-
> 1 file chang
https://bugs.freedesktop.org/show_bug.cgi?id=81500
Ian Romanick changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #25 from Ian Romanic
On 21/07/14 16:25, Ilia Mirkin wrote:
> On Mon, Jul 21, 2014 at 11:23 AM, Kristian Høgsberg
> wrote:
>> On Sun, Jul 20, 2014 at 11:36 PM, Eric Anholt wrote:
>>> Emil Velikov writes:
>>>
On 18/07/14 17:27, Kenneth Graunke wrote:
> On Friday, July 18, 2014 07:41:57 AM Dylan Baker wrote:
Am 21.07.2014 17:53, schrieb Richard Sandiford:
> llvmpipe treats PIPE_FORMAT_Z32_FLOAT_S8X24_UINT as a bit of a special case,
> handling it as two 32-bit pieces rather than a single 64-bit block:
>
>/* 64bit d/s format is special already extracted 32 bits */
>total_bits = format_desc->blo
Am 21.07.2014 17:53, schrieb Richard Sandiford:
> Fallback cases in lp_bld_arit.c used 2^24 to mean "2 to the power 24",
> but in C it's "2 xor 24", i.e. 26. Fixed by using 1<< instead.
>
> Signed-off-by: Richard Sandiford
> ---
> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 8
> 1 fi
Am 21.07.2014 17:53, schrieb Richard Sandiford:
> ...fixing the associated TODO.
>
> Signed-off-by: Richard Sandiford
> ---
> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 34
> -
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/auxili
On 21/07/14 17:02, Giovanni Campagna wrote:
> On Mon, Jul 21, 2014 at 12:47 PM, Emil Velikov
> wrote:
>> Giovanni can you test the series that I've not butchered anything else during
>> the rebase ?
>
> Oh hey, sorry I missed the bit that I was expected to test the patches.
> Unfortunately, some
Will clarify make the next commit easier to read.
---
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
index cf47cb5..c0
... to eliminate an ELSE instruction followed immediately by an ENDIF.
instructions in affected programs: 704 -> 700 (-0.57%)
---
.../drivers/dri/i965/brw_dead_control_flow.cpp | 25 +-
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dr
---
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
index c0bba8e..03c7ee6 100644
--- a/src/mesa/dri
On Mon, Jul 21, 2014 at 3:40 AM, Emil Velikov wrote:
> For all the people interested in testing the freedreno driver on
> their Android devices. The next commit will hook these up within
> the libEGL driver (via the gallium-egl backend).
>
> There may be some rough edges but those can be sorted wh
On Mon, Jul 21, 2014 at 6:40 AM, Emil Velikov wrote:
> Rather than including two extra folders only for two headers,
> correctly prefix the headers.
>
> Cc: "10.1 10.2"
> Cc: Rob Clark
> Signed-off-by: Emil Velikov
Reviewed-by: Rob Clark
> ---
> src/gallium/drivers/freedreno/Makefile.am
Hi again.
It seems I finally found out the trick, even though the render tests in
OpenGL Extensions Viewer for OpenGL >3 will still remain disabled.
The following environment variable must be defined in order to get OpenGL
3.3 support with a forward context: MESA_GL_VERSION_OVERRIDE=3.3FC
I can
---
src/gallium/auxiliary/util/u_format.csv | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary/util/u_format.csv
index b68f6c2..1cd4954 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/aux
...fixing the associated TODO.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 34 -
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
b/src/gallium/auxiliary/gallivm/lp_bld_a
lp_build_iround has a fallback case that tries to emulate a round-to-nearest
float->int conversion by adding 0.5 and using a truncating fptosi. For odd
numbers in the range [2^23, 2^24], which are already integral, this has
the effect of adding 1 to the integer, since the result of adding 0.5 is
e
Fallback cases in lp_bld_arit.c used 2^24 to mean "2 to the power 24",
but in C it's "2 xor 24", i.e. 26. Fixed by using 1<< instead.
Signed-off-by: Richard Sandiford
---
src/gallium/auxiliary/gallivm/lp_bld_arit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/
The pack64 routines were hardwired for little-endian layout.
On big-endian, loading a PIPE_FORMAT_Z32_FLOAT_S8X24_UINT
as a 64-bit integer puts the depth float in the high 32 bits
and the stencil in the low 8 bits, like for the associated
MESA_FORMAT_*.
Signed-off-by: Richard Sandiford
---
src/g
llvmpipe treats PIPE_FORMAT_Z32_FLOAT_S8X24_UINT as a bit of a special case,
handling it as two 32-bit pieces rather than a single 64-bit block:
/* 64bit d/s format is special already extracted 32 bits */
total_bits = format_desc->block.bits > 32 ? 32 : format_desc->block.bits;
The format_d
...i.e. formats in which the first listed component is in the least
significant byte of the integer. The corresponding UNORM aliases already exist.
---
src/gallium/include/pipe/p_format.h | 24
1 file changed, 24 insertions(+)
diff --git a/src/gallium/include/pipe/p_form
MESA_FORMAT_R8G8B8X8_SNORM used a function called unpack_X8B8G8R8_SNORM
while MESA_FORMAT_R8G8B8X8_SRGB used a function called unpack_R8G8B8X8_SRGB.
This patch renames the SNORM function to have the same order as the
MESA_FORMAT name, like the SRGB function does.
---
src/mesa/main/format_unpack.c
The function was using the "X" component as the alpha channel,
rather than setting alpha to 1.0.
---
src/mesa/main/format_unpack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/format_unpack.c b/src/mesa/main/format_unpack.c
index ae14478..fddb067 100644
--- a/s
This means that each SRGB format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
src/mesa/main/format_pack.c | 60 +
src/mesa/main/format_unp
MESA_FORMAT_x8y8z8w8 means a format in which "x" is the least
signficant byte and "w" is the most significant byte. Most
functions get that right, but the signed ones access the
bytes from an array rather than an integer, so they need
to take endianness into account. This isn't too onerous
since
This means that each RnGnBnxn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
The associated UNORM and SRGB formats already exist.
---
src/gallium/auxiliary/util/u_format.csv | 3 +++
src/gallium/include/pipe/p_format.h | 3 +++
2 files ch
Similar to the L/A and R/G series I just posted, this one fixes the SNORM
and SRGB formats. The UNORM ones were done last year as part of the
original big-endian work.
Richard Sandiford (7):
util: Add PIPE_FORMAT_x8B8G8R8_SNORM formats
util: Define PIPE_FORMAT_xyzw_{SNORM,SRGB} alias
MESA_FORMAT_x8y8z8w8 puts the x channel in the least significant part of
the containing 32-bit integer, which is equivalent to PIPE_FORMAT_xyzw.
PIPE_FORMAT_x8y8z8w8 puts the x channel first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
---
src/mesa/state_tracker/st_f
...i.e. formats in which the alpha or green channel is first in memory.
This means that each LnAn and RnGn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
---
src/gallium/auxiliary/util/u_format.csv | 9 +
src/gallium/include/pipe/p_
The associated UNORM format already existed.
This means that each LnAn format has a reversed counterpart,
which is necessary for handling big-endian mesa<->gallium mappings.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 2 ++
src/mesa/main/format_pack.c | 37 +
MESA_FORMAT_LnAn puts the luminance in the least significant part of
the containing integer, which is equivalent to PIPE_FORMAT_LAnn.
PIPE_FORMAT_LnAn puts the luminance first in memory.
This patch fixes up the mesa<->gallium mapping accordingly.
---
src/mesa/state_tracker/st_format.c | 64 ++
Luminance is the least-significant byte of the uint16, rather than the
lowest byte in memory. Other parts of mesa already handle this correctly
for big-endian, and swrast already handles other MESA_FORMAT_x8y8 formats
correctly. This case was just an odd-one-out.
---
src/mesa/swrast/s_texfetch_t
1 - 100 of 132 matches
Mail list logo
