On 23 November 2015 at 03:17, Ilia Mirkin wrote:
> On Sun, Nov 22, 2015 at 9:28 PM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> No reason not to build this, it has no external
>> requirements at the moment.
>
> Not that I object, but what's the policy around these defaults? Should
> we also ad
On Mon, Nov 23, 2015 at 02:24:45PM +1100, Jonathan Gray wrote:
> Use PKG_CHECK_MODULES to get the flags to link libelf.
This should also include the part that uses cflags
If there is any interest in it going in I'll post another diff with this
included:
diff --git a/src/gallium/drivers/radeon/Ma
On 11/22/2015 01:25 PM, Timothy Arceri wrote:
On Sun, 2015-11-22 at 11:00 +0100, gregory hainaut wrote:
On Sun, 22 Nov 2015 14:25:31 +1100
Timothy Arceri wrote:
On Tue, 2015-09-01 at 13:53 +0300, Tapani Pälli wrote:
From OpenGL 4.5 Core spec (7.13):
"If pipeline is a name that has b
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +--
src/mesa/drivers/dri/i965/brw_shader.cpp | 7 +++
src/mesa/drivers/dri/i965/brw_shader.h | 2 ++
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 ++
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i96
In order to do this, we have to change the signature of the
backend_reg(brw_reg) constructor to take a reference to a brw_reg in
order to avoid unresolvable ambiguity about which constructor is
actually being called in the other modifications in this patch.
As far as I understand it, the rule in C
Now that backend_reg inherits from brw_reg, we have to be careful to
avoid the object slicing problem.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +-
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 4 +--
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 +-
src/mesa/d
Use PKG_CHECK_MODULES to get the flags to link libelf.
Signed-off-by: Jonathan Gray
Cc: "11.0 11.1"
---
configure.ac | 4 +---
src/gallium/drivers/radeon/Makefile.am | 2 +-
src/gallium/targets/opencl/Makefile.am | 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
Correct some occurrences of -ldl and -lpthread to use
$(DLOPEN_LIBS) and $(PTHREAD_LIBS) respectively.
Signed-off-by: Jonathan Gray
Cc: "11.0 11.1"
---
src/gallium/targets/opencl/Makefile.am | 2 +-
src/mesa/drivers/dri/i965/Makefile.am | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
On Sun, Nov 22, 2015 at 9:28 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> No reason not to build this, it has no external
> requirements at the moment.
Not that I object, but what's the policy around these defaults? Should
we also add nouveau? freedreno? vc4?
Of course my personal preference
From: Dave Airlie
No reason not to build this, it has no external
requirements at the moment.
Signed-off-by: Dave Airlie
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 120c93e..5479ba6 100644
--- a/configure.ac
+++ b/c
On 23 November 2015 at 01:15, Timothy Arceri wrote:
> On Mon, 2015-11-23 at 00:59 +, Emil Velikov wrote:
>> On 23 November 2015 at 00:35, Timothy Arceri wrote:
>> > On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
>> > > Based on one's interpretation of the spec one may say that length
On 22 November 2015 at 23:12, Timothy Arceri wrote:
> From: Timothy Arceri
>
> Regression as of 64710db66461e
>
> We can't use the type returned by get_interface_type() as
> the interface type has arrays removed.
>
> Cc: Emil Velikov
Reviewed-by: Emil Velikov
-Emil
___
On Mon, 2015-11-23 at 00:59 +, Emil Velikov wrote:
> On 23 November 2015 at 00:35, Timothy Arceri wrote:
> > On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
> > > Based on one's interpretation of the spec one may say that length (when
> > > non negative) either considers or doesn't the
On 23 November 2015 at 00:35, Timothy Arceri wrote:
> On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
>> Based on one's interpretation of the spec one may say that length (when
>> non negative) either considers or doesn't the null terminator.
>>
>> I'm leaning towards the latter case, altho
On Mon, 2015-11-23 at 00:20 +, Emil Velikov wrote:
> On 22 November 2015 at 23:53, Ilia Mirkin wrote:
> > On Sun, Nov 22, 2015 at 6:50 PM, Emil Velikov
> > wrote:
> > > On 22 November 2015 at 23:22, Ilia Mirkin wrote:
> > > > There are some places that you're not fixing up...
> > > I thought
On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
> Based on one's interpretation of the spec one may say that length (when
> non negative) either considers or doesn't the null terminator.
>
> I'm leaning towards the latter case, although the CTS authors are
> thinking about the former.
The
On Mon, 2015-11-23 at 00:26 +, Emil Velikov wrote:
> On 23 November 2015 at 00:10, Timothy Arceri wrote:
> > On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
> > > As per the spec quote:
> > >
> > > "All messages are initially enabled unless their assigned severity
> > > is DEBU
On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
> These new (relative to ARB_debug_output) tokens, have been explicitly
> separated from the existing ones in the spec text. With the reference
> to glDebugMessageInsert was dropped.
>
> At the same time, further down the spec says:
>"The
On 23 November 2015 at 00:10, Timothy Arceri wrote:
> On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
>> As per the spec quote:
>>
>> "All messages are initially enabled unless their assigned severity
>> is DEBUG_SEVERITY_LOW"
>>
>> We already had MEDIUM and HIGH set, let's toggle N
On 22 November 2015 at 23:53, Ilia Mirkin wrote:
> On Sun, Nov 22, 2015 at 6:50 PM, Emil Velikov
> wrote:
>> On 22 November 2015 at 23:22, Ilia Mirkin wrote:
>>> There are some places that you're not fixing up...
>> I thought I fixed all cases - which ones do you have in mind ? The
>> ones in d
On Sun, 2015-11-22 at 23:21 +, Emil Velikov wrote:
> As per the spec quote:
>
> "All messages are initially enabled unless their assigned severity
> is DEBUG_SEVERITY_LOW"
>
> We already had MEDIUM and HIGH set, let's toggle NOTIFICATION as well.
Looks like there was a spec bug and o
On Sun, Nov 22, 2015 at 6:50 PM, Emil Velikov wrote:
> On 22 November 2015 at 23:22, Ilia Mirkin wrote:
>> There are some places that you're not fixing up...
> I thought I fixed all cases - which ones do you have in mind ? The
> ones in debug_destroy() or the comparison in _mesa_PushDebugGroup()
On 22 November 2015 at 23:22, Ilia Mirkin wrote:
> There are some places that you're not fixing up...
I thought I fixed all cases - which ones do you have in mind ? The
ones in debug_destroy() or the comparison in _mesa_PushDebugGroup() ?
> would this
> alternatively be resolved by returning Grou
On 22 November 2015 at 23:21, Emil Velikov wrote:
> Until then lets restrict things,
> effectively fixing the following CTS test:
>
>ES2-CTS.gtf.GL2ExtensionTests.debug.debug
>
This hunk is a silly thinko. I've dropped it locally.
-Emil
___
mesa-dev
Reviewed-by: Timothy Arceri
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sun, Nov 22, 2015 at 2:05 PM, Emil Velikov wrote:
> It seems that due to the conditional autotools is getting confused and
> forgetting to add AM_CPPFLAGS when building libloader (when
> HAVE_DRICOMMON is not set).
I very much expect this is by design.
Reviewed-by: Matt Turner
__
There are some places that you're not fixing up... would this
alternatively be resolved by returning GroupStackDepth+1 in
_mesa_get_debug_state_int and leaving everything else alone?
On Sun, Nov 22, 2015 at 6:21 PM, Emil Velikov wrote:
> The variable represents the length/size of the stack, thus
Based on one's interpretation of the spec one may say that length (when
non negative) either considers or doesn't the null terminator.
I'm leaning towards the latter case, although the CTS authors are
thinking about the former.
Hack this for now and think about it later :-)
Signed-off-by: Emil V
Currently it stores strlen(buf) whenever the user originally provided a
negative value for length.
Although I've not seen any explicit text in the spec, CTS requires that
the very same length (be that negative value or not) is returned back on
Pop.
So let's push down the length < 0 checks, tweak
As per the spec quote:
"All messages are initially enabled unless their assigned severity
is DEBUG_SEVERITY_LOW"
We already had MEDIUM and HIGH set, let's toggle NOTIFICATION as well.
Signed-off-by: Emil Velikov
---
src/mesa/main/errors.c | 5 +++--
1 file changed, 3 insertions(+), 2 d
The variable represents the length/size of the stack, thus (based on the
spec requirement and the allocation above) it should be set to 1.
This means that we have to use GroupStackDepth-1 to access the correct
entry in the array.
Signed-off-by: Emil Velikov
---
src/mesa/main/errors.c | 17 +
The KHR_debug extension implements this.
Strictly speaking it could be used with ES 1.0, although as the original
function is available on ES 1.1, I'm inclined to lift the KHR_debug
requirement to ES 1.1.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048
Signed-off-by: Emil Velikov
--
These new (relative to ARB_debug_output) tokens, have been explicitly
separated from the existing ones in the spec text. With the reference
to glDebugMessageInsert was dropped.
At the same time, further down the spec says:
"The value of must be one of the values from Table 5.4"
... and these
The extension requires (cough implements) GetPointervKHR (alias of
GetPointerv) which in itself is available for ES 1.1 enabled mesa.
Anyone willing to fish around and implement it for ES 1.0 is more than
welcome to revert this commit. Until then lets restrict things,
effectively fixing the follow
Hi all,
Seems that with enabling KHR_debug on GLES contexts the Khronos CTS
found a few bugs in our implementation.
All but the first two seems to be generic issues (ie. applicable to both
GL and GLES contexts).
The following patches fix some of the problems, although as the test
doesn't yet
From: Timothy Arceri
Regression as of 64710db66461e
We can't use the type returned by get_interface_type() as
the interface type has arrays removed.
Cc: Emil Velikov
---
src/glsl/ast_to_hir.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/s
Reviewed-by: Ilia Mirkin
I can indeed confirm that those functions are nowhere to be found,
makes sense to remove the declarations as well.
Oded's issue seems likely to stem from some mismatch between the
loader and what's being loaded...
On Sun, Nov 22, 2015 at 5:45 PM, Emil Velikov wrote:
>
Unused as of commit 23fb11455b4 "{st,targets}/dri: use static/dynamic
pipe-loader"
Signed-off-by: Emil Velikov
---
Noticed when Oded reported missing symbol drisw_create_screen in
swrast_dri.so. Still not sure how that's even remotely possible.
-Emil
src/gallium/include/state_tracker/drisw_a
Not too long ago, the dri3 code was living in src/glx, which in itself
was guarded by HAVE_DRI_GLX. As the name suggests we didn't dive into
the folder when dri was disabled, thus we missed that dri3 does not
consider/honour --enable-dri.
Fixes: 6bd9ba7d074 "loader: Add dri3 helper"
Cc: Pali Rohár
It seems that due to the conditional autotools is getting confused and
forgetting to add AM_CPPFLAGS when building libloader (when
HAVE_DRICOMMON is not set).
Fixes: 5a79e0a8e37 "automake: loader: rework the CPPFLAGS"
Reported-by: Pali Rohár
Tested-by: Pali Rohár
Signed-off-by: Emil Velikov
---
From: Timothy Arceri
This change allows used defined inputs/outputs with explicit locations
to be removed if they are detected to not be used between shaders
at link time.
To enable this we change the is_unmatched_generic_inout field to be
flagged when we have a user defined varying. Previously
On Sat, Nov 21, 2015 at 2:46 PM, Ilia Mirkin wrote:
> Just ran into this myself and spent a bunch of time investigating...
> Any reason this wasn't already reviewed/checked in?
>
>
None that I know of. I just pushed it though.
> On Wed, Oct 28, 2015 at 5:50 PM, Nanley Chery
> wrote:
> > From:
Jordan Justen writes:
> On 2015-11-17 21:54:44, Jordan Justen wrote:
>> From: Francisco Jerez
>>
>> ---
>> src/mesa/drivers/dri/i965/gen7_l3_state.c | 17 +
>> src/mesa/drivers/dri/i965/intel_debug.c | 1 +
>> src/mesa/drivers/dri/i965/intel_debug.h | 1 +
>> 3 files chan
Kenneth Graunke writes:
> On Friday, November 20, 2015 05:36:35 PM Francisco Jerez wrote:
>> Kenneth Graunke writes:
>>
>> > On Friday, November 20, 2015 02:38:10 PM Francisco Jerez wrote:
>> >> Kenneth Graunke writes:
>> >>
>> >> > On Thursday, November 19, 2015 02:05:44 PM Kenneth Graunke w
On Sun, 2015-11-22 at 22:25 +1100, Timothy Arceri wrote:
> On Sun, 2015-11-22 at 11:00 +0100, gregory hainaut wrote:
> > On Sun, 22 Nov 2015 14:25:31 +1100
> > Timothy Arceri wrote:
> >
> > > On Tue, 2015-09-01 at 13:53 +0300, Tapani Pälli wrote:
> > > > From OpenGL 4.5 Core spec (7.13):
> > > >
On Sun, 2015-11-22 at 11:00 +0100, gregory hainaut wrote:
> On Sun, 22 Nov 2015 14:25:31 +1100
> Timothy Arceri wrote:
>
> > On Tue, 2015-09-01 at 13:53 +0300, Tapani Pälli wrote:
> > > From OpenGL 4.5 Core spec (7.13):
> > >
> > > "If pipeline is a name that has been generated (without
> >
https://bugs.freedesktop.org/show_bug.cgi?id=93063
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 22 November 2015 at 09:12, Igor Gnatenko wrote:
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=93063
> Signed-off-by: Igor Gnatenko
> ---
> src/gallium/auxiliary/target-helpers/drm_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxilia
Hi Eric,
On 22 November 2015 at 02:47, Eric Anholt wrote:
> They're exclusive at build time, but the ilo entry is always present, so
> we'd try to use it and fail out.
> ---
> src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 16
> 1 file changed, 8 insertions(+), 8 deletion
On Sun, 22 Nov 2015 14:25:31 +1100
Timothy Arceri wrote:
> On Tue, 2015-09-01 at 13:53 +0300, Tapani Pälli wrote:
> > From OpenGL 4.5 Core spec (7.13):
> >
> > "If pipeline is a name that has been generated (without
> > subsequent
> > deletion) by GenProgramPipelines, but refers to a pro
https://bugs.freedesktop.org/show_bug.cgi?id=93063
--- Comment #3 from Igor Gnatenko ---
Created attachment 120012
--> https://bugs.freedesktop.org/attachment.cgi?id=120012&action=edit
[PATCH] virgl: pipe_virgl_create_screen is not static
--
You are receiving this mail because:
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=93063
--- Comment #2 from Igor Gnatenko ---
http://lists.freedesktop.org/archives/mesa-dev/2015-November/101074.html
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=93063
Signed-off-by: Igor Gnatenko
---
src/gallium/auxiliary/target-helpers/drm_helper.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/target-helpers/drm_helper.h
b/src/gallium/auxiliary/target-he
https://bugs.freedesktop.org/show_bug.cgi?id=93063
Igor Gnatenko changed:
What|Removed |Added
CC||i.gnatenko.br...@gmail.com
--- Comment #
https://bugs.freedesktop.org/show_bug.cgi?id=93063
Vinson Lee changed:
What|Removed |Added
CC||emil.l.veli...@gmail.com
--
You are receiv
55 matches
Mail list logo
