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 pixel format code
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 +
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 found
- 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:
I've been looking
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 v...@freedesktop.org
---
src/mapi/glapi/gen/gl_gentable.py | 2 +-
1 file changed, 1
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_exec.c:
From: Michel Dänzer michel.daen...@amd.com
GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
configure.ac |8
1 file changed, 8 insertions(+)
diff --git a/configure.ac b/configure.ac
index cfd52bf..62cc32b
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 been looking at
https://bugs.freedesktop.org/show_bug.cgi?id=59851
Quentin Glidic sardemff7+freedesk...@sardemff7.net changed:
What|Removed |Added
Attachment #73648|0 |1
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 more
https://bugs.freedesktop.org/show_bug.cgi?id=59851
--- Comment #3 from Tom Stellard tstel...@gmail.com ---
(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
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 please
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 nice if the software
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
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, but
- 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
this
On Thu, Jan 31, 2013 at 11:50:46AM +0100, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
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 thomas.stell...@amd.com
On Jan 31, 2013 2:51 AM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
configure.ac |8
1 file changed, 8
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 +
- 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
this
On Thu, Jan 31, 2013 at 9:34 AM, Michel Dänzer mic...@daenzer.net 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
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák mar...@gmail.com wrote:
On Wed, Jan 30, 2013 at 6:14 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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.
From: Jerome Glisse jgli...@redhat.com
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
---
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
+++
---
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
+++
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 ++-
2013/1/31 Michel Dänzer mic...@daenzer.net:
From: Michel Dänzer michel.daen...@amd.com
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 andreas.boll@gmail.com
Signed-off-by: Michel Dänzer
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 100644
---
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 -
---
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 let us
https://bugs.freedesktop.org/show_bug.cgi?id=59967
--- Comment #9 from Johannes Obermayr johannesoberm...@gmx.de ---
(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
On 01/30/2013 11:27 AM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
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
On Thu, Jan 31, 2013 at 4:29 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Wed, Jan 30, 2013 at 10:35 PM, Marek Olšák mar...@gmail.com wrote:
On Wed, Jan 30, 2013 at 6:14 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
We are now seing cs that can go over the vram+gtt
Reviewed-by: Marek Olšák mar...@gmail.com
Marek
On Thu, Jan 31, 2013 at 4:38 PM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
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
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 true
From: Michel Dänzer michel.daen...@amd.com
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 thomas.stell...@amd.com
Signed-off-by: Michel
On Thu, Jan 31, 2013 at 5:39 PM, Michel Dänzer mic...@daenzer.net 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
https://bugs.freedesktop.org/show_bug.cgi?id=60121
--- Comment #1 from Matt Turner matts...@gmail.com ---
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
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
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 of
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 mic...@daenzer.net 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? :\ —
https://bugs.freedesktop.org/show_bug.cgi?id=59967
Mike Lothian m...@fireburn.co.uk changed:
What|Removed |Added
CC||m...@fireburn.co.uk
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-levels
From: Roland Scheidegger srol...@vmware.com
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
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 i...@freedesktop.org wrote:
I like these changes, but this hits some twitchy code. Do you have a branch
Do you plan to merge this branch anytime soon?
Marek
On Sat, Dec 29, 2012 at 5:36 PM, Vadim Girlin vadimgir...@gmail.com 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
From: Tom Stellard thomas.stell...@amd.com
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
From: Tom Stellard thomas.stell...@amd.com
---
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
---
https://bugs.freedesktop.org/show_bug.cgi?id=60121
--- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com ---
(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
---
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
+++
---
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
---
---
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
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
---
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
---
---
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
+++
---
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
---
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
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
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
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
From: Tom Stellard thomas.stellard at amd.com
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
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
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
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),
https://bugs.freedesktop.org/show_bug.cgi?id=59494
lu hua huax...@intel.com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #5 from
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
---
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
https://bugs.freedesktop.org/show_bug.cgi?id=60143
Daniel van Vugt daniel.van.v...@canonical.com changed:
What|Removed |Added
See Also|
https://bugs.freedesktop.org/show_bug.cgi?id=60143
--- Comment #1 from Daniel van Vugt daniel.van.v...@canonical.com ---
Or even simpler fix...
bo-base.base.format = format;
--
You are receiving this mail because:
You are the assignee for the bug.
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
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
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
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
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
---
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
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
---
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
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
---
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
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
---
Fixes resource leak defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
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
76 matches
Mail list logo
