Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/r600/r600_hw_context.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index a89f230.
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/egl/drivers/dri2/egl_dri2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 351fbf4..ab06247 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/nv30/nv30_vbo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nv30/nv30_vbo.c
b/src/gallium/drivers/nv30/nv30_vbo.c
index 128457f..d7a774f 100644
--- a/src/gallium/driver
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/nv50/nv50_vbo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nv50/nv50_vbo.c
b/src/gallium/drivers/nv50/nv50_vbo.c
index 6e81b7b..d050062 100644
--- a/src/gallium/driver
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/gallium/drivers/nvc0/nvc0_vbo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nvc0/nvc0_vbo.c
b/src/gallium/drivers/nvc0/nvc0_vbo.c
index 61a6341..3ae437a 100644
--- a/src/gallium/driver
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee
---
src/mesa/drivers/dri/swrast/swrast.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/swrast/swrast.c
b/src/mesa/drivers/dri/swrast/swrast.c
index 9638271..b380de3 100644
--- a/src/mesa/driver
Hi,
I am getting the following error while using glFramebufferTexture2D in mesa es2
demos in mesa-9.0.2 and mesa-8.0.4 code . Can you please let me know, how to
resolve this error.
"GL_INVALID_OPERATION in glFramebufferTexture2D(textarget=0x3)"
Thanks and Regards,
Ramesh
CAU
On Don, 2013-01-31 at 17:05 -0500, Tom Stellard wrote:
> From: Tom Stellard
>
> This fixes indirect addressing when on 32-bit systems.
> ---
> lib/Target/R600/AMDGPUInstrInfo.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/Target/R600/AMDGPUInstrInfo.h
>
https://bugs.freedesktop.org/show_bug.cgi?id=60143
--- Comment #1 from Daniel van Vugt ---
Or even simpler fix...
bo->base.base.format = format;
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa
https://bugs.freedesktop.org/show_bug.cgi?id=60143
Daniel van Vugt changed:
What|Removed |Added
See Also||https://launchpad.net/bugs/
On Fre, 2013-02-01 at 00:20 +0100, Marek Olšák wrote:
> ---
> src/gallium/drivers/radeonsi/radeonsi_pipe.c |8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
> index 47
https://bugs.freedesktop.org/show_bug.cgi?id=60143
Priority: medium
Bug ID: 60143
Assignee: mesa-dev@lists.freedesktop.org
Summary: gbm_dri_bo_create fails to initialize
bo->base.base.format
Severity: normal
Classificatio
On 02/01/2013 03:20 AM, Marek Olšák wrote:
---
src/gallium/drivers/r600/r600_pipe.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index a59578d..1698cb3 100644
--- a/src/gallium/drive
https://bugs.freedesktop.org/show_bug.cgi?id=59494
lu hua changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #5 from lu hua ---
Verifi
On 02/01/2013 01:53 AM, Marek Olšák wrote:
Do you plan to merge this branch anytime soon?
Sorry, I almost forgot about that. Though, in theory, I'd like to get
some testing reports first confirming that it doesn't break everything
for the non-evergreen chips (I can only test on evergreen), b
When glCompressedTexImage is called the internalFormat is a specific
format for the incoming image and the the hardware format should be
the same (since we never do format transcoding). So use the simpler
_mesa_glenum_to_compressed_format() function. This change is also
needed for the next patch.
If we call glTexImage2D() with a generic compression format (e.g.
intFormat=GL_COMPRESSED_RGBA) we can't choose a DXT format if we
don't have the external DXT compression library.
We weren't actually enforcing this before since the
pipe_screen::is_format_supported(DXT) query has no dependency on
t
From: Tom Stellard
These instructions compare two floating point values and return an
integer true (-1) or false (0) value.
When compiling code generated by the Mesa GLSL frontend, the SET*_DX10
instructions save us four instructions for most branch decisions that
use floating-point comparisons.
Since transform feedback needs to be able to access individual fields
of varying structs, we can no longer match up the arguments to
glTransformFeedbackVaryings() with variables in the vertex shader.
Instead, we build up a hashtable which records information about each
possible name that is a cand
Previously, transform feedback varyings were parsed in an ad-hoc
fashion that wasn't compatible with structs (or array of structs).
This patch makes it use parse_program_resource_name(), which correctly
handles both.
Note that parse_program_resource_name()'s technique for handling
mal-formed input
There's actually nothing uniform-specific in uniform_field_visitor.
It is potentially useful for all kinds of program resources (in
particular, future patches will use it for transform feedback
varyings).
This patch renames it to program_resource_visitor, and clarifies
several comments, to reflect
The parsing logic is moved to a new function in the GLSL module,
parse_program_resource_name(). This name was chosen because it should
eventually be useful for handling everything that OpenGL 4.3 calls
"program resources" (e.g. uniforms, vertex inputs, fragment outputs,
and transform feedback vary
---
src/mesa/state_tracker/st_extensions.c |1 +
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 15 +++
2 files changed, 16 insertions(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 214588f..4d2d43d 100644
--- a/src/mesa/
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 994a551..6d556a2 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/
based on the intel driver
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 65 +---
1 file changed, 29 insertions(+), 36 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index bc29f8a..994a551 100644
--- a
EmitCondCodes is always false.
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index c6ac634..bc29f8a 100644
--- a
---
src/glsl/glsl_parser_extras.cpp |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index c8dbc89..7d826e3 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1195,8 +119
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index 471dd48..860e70f 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pip
---
src/gallium/drivers/r600/r600_pipe.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index a59578d..1698cb3 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r
https://bugs.freedesktop.org/show_bug.cgi?id=60121
--- Comment #2 from Andy Furniss ---
(In reply to comment #1)
> Try running under strace to see what's going wrong.
Below is what happens - I don't know why - it opens /usr/lib/vdpau OK but then
there are a bunch of fails and it ends up trying /
Hi,
On Wednesday, I will be stabilizing my LLVM tree in preparation for the
Mesa 9.1 release. From that point on, I will only accept bug fixes for
that tree. New feature development should be based off of the upstream LLVM
SVN tree (If you don't like SVN you can use git svn, it works well for
me
From: Tom Stellard
---
tests/cl/program/program-tester.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/cl/program/program-tester.c
b/tests/cl/program/program-tester.c
index 096cd2a..189b617 100644
--- a/tests/cl/program/program-tester.c
+++ b/tests/cl/program
From: Tom Stellard
This fixes indirect addressing when on 32-bit systems.
---
lib/Target/R600/AMDGPUInstrInfo.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/Target/R600/AMDGPUInstrInfo.h
b/lib/Target/R600/AMDGPUInstrInfo.h
index bca3aa2..5220aa0 100644
--- a/l
From: Tom Stellard
This is for the case when no processor is passed to the backend. This
prevents the
'' is not a recognized processor for this target (ignoring processor)
warning from being generated by clang.
---
lib/Target/R600/Processors.td |1 +
1 files changed, 1 insertions(+), 0 de
Do you plan to merge this branch anytime soon?
Marek
On Sat, Dec 29, 2012 at 5:36 PM, Vadim Girlin wrote:
> The patches are pretty big so you can find the branch here:
>
> http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-disasm
>
> My primary goal was to have a shader disassembler in the dri
Here's the branch:
git://people.freedesktop.org/~mareko/mesa rgbx-and-texstore
Please let me know when it can be pushed to master.
Marek
On Tue, Jan 29, 2013 at 7:00 PM, Ian Romanick wrote:
> I like these changes, but this hits some twitchy code. Do you have a branch
> somewhere that I could
From: Roland Scheidegger
The emulation of these if there's no rounding instruction available
is a bit more complicated than what the code did.
In particular, doing fp-to-int/int-to-fp will not work if the exponent
is large enough (and with NaNs, Infs). Hence such values need to be filtered
out an
On 01/31/2013 09:35 AM, Abdiel Janulgue wrote:
> Save miptree level info to DRIImage:
> - Appropriately-aligned base offset pointing to the image
> - Additional x/y adjustment offsets from above.
>
> In non-tile-aligned surface cases where resolving back to the original image
> located in mip-leve
https://bugs.freedesktop.org/show_bug.cgi?id=59967
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #10 from
On Don, 2013-01-31 at 18:03 +0100, Marek Olšák wrote:
> On Thu, Jan 31, 2013 at 5:39 PM, Michel Dänzer wrote:
> > I'm afraid these are not quite correct yet. I'm not 100% sure after
> > looking at the red book and the GL 3.x spec — this is head spinning
> > material, isn't it? :\ — but I think sw
FYI, I'm investigating now why the series breaks the Android build.
On 01/30/2013 05:40 AM, Abdiel Janulgue wrote:
> Mostly similar to V6 but rebased from
> 0ca384fb39f6d98af2de5654c46394743147d228.
> The only slight change is in patch 5 which uses bit-shifting to account for
> offsets instead o
Save miptree level info to DRIImage:
- Appropriately-aligned base offset pointing to the image
- Additional x/y adjustment offsets from above.
In non-tile-aligned surface cases where resolving back to the original image
located in mip-levels higher than the base level proves problematic due to
off
https://bugs.freedesktop.org/show_bug.cgi?id=60121
--- Comment #1 from Matt Turner ---
Try running under strace to see what's going wrong.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lis
On Thu, Jan 31, 2013 at 5:39 PM, Michel Dänzer wrote:
> I'm afraid these are not quite correct yet. I'm not 100% sure after
> looking at the red book and the GL 3.x spec — this is head spinning
> material, isn't it? :\ — but I think swapBytes only applies to the basic
> type, in these cases GL_BYT
From: Michel Dänzer
GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59364
Tested-by: Tom Stellard
Signed-off-by: Michel Dänzer
---
v2: Error out on --enable-xlib-glx --
On Don, 2013-01-31 at 17:06 +0100, Marek Olšák wrote:
> - swapBytes has no effect on 8-bit single-component formats
> - GL_SHORT is in host byte order, so checking for littleEndian is unnecessary,
> I decided to make the change for single-component formats only
Fair enough. BTW, the same is tru
Reviewed-by: Marek Olšák
Marek
On Thu, Jan 31, 2013 at 4:38 PM, wrote:
> From: Jerome Glisse
>
> We are now seing cs that can go over the vram+gtt size to avoid
> failing flush early cs that goes over 70% (gtt+vram) usage. 70%
> is use to allow some fragmentation.
>
> The idea is to compute a
On Thu, Jan 31, 2013 at 4:29 PM, Jerome Glisse wrote:
> On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák wrote:
>> On Wed, Jan 30, 2013 at 6:14 PM, wrote:
>>> From: Jerome Glisse
>>>
>>> We are now seing cs that can go over the vram+gtt size to avoid
>>> failing flush early cs that goes over 70%
On 01/30/2013 11:27 AM, Ian Romanick wrote:
From: Ian Romanick
Previously the loop_state was allocated in the loop_analysis
constructor, but not freed in the (nonexistent) destructor. Moving
the allocation of the loop_state makes this code appear less sketchy.
Either way, there is no actual l
https://bugs.freedesktop.org/show_bug.cgi?id=59967
--- Comment #9 from Johannes Obermayr ---
(In reply to comment #7)
> Johannes, I totally fail to see how your rant explains this problem at all.
Michel, thanks to making me thinking on this issue a second time.
First I thought it was an error b
- swapBytes has no effect on 8-bit single-component formats
- GL_SHORT is in host byte order, so checking for littleEndian is unnecessary,
I decided to make the change for single-component formats only
- for 8_8 formats, instead of littleEndian && !swapBytes,
use littleEndian != swapBytes to in
On 01/30/2013 04:16 AM, Ramesh Reddy Emmadi wrote:
> Hi,
>
> We are working on mesa-8.0.4 and compiling with opengles2 option and using
> the default glapi_gentable.c and glapitemp.h.
>
> We would like to know whether we can generate these two files for opengles2
> specific . if it is please le
I haven't got patch 3/3 but 1-2 look good. Below is a good idea.
(Of course, if would be even nicer if we redirected output to
src/gallium/tools/trace/dump.py via pipe/fdopen but that's quite hard to do in
a cross platform fashion)
- Original Message -
> ---
> src/gallium/drivers/trace
On Don, 2013-01-31 at 08:41 -0700, Brian Paul wrote:
> ---
> src/gallium/drivers/trace/tr_dump.c | 14 +++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/trace/tr_dump.c
> b/src/gallium/drivers/trace/tr_dump.c
> index 90befb0..0714e9a 10064
2013/1/31 Michel Dänzer :
> From: Michel Dänzer
>
> GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
>
NOTE: This is a candidate for the stable branches.
Reviewed-by: Andreas Boll
> Signed-off-by: Michel Dänzer
> ---
> configure.ac |8
> 1 file changed, 8 inserti
To get a rough idea of how much time is spent in each gallium driver
function. The time is measured in microseconds.
---
src/gallium/drivers/trace/tr_dump.c | 24
src/gallium/tools/trace/model.py|7 +--
src/gallium/tools/trace/parse.py| 11 ++-
---
src/gallium/drivers/trace/tr_dump.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_dump.c
b/src/gallium/drivers/trace/tr_dump.c
index 0714e9a..cd106af 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/drivers/trace/tr_d
---
src/gallium/drivers/trace/tr_dump.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_dump.c
b/src/gallium/drivers/trace/tr_dump.c
index 90befb0..0714e9a 100644
--- a/src/gallium/drivers/trace/tr_dump.c
+++ b/src/gallium/driver
From: Jerome Glisse
We are now seing cs that can go over the vram+gtt size to avoid
failing flush early cs that goes over 70% (gtt+vram) usage. 70%
is use to allow some fragmentation.
The idea is to compute a gross estimate of memory requirement of
each draw call. After each draw call, memory wi
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák wrote:
> On Wed, Jan 30, 2013 at 6:14 PM, wrote:
>> From: Jerome Glisse
>>
>> We are now seing cs that can go over the vram+gtt size to avoid
>> failing flush early cs that goes over 70% (gtt+vram) usage. 70%
>> is use to allow some fragmentation.
>
On Thu, Jan 31, 2013 at 9:34 AM, Michel Dänzer wrote:
> On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote:
>> - Original Message -
>> > On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
>> > >
>> > > - Original Message -
>> > > > For another example (which I suspect is mor
- Original Message -
> On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote:
> > - Original Message -
> > > On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
> > > >
> > > > - Original Message -
> > > > > For another example (which I suspect is more relevant for
> >
On 01/31/2013 01:35 AM, Andreas Boll wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60098
---
src/gallium/drivers/llvmpipe/lp_screen.c |1 +
src/gallium/drivers/nv30/nv30_screen.c |1 +
src/gallium/drivers/r300/r300_screen.c |1 +
src/gallium/driver
On Jan 31, 2013 2:51 AM, "Michel Dänzer" wrote:
>
> From: Michel Dänzer
>
> GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
>
> Signed-off-by: Michel Dänzer
> ---
> configure.ac |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> in
On Thu, Jan 31, 2013 at 11:50:46AM +0100, Michel Dänzer wrote:
> From: Michel Dänzer
>
> GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
>
This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=59364
Tested-by: Tom Stellard
> Signed-off-by: Michel Dänzer
> ---
> confi
On Don, 2013-01-31 at 06:42 -0800, Jose Fonseca wrote:
>
> - Original Message -
> > On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote:
> > > - Original Message -
> > > > On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
> > > > >
> > > > > - Original Message -
>
- Original Message -
> On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote:
> > - Original Message -
> > > On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
> > > >
> > > > - Original Message -
> > > > > For another example (which I suspect is more relevant for
> >
On Don, 2013-01-31 at 14:01 +, Ramesh Reddy Emmadi wrote:
>
> Got the error1 while compiling mesa-8.0.4 with the following
> configuration options and commented the "_mesa_BindBufferBase"
> function in src/mesa/main/bufferobj.c file. After this change able to
> compile the code successfully
https://bugs.freedesktop.org/show_bug.cgi?id=60121
Priority: medium
Bug ID: 60121
Assignee: mesa-dev@lists.freedesktop.org
Summary: build - libvdpau_softpipe fails at runtime.
Severity: normal
Classification: Unclassified
OS:
On Don, 2013-01-31 at 02:14 -0800, Jose Fonseca wrote:
> - Original Message -
> > On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
> > >
> > > - Original Message -
> > > > For another example (which I suspect is more relevant for this
> > > > thread),
> > > > wouldn't it be
Hi,
Got the error1 while compiling mesa-8.0.4 with the following configuration
options and commented the "_mesa_BindBufferBase" function in
src/mesa/main/bufferobj.c file. After this change able to compile the code
successfully, but while make install got one more error(error2). Can you pleas
https://bugs.freedesktop.org/show_bug.cgi?id=59851
--- Comment #3 from Tom Stellard ---
(In reply to comment #2)
> Created attachment 73992 [details] [review]
> Patch to fix mesa configure
>
> Patch fixed and with a different logic. Now force-enable LLVM shared
> libraries in a post-check, with
Hi Michel,
Thanks for your info.
Got the error1 while compiling mesa-8.0.4 with the following configuration
options and commented the "_mesa_BindBufferBase" function in
src/mesa/main/bufferobj.c file. After this change able to compile the code
successfully, but while make install got one mor
https://bugs.freedesktop.org/show_bug.cgi?id=59851
Quentin Glidic changed:
What|Removed |Added
Attachment #73648|0 |1
is obsolete|
On 31.01.2013 09:30, Michel Dänzer wrote:
> On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
>> - Original Message -
>>> On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote:
- Original Message -
> On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote:
>> I've b
From: Michel Dänzer
GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
Signed-off-by: Michel Dänzer
---
configure.ac |8
1 file changed, 8 insertions(+)
diff --git a/configure.ac b/configure.ac
index cfd52bf..62cc32b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -
On Don, 2013-01-31 at 09:29 +, Ramesh Reddy Emmadi wrote:
>
> OpenGL: no (ES1: no ES2: yes)
[...]
> make[4]: Entering directory
> `/home/amd/Downloads/testtrails/mesa-mesa-9.0.1/src/mesa'
>
> CC api_arrayelt.lo
>
> CC api_exec.lo
>
> ../../src/mesa/main/api_
Looks good. Though I wonder why I didn't see build failures here. What sort of
error did you get?
Jose
- Original Message -
> execinfo.h is not available on MinGW.
>
> Signed-off-by: Vinson Lee
> ---
> src/mapi/glapi/gen/gl_gentable.py | 2 +-
> 1 file changed, 1 insertion(+), 1 delet
- Original Message -
> On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
> >
> > - Original Message -
> > > On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote:
> > > >
> > > > - Original Message -
> > > > > On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote:
> >
Hi,
Thanks for your reply. We are working with mesa-8.0.4 on Ubuntu 12.04 and
compiling the mesa with following options(hardware rendering enabled) and found
that there is no Winsys is enabled for "radeon/drm" and it has only "SW"
winsys. After this we took mesa-9.0.1 and configured and fou
https://bugs.freedesktop.org/show_bug.cgi?id=60098
Andreas Boll changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |andreas.boll@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60098
---
src/gallium/drivers/llvmpipe/lp_screen.c |1 +
src/gallium/drivers/nv30/nv30_screen.c |1 +
src/gallium/drivers/r300/r300_screen.c |1 +
src/gallium/drivers/r600/r600_pipe.c |1 +
src/gallium/d
On Mit, 2013-01-30 at 08:35 -0800, Jose Fonseca wrote:
>
> - Original Message -
> > On Mit, 2013-01-30 at 06:12 -0800, Jose Fonseca wrote:
> > >
> > > - Original Message -
> > > > On Mon, 2013-01-28 at 06:56 -0500, Adam Jackson wrote:
> > > > > I've been looking at untangling the
83 matches
Mail list logo
