https://bugs.freedesktop.org/show_bug.cgi?id=90048
Bug ID: 90048
Summary: shaderapi.h:235:50: error: expected ‘{’ before ‘,’
token
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=90048
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=90048
--- Comment #2 from Tapani Pälli ---
sorry, will try to dig what is causing this
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-
https://bugs.freedesktop.org/show_bug.cgi?id=90048
--- Comment #3 from Tapani Pälli ---
Created attachment 115113
--> https://bugs.freedesktop.org/attachment.cgi?id=115113&action=edit
fix attempt
does this fix the issue?
--
You are receiving this mail because:
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=90048
--- Comment #4 from Vinson Lee ---
(In reply to Tapani Pälli from comment #3)
> Created attachment 115113 [details] [review]
> fix attempt
>
> does this fix the issue?
No.
--
You are receiving this mail because:
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=90048
--- Comment #5 from Vinson Lee ---
A definition of interface must be getting included from some MinGW header file.
This patch works around the compile error.
diff --git a/src/mesa/main/shaderapi.h b/src/mesa/main/shaderapi.h
index 0cd2fad..d313
https://bugs.freedesktop.org/show_bug.cgi?id=90048
--- Comment #6 from Tapani Pälli ---
(In reply to Vinson Lee from comment #5)
> A definition of interface must be getting included from some MinGW header
> file.
>
> This patch works around the compile error.
>
> diff --git a/src/mesa/main/shad
I took the liberty to push a follow-up change to rename `interface` to
`program `programInterface`.
`interface` caused build failures on Windows, as it is a define -- an
alias for `struct` keyword, used when declaring COM interfaces in C or C++.
I chose `programInterface` to match the the nam
On 04/16/2015 12:32 PM, Jose Fonseca wrote:
I took the liberty to push a follow-up change to rename `interface` to
`program `programInterface`.
`interface` caused build failures on Windows, as it is a define -- an
alias for `struct` keyword, used when declaring COM interfaces in C or
C++.
I
https://bugs.freedesktop.org/show_bug.cgi?id=90048
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 15 April 2015 at 23:25, Rob Clark wrote:
> On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick wrote:
>> On 04/15/2015 10:56 AM, Emil Velikov wrote:
>>> On 15 April 2015 at 18:33, Matt Turner wrote:
On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov
wrote:
> Rather than forcing everyone
Consistently just use C99's __func__ everywhere.
No functional changes.
Signed-off-by: Marius Predut
---
src/mesa/drivers/dri/r200/r200_blit.c |2 +-
src/mesa/drivers/dri/r200/r200_cmdbuf.c| 10 +++
src/mesa/drivers/dri/r200/r200_ioctl.c |2 +-
Consistently just use C99's __func__ everywhere.
No functional changes.
Apply this patch after "radeon: replace __FUNCTION__ with __func__" patch.
Signed-off-by: Marius Predut
---
src/mesa/main/compiler.h |5 -
1 file changed, 5 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/m
On 15 April 2015 at 21:39, Chad Versace wrote:
> On Wed 15 Apr 2015, Emil Velikov wrote:
>>
>> On 14 April 2015 at 17:22, Ian Romanick wrote:
>>>
>>> On 04/14/2015 08:36 AM, Emil Velikov wrote:
On 14 April 2015 at 13:52, Jose Fonseca wrote:
>
> On 13/04/15 22:59, Ian Romanick w
On 15/04/15 23:25, Rob Clark wrote:
On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick wrote:
On 04/15/2015 10:56 AM, Emil Velikov wrote:
On 15 April 2015 at 18:33, Matt Turner wrote:
On Wed, Apr 15, 2015 at 7:08 AM, Emil Velikov wrote:
Rather than forcing everyone to provide their own definiti
Hi Marius,
On 16 April 2015 at 11:36, Marius Predut wrote:
> Consistently just use C99's __func__ everywhere.
> No functional changes.
> Apply this patch after "radeon: replace __FUNCTION__ with __func__" patch.
>
Tip: If you send the patches as series (git format-patch -2) this will
implicitly p
On 16 April 2015 at 11:50, Jose Fonseca wrote:
> On 15/04/15 23:25, Rob Clark wrote:
>>
>> On Wed, Apr 15, 2015 at 6:15 PM, Ian Romanick wrote:
>>>
>>> On 04/15/2015 10:56 AM, Emil Velikov wrote:
On 15 April 2015 at 18:33, Matt Turner wrote:
>
> On Wed, Apr 15, 2015 at 7:08 AM,
When running piglit w/ llvmpipe on Windows several tests terminate
abnormally just when the test exits.
The problem was that LLVMContextDispose was being called
after LLVM global destructors.
---
src/gallium/targets/libgl-gdi/libgl_gdi.c | 22 --
1 file changed, 20 insertions(
On 26 March 2015 at 00:40, Ilia Mirkin wrote:
> On Wed, Mar 25, 2015 at 8:31 PM, Matt Turner wrote:
>> On Wed, Mar 25, 2015 at 4:15 PM, Jan Vesely wrote:
>>> On Wed, 2015-03-25 at 18:55 -0400, Ilia Mirkin wrote:
On Wed, Mar 25, 2015 at 6:51 PM, Jan Vesely wrote:
> On Fri, 2015-03-06 a
> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, April 16, 2015 1:53 PM
> To: Predut, Marius
> Cc: ML mesa-dev
> Subject: Re: [Mesa-dev] [PATCH] main: remove __FUNCTION__ defined because it
> is obsolete
>
> Hi Marius,
>
> On 16 April 2015 at
Makes sense I guess. That teardown all feels so unnatural unfortunately :-(.
Roland
Am 16.04.2015 um 14:09 schrieb Jose Fonseca:
> When running piglit w/ llvmpipe on Windows several tests terminate
> abnormally just when the test exits.
>
> The problem was that LLVMContextDispose was being calle
On Wed, Apr 15, 2015 at 6:06 PM, Ian Romanick wrote:
> On 04/15/2015 04:28 PM, Kenneth Graunke wrote:
>> On Wednesday, April 15, 2015 02:47:01 PM Ian Romanick wrote:
>>> On 04/15/2015 12:41 PM, Kristian Høgsberg wrote:
The ir_tex opcode turns into a sample or sample_c message, which will try
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Previously, we used _mesa_update_state to update the currently bound
> framebuffers prior to performing a blit. Now that _mesa_blit_framebuffer
> uses arbitrary framebuffers, _mesa_update_state is no
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mesa/main/fbobject.c | 38 +++---
> 1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
>
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mesa/main/fbobject.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 7a1684c..0b4c
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 16 ++
> src/mesa/main/fbobject.c | 67
> ++
> src/mesa/main/fbobject.h
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> Mesa's ClearBuffer framework is very complicated and thoroughly married to the
> object binding model. Moreover, the OpenGL spec for ClearBuffer is also very
> complicated. At some point, we should
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> The ARB_direct_state_access specification says (as of 2015.02.05):
>"Interactions with OpenGL 4.3 or ARB_framebuffer_no_attachments
>
>If neither OpenGL 4.3 nor ARB_framebuffer_no_attachm
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mesa/drivers/common/meta.c | 3 ++-
> src/mesa/main/buffers.c| 25 -
> src/mesa/main/buffers.h| 4 +++-
> src/mesa/main/context.c| 3 ++-
> src/mesa/main/framebuffer.c| 2 +-
> 5 f
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> This could have added a new DD table entry for DrawBuffer that takes an
> arbitrary draw buffer, but, after looking at the existing DD functions,
> Kenneth Graunke recommended that we just skip calling the DD functions in the
> case of ARB_direct_
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 5 +
> src/mesa/main/buffers.c| 18 ++
> src/mesa/main/buffers.h| 3 +++
> src/mesa/main/tests/dispatch_sanity.cpp
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> This could have added a new DD table entry for ReadBuffer that takes an
> arbitrary read buffer, but, after looking at the existing DD functions,
> Kenneth Graunke recommended that we just skip calling the DD functions in the
> case of ARB_direct_
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 5 +
> src/mesa/main/buffers.c| 18 ++
> src/mesa/main/buffers.h| 3 +++
> src/mesa/main/tests/dispatch_sanity.cpp
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> This could have added a new DD table entry for DrawBuffers that takes an
> arbitrary draw buffer, but, after looking at the existing DD functions,
> Kenneth Graunke recommended that we just skip calling the DD functions in the
> case of ARB_direct
This patch is:
Reviewed-by: Fredrik Höglund
On Wednesday 04 March 2015, Laura Ekstrand wrote:
> ---
> src/mapi/glapi/gen/ARB_direct_state_access.xml | 6 ++
> src/mesa/main/buffers.c| 19 +++
> src/mesa/main/buffers.h| 4
From: Ville Syrjälä
All CHV devices will be branded as "Intel(r) HD Graphics".
Signed-off-by: Ville Syrjälä
---
include/pci_ids/i965_pci_ids.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 3e3e8
On Thursday, April 16, 2015 09:00:46 PM ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> All CHV devices will be branded as "Intel(r) HD Graphics".
>
> Signed-off-by: Ville Syrjälä
> ---
> include/pci_ids/i965_pci_ids.h | 8
> 1 file changed, 4 insertions(+), 4 deletions
On Thu, Apr 16, 2015 at 11:20:01AM -0700, Kenneth Graunke wrote:
> On Thursday, April 16, 2015 09:00:46 PM ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > All CHV devices will be branded as "Intel(r) HD Graphics".
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > include/pc
Eric Anholt writes:
> Jason Ekstrand writes:
>
>> On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland
>> wrote:
>>> The performance numbers (shader-db runtime) are:
>>>
>>> Difference at 95.0% confidence
>>> -14.7608 +/- 3.36786
>>> -9.05064% +/- 2.06501%
>>> (Original runtime was 160 se
From: Rob Clark
There is an level param stashed away in the .w component of the first
src.
Signed-off-by: Rob Clark
---
src/gallium/auxiliary/nir/tgsi_to_nir.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c
b/src/gallium/auxi
Hi,
On 9 April 2015 at 17:20, Kristian Høgsberg wrote:
> On Wed, Apr 8, 2015 at 11:37 AM, Emil Velikov
> wrote:
>> Hi all,
>>
>> Can we get a pair of eyes on this patch please ?
>
> Reviewed-by: Kristian Høgsberg
>
> Thanks for the reminder.
Mind you, this does break 75b7e1df13, which explici
If an app called glTextureBarrierNV() without checking if the
extension was available, we'd crash with some gallium drivers
in st_TextureBarrier() because the pipe_context::texture_barrier()
pointer was NULL.
Generate GL_INVALID_OPERATION instead.
---
src/mesa/main/texturebarrier.c | 6 ++
1
This should be more efficient than the previous snprintf() solution.
But more importantly, it avoids a buffer overflow bug that could result
in crashes or unpredictable results when processing very large interface
blocks.
For the app in question, key->length = 103 for some interfaces. The check
i
---
src/mesa/main/shader_query.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index b5f1d08..ad936e5 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -537,6 +537,7 @@ array_index_of_resource
Reviewed-by: Ilia Mirkin
Consider dropping the NV from the message as the same callback is used
for ARB_texture_barrier.
On Thu, Apr 16, 2015 at 5:52 PM, Brian Paul wrote:
> If an app called glTextureBarrierNV() without checking if the
> extension was available, we'd crash with some gallium dri
2015-04-16 21:16 GMT+02:00 Eric Anholt :
> Eric Anholt writes:
>
>> Jason Ekstrand writes:
>>
>>> On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland
>>> wrote:
The performance numbers (shader-db runtime) are:
Difference at 95.0% confidence
-14.7608 +/- 3.36786
-9
Rob Clark writes:
> From: Rob Clark
>
> There is an level param stashed away in the .w component of the first
> src.
"a" level param, but other than that:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
On Wed, Apr 15, 2015 at 2:24 AM, Kenneth Graunke
wrote:
> Jason noticed that shader_time was bumping the reference count on the
> gl_shader_program and gl_program structures, in code called during
> compilation.
>
> Not only were these never unreferenced, but it meant fragment shaders
> might be
On Wed, Apr 15, 2015 at 2:24 AM, Kenneth Graunke wrote:
>
> 0 is not a valid GLSL shader or ARB program ID. For some reason,
> shader_time used -1 instead...so we had code to detect 0, then override
> it to -1.
>
> We can just delete that.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/dri
On 16.04.2015 19:35, Marius Predut wrote:
> Consistently just use C99's __func__ everywhere.
> No functional changes.
>
> Signed-off-by: Marius Predut
Acked-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
53 matches
Mail list logo
