Hi,
I did a piglit run with the gpu.py profile with and without the patch.
There were some switches from pass->fail and fail->pass in
spec/glsl-1.50/execution/geometry/end-primitive but these seem to not be
stable, because after a second with and without a patch different tests from
this catego
On Tuesday, July 01, 2014 08:26:48 PM Jordan Justen wrote:
> Should this be i965/gen7? (Seems to be a no-op for gen8.)
>
> Series Reviewed-by: Jordan Justen
>
> Speaking of xfb and gen8, I rebased a ~week old branch today, and saw
> two regressions:
> spec/EXT_transform_feedback/primgen-query tr
Should this be i965/gen7? (Seems to be a no-op for gen8.)
Series Reviewed-by: Jordan Justen
Speaking of xfb and gen8, I rebased a ~week old branch today, and saw
two regressions:
spec/EXT_transform_feedback/primgen-query transform-feedback-disabled: pass fail
spec/ARB_transform_feedback2/countin
On 02.07.2014 00:43, Brian Paul wrote:
> Module: Mesa
> Branch: master
> Commit: f4b0ab7afd83c811329211eae8167c9bf238870c
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f4b0ab7afd83c811329211eae8167c9bf238870c
>
> Author: Brian Paul
> Date: Tue Jul 1 08:17:09 2014 -0600
>
> st/
Signed-off-by: Ilia Mirkin
---
Not sure if this is the right approach or if I should combine it with Centroid
more directly. More modifications will be required wrt per-sample shading
since we'll need to distinguish the min samples case where everything is
per-sample-interpolated vs this case whe
On Tue, Jul 1, 2014 at 9:23 PM, Michel Dänzer wrote:
> On 02.07.2014 01:25, Marek Olšák wrote:
>> If the tests pass, the patch can be merged.
>
> And if the patch causes no piglit regressions.
I can't vouch for that. I have a report that the
ARB_fragment_layer_viewport-specific tests pass on a ca
On 02.07.2014 01:25, Marek Olšák wrote:
> If the tests pass, the patch can be merged.
And if the patch causes no piglit regressions.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
_
This ensures that the previous commit indeed generates the expected error
message when a "#define" directive is not followed by anything except for a
newline.
---
src/glsl/glcpp/tests/139-define-without-macro-name.c | 2 ++
src/glsl/glcpp/tests/139-define-without-macro-name.c.expected | 2
This is the fix for the following line:
# // comment to ignore here
According to the translation-phase rules, the comment should be removed before
the preprocessor looks to interpret the null directive.
So in our implementation we must explicitly look for single-line comments in
the st
We accidentally had support for null directives, (that is, a line with "#" and
nothing else) in two places: the lexer and the parser.
The support in the lexer was broken, (expecting the '#' to be followed
immediately by a newline), so it caused failures if the '#' was followed
immediately by white
This new "make check" test stresses out the support from the last two commits,
(to esnure that '#' is correctly interpreted as the null directives,
regardless of any whitespace or comments on the same line).
---
src/glsl/glcpp/tests/138-null-directive.c | 9 +
src/glsl/glcpp/tests
We were already correctly supporting single-line comments in case like:
#define FOO bar // comment here...
The new support added here is simply for the none-too-useful:
#define // comment instead of macro name
With this commit, this line will now give the expected "#define witho
This simply tests the previous commit, (that #define followed by a comment
will still generate the expected "#define without macro name" error message).
---
src/glsl/glcpp/tests/139-define-without-macro-name.c | 5 -
src/glsl/glcpp/tests/139-define-without-macro-name.c.expected | 5 ++
On Tue, Jul 1, 2014 at 2:06 PM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
>>> +static void
>>> +clear_image_to_zero(GLubyte *dstMap, GLint dstRowStride,
>>> +GLsizei width, GLsizei height,
>>> +GLsizei clearValueSize)
>>> +{
>>> + while (height-- > 0
On Tuesday, July 01, 2014 03:25:49 PM Carl Worth wrote:
> There is no behavioral change here. It's just easier to verify that lists
> of start conditions include all expected conditions when they appear in a
> consistent order.
>
> The state is special, so it appears first in all lists. All other
The GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN counter is not supposed to
increment during glGenerateMipmap(). I don't think either counter is
supposed to increment during most meta operations, so simply turn off
statistics during those.
Fixes one Piglit test:
spec/EXT_transform_feedback/generatemi
Previously, we only emitted 3DSTATE_SO_BUFFER and 3DSTATE_SO_DECL_LIST
when transform feedback was active. When it was inactive, we disabled
the SOL stage in 3DSTATE_SOL so the other state would be ignored.
In commit 3178d2474ae5bdd1102fb3d76a60d1d63c961ff5, Iago enabled the SOL
stage universally
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.
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/
The hiz buffer doesn't have a documented structure.
Nevertheless, we allocate a miptree structure for the hiz buffer. In
the past we relied on setting up the surface such that we had to point
at an offset within the hiz buffer.
For gen7+ we no longer do this. We now always point the surface to th
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
---
src/mesa/drivers/dri/i965/gen8_depth_state.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 67 ++-
1 file changed, 65 insertions(+), 2 deletions(-)
d
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
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp| 6 +++---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 7
Am 01.07.2014 23:47, schrieb Emil Velikov:
> On 01/07/14 20:17, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
>> in more places, in particular even for things buildable with msvc, and hence
>> those break t
Kristian Høgsberg writes:
> Oh, I should have read the rest of the page - there's %option warn to
> go with nodefault:
>
> warn about certain things. In particular, if the default rule can
> be matched but no default rule has been given, the flex will warn
> you. We recommend using
Using a single rule here means that we can use the <*> syntax to match
all start conditions. This makes the catch-all rule more robust against
the addition of future start conditions, (no need to maintain an ever-
growing list of start conditions for this rul).
---
src/glsl/glcpp/glcpp-lex.l | 12
We've had multiple bugs in the past where we have been inadvertently matching
the default rule, (which we never want to do). We recently added a catch-all
rule to avoid this, (and made this rule robust for future start conditions).
Kristian pointed out that flex allows us to go one step better. Th
We've had bugs in the past where we have been inadvertently matching the
default rule.
Just as we did in the pre-processor in the previous commit, we can use:
%option warn nodefault
in the compiler to instruct flex to not generate the default rule, and
further to warn if our set of rules
There is no behavioral change here. It's just easier to verify that lists
of start conditions include all expected conditions when they appear in a
consistent order.
The state is special, so it appears first in all lists. All others
appear in alphabetical order.
---
src/glsl/glcpp/glcpp-lex.l |
Typically, updating our environment to use new compilers is not easy
because of various dependencies, etc. It'll probably be a while.
-Brian
On 07/01/2014 03:47 PM, Emil Velikov wrote:
On 01/07/14 20:17, srol...@vmware.com wrote:
From: Roland Scheidegger
it looks since ce1a1372280d737a1b85
On 01/07/14 20:17, srol...@vmware.com wrote:
> From: Roland Scheidegger
>
> it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
> in more places, in particular even for things buildable with msvc, and hence
> those break the build.
Microsoft were kind enough to finally a
From: Cody Northrop
Vectors are falling in to the ir_dereference_array() path.
Without this change, the following glsl aborts the debug driver,
or gets the wrong answer in release:
mat2x2 a = mat2( vec2( 1.0, vertex.x ), vec2( 0.0, 1.0 ) );
Also submitting piglit tests, will reference in bug.
On Thu, Jun 26, 2014 at 2:54 PM, Carl Worth wrote:
> The preprocessor defines a notions of a "preprocessing number" that
> starts with either a digit or a decimal point, and continues with zero
> or more of digits, decimal points, identifier characters, or the sign
> symbols, ('-' and '+').
>
> Pr
Vectors are falling in to the ir_dereference_array() path.
Without this change, the following glsl aborts the debug driver,
or gets the wrong answer in release:
mat2x2 a = mat2( vec2( 1.0, vertex.x ), vec2( 0.0, 1.0 ) );
Also submitting piglit tests, will reference in bug.
Signed-off-by: Cody N
On Tuesday, July 01, 2014 12:43:54 PM Cody Northrop wrote:
> Commit 17c7ead7 exposed a bug in how uniform loading happens in the
> presence of discard. It manifested itself in an application as
> randomly incorrect pixels on the borders of conditional areas.
>
> This is due to how discards jump t
On 07/01/2014 01:17 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
in more places, in particular even for things buildable with msvc, and hence
those break the build.
---
src/gallium/auxiliary/target-helpers
On 07/01/2014 01:05 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
Because the layout is always linear this didn't really do much any longer -
at some point this triggered per-tile swizzled->linear conversion. The x/y
coords were ignored too.
Apart from triggering conversion, this also
From: Roland Scheidegger
it looks since ce1a1372280d737a1b85279995529206586ae480 they are now included
in more places, in particular even for things buildable with msvc, and hence
those break the build.
---
src/gallium/auxiliary/target-helpers/inline_drm_helper.h | 8
1 file changed, 4
From: Roland Scheidegger
Since switching to non-swizzled rendering we only have "normal", aka linear,
offsets.
---
src/gallium/drivers/llvmpipe/lp_setup.c | 2 +-
src/gallium/drivers/llvmpipe/lp_state_sampler.c | 2 +-
src/gallium/drivers/llvmpipe/lp_texture.c | 6 +++---
src/galli
From: Roland Scheidegger
Once used for invoking swizzled->linear conversion for all needed images.
But we now have a single allocation for all images in a resource, thus looping
through all slices is rather pointless, conversion doesn't happen neither.
Also simplify the sampling setup code to use
From: Roland Scheidegger
The only caller left used it only for non display target textures,
hence it was really the same as llvmpipe_get_texture_image_address - it
also had a usage flag but this was ignored anyway.
---
src/gallium/drivers/llvmpipe/lp_texture.c | 48 +-
From: Roland Scheidegger
Just use a tex_data pointer directly - the description was no longer correct
neither.
---
src/gallium/drivers/llvmpipe/lp_setup.c | 2 +-
src/gallium/drivers/llvmpipe/lp_state_sampler.c | 2 +-
src/gallium/drivers/llvmpipe/lp_texture.c | 39 ++
From: Roland Scheidegger
The deferred allocation doesn't really make much sense anymore, since we no
longer allocate swizzled/linear memory in chunks and not per level / slice
neither.
This means we could fail resource creation a bit more (could already fail in
theory anyway) but should not fail
From: Roland Scheidegger
Because the layout is always linear this didn't really do much any longer -
at some point this triggered per-tile swizzled->linear conversion. The x/y
coords were ignored too.
Apart from triggering conversion, this also invoked alloc_image_data(), which
could only actuall
Commit 17c7ead7 exposed a bug in how uniform loading happens in the
presence of discard. It manifested itself in an application as
randomly incorrect pixels on the borders of conditional areas.
This is due to how discards jump to the end of the shader incorrectly
for some channels. The current i
On Tue, Jul 1, 2014 at 11:06 AM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
> >> +static void
> >> +clear_image_to_zero(GLubyte *dstMap, GLint dstRowStride,
> >> +GLsizei width, GLsizei height,
> >> +GLsizei clearValueSize)
> >> +{
> >> + while (heig
On Tue, Jul 1, 2014 at 10:09 AM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
> >> + texImages[0] = _mesa_select_tex_image(ctx, texObj, texObj->Target,
> >> level);
> >>
> >
> > Do you want this inside an else block?
>
> I think it's quite a common idiom in Mesa to handle the special cases a
Jason Ekstrand writes:
>> +static void
>> +clear_image_to_zero(GLubyte *dstMap, GLint dstRowStride,
>> +GLsizei width, GLsizei height,
>> +GLsizei clearValueSize)
>> +{
>> + while (height-- > 0) {
>> + memset(dstMap, 0, clearValueSize * width);
>> +
Ian Romanick writes:
> Are there potentially cases where the first clear_tex_image could
> succeed but the second fail? If so, then this is no good. If a GL call
> generates an error (other than GL_NO_MEMORY), it is supposed to be as
> though nothing happened.
Urgh, yes, you're right because f
Jason Ekstrand writes:
>> + texImages[0] = _mesa_select_tex_image(ctx, texObj, texObj->Target,
>> level);
>>
>
> Do you want this inside an else block?
I think it's quite a common idiom in Mesa to handle the special cases as
a series of if-statements with a return upfront before handling the
n
If the tests pass, the patch can be merged.
Marek
On Tue, Jul 1, 2014 at 5:25 PM, Ilia Mirkin wrote:
> On Tue, Jul 1, 2014 at 11:13 AM, Alex Deucher wrote:
>> On Tue, Jun 24, 2014 at 8:43 PM, Ilia Mirkin wrote:
>>> In order to support ARB_fragment_layer_viewport, we need to explicitly
>>> send
https://bugs.freedesktop.org/show_bug.cgi?id=75913
commiethebeas...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Done.
-Brian
On 07/01/2014 09:40 AM, Axel Davy wrote:
I don't have push access.
Could you push it ?
On 01/07/2014 11:22, Brian Paul wrote :
That works.
Tested-by: Brian Paul
On 07/01/2014 09:19 AM, Axel Davy wrote:
Hi,
This path should resolve the problem.
Axel
On 01/07/2014 10:53, Ax
I don't have push access.
Could you push it ?
On 01/07/2014 11:22, Brian Paul wrote :
That works.
Tested-by: Brian Paul
On 07/01/2014 09:19 AM, Axel Davy wrote:
Hi,
This path should resolve the problem.
Axel
On 01/07/2014 10:53, Axel Davy wrote :
In src/loader/Makefile.am,
the test 'if
On 07/01/2014 09:25 AM, Roland Scheidegger wrote:
Am 01.07.2014 16:53, schrieb Brian Paul:
---
src/mesa/main/mtypes.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index eaf3776..e78bcde 100644
--- a/src/mesa/main/mtypes
Am 01.07.2014 16:25, schrieb Ilia Mirkin:
> On Tue, Jul 1, 2014 at 8:39 AM, Roland Scheidegger wrote:
>> Am 30.06.2014 19:43, schrieb Ilia Mirkin:
>>> On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger
>>> wrote:
3-4 look alright to me.
>>>
>>> Does this count as a R-b? Looks like the core
On Tue, Jul 1, 2014 at 11:13 AM, Alex Deucher wrote:
> On Tue, Jun 24, 2014 at 8:43 PM, Ilia Mirkin wrote:
>> In order to support ARB_fragment_layer_viewport, we need to explicitly
>> send these along to the fragment shader, since it has no other way to
>> retrieve them.
>>
>> Signed-off-by: Ilia
Am 01.07.2014 16:53, schrieb Brian Paul:
> ---
> src/mesa/main/mtypes.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index eaf3776..e78bcde 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -2
That works.
Tested-by: Brian Paul
On 07/01/2014 09:19 AM, Axel Davy wrote:
Hi,
This path should resolve the problem.
Axel
On 01/07/2014 10:53, Axel Davy wrote :
In src/loader/Makefile.am,
the test 'if NEED_OPENGL_COMMON' should probably be more restrictive,
I'm looking at it.
Axel
On 01
Hi,
This path should resolve the problem.
Axel
On 01/07/2014 10:53, Axel Davy wrote :
In src/loader/Makefile.am,
the test 'if NEED_OPENGL_COMMON' should probably be more restrictive,
I'm looking at it.
Axel
On 01/07/2014 10:22, Brian Paul wrote :
I configured with:
./autogen.sh CFLAGS="-g
On Tue, Jun 24, 2014 at 8:43 PM, Ilia Mirkin wrote:
> In order to support ARB_fragment_layer_viewport, we need to explicitly
> send these along to the fragment shader, since it has no other way to
> retrieve them.
>
> Signed-off-by: Ilia Mirkin
> Tested-by: Tobias Droste
> ---
>
> v1 -> v2:
>
>
> FWIW, I relaxed the format restrictions in
> brw_blorp_copytexsubimage, so it can handle general format
> conversions as well (i.e. RGBA_FLOAT16 -> RGBA_UNORM). There's
> no reason we couldn't do that for BlitFramebuffer as well, I just
> forgot to do it (and then we decided to make it a newb
Otherwise, if we were creating a const buffer src register for a UBO
the index into the UBO was always zero.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st
---
src/mesa/main/mtypes.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index eaf3776..e78bcde 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2560,7 +2560,7 @@ struct gl_uniform_block
GLuint Binding
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 1020d36..3933e69 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgs
UniformBufferSize is in bytes so we need to divide by 16 to get the
number of constant buffer slots. Also, the ureg_DECL_constant2D()
function takes first..last parameters so we need to subtract one
for the last value.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |9 -
1 file change
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 3391a14..1020d36 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/sr
In src/loader/Makefile.am,
the test 'if NEED_OPENGL_COMMON' should probably be more restrictive,
I'm looking at it.
Axel
On 01/07/2014 10:22, Brian Paul wrote :
I configured with:
./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug
--enable-xlib-glx --disable-driglx-direct --disabl
Some of the features are completely implemented by core, while others
have hardware dependencies. Create a list of drivers supporting each
sub-feature that must have hw support.
Signed-off-by: Ilia Mirkin
---
docs/GL3.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --g
On Tue, Jul 1, 2014 at 8:39 AM, Roland Scheidegger wrote:
> Am 30.06.2014 19:43, schrieb Ilia Mirkin:
>> On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger
>> wrote:
>>> 3-4 look alright to me.
>>
>> Does this count as a R-b? Looks like the core changes have landed, so
>> I'm going to be lookin
I configured with:
./autogen.sh CFLAGS="-g -O0" CXXFLAGS="-g -O0" --enable-debug
--enable-xlib-glx --disable-driglx-direct --disable-dri
--enable-gallium-osmesa --with-gallium-drivers=swrast --enable-gallium-tests
So no DRI code should be used. When I compile:
gmake[2]: Entering directory `
On Thu, 2014-06-26 at 08:24 +0200, Iago Toral Quiroga wrote:
> So far we have been using CL_INVOCATION_COUNT to resolve this query
> but this
> is no good with streams, as only stream 0 reaches the clipping
> stage. Instead
> we will use SO_PRIM_STORAGE_NEEDED which can keep track of the
> primi
On Mon, Jun 30, 2014 at 10:11:41AM -0700, Matt Turner wrote:
> We've often created the CFG immediately before, so use it when
> available.
> ---
> src/mesa/drivers/dri/i965/brw_fs.h| 2 +-
> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 3 +--
> src/mesa/dri
Am 30.06.2014 19:43, schrieb Ilia Mirkin:
> On Sat, Jun 28, 2014 at 8:44 AM, Roland Scheidegger
> wrote:
>> 3-4 look alright to me.
>
> Does this count as a R-b? Looks like the core changes have landed, so
> I'm going to be looking to push all this out ~tomorrow.
>
>> I wonder if the cap name i
Sure though it seems a bit unfortunate if all the code is already
there... Please also enable it for llvmpipe.
Roland
Am 30.06.2014 17:22, schrieb Ilia Mirkin:
> Looks like it'll be a while before someone can look at my r600 patch
> which makes layer/viewport available in the fragment shader. Rol
Currently, when a geometry shader can't use dual object mode we fall back to
dual instance mode, however, when invocations == 1, single dispatch mode is
more performant and equally efficient in terms of register pressure.
Single dispatch mode requires that the driver can handle interleaving of
reg
Reviewed-by: Jordan Justen
On Mon, Jun 30, 2014 at 5:55 PM, Kenneth Graunke wrote:
> i965 precompiles shaders at link time, and prints a disassembly if
> INTEL_DEBUG=vs,gs,fs, including the shader name. However, blit shaders
> were showing up as "unnamed" since we hadn't set a name prior to
> l
78 matches
Mail list logo
