http://tinderbox.x.org/builds/2010-09-24-0001/logs/libGL/#build
radeon_drm_buffer.c:4:27: error: radeon_bo_gem.h: No such file or directory
radeon_drm_buffer.c:5:27: error: radeon_cs_gem.h: No such file or directory
In file included from radeon_drm_buffer.c:6:
radeon_buffer.h:41:23: error: radeon_
---
src/mesa/drivers/dri/sis/sis_context.c | 16
src/mesa/drivers/dri/sis/sis_screen.c |5 +-
src/mesa/drivers/dri/sis/sis_tex.c | 127
3 files changed, 17 insertions(+), 131 deletions(-)
diff --git a/src/mesa/drivers/dri/sis/sis_context.c
b/src/
---
src/mesa/drivers/dri/unichrome/via_context.c | 26 +
src/mesa/drivers/dri/unichrome/via_tex.c | 156 +-
2 files changed, 28 insertions(+), 154 deletions(-)
diff --git a/src/mesa/drivers/dri/unichrome/via_context.c
b/src/mesa/drivers/dri/unichrome/via_contex
This drops the texture format forcing like for mga.
---
src/mesa/drivers/dri/r128/r128_context.c | 17 +++--
src/mesa/drivers/dri/r128/r128_context.h |2 -
src/mesa/drivers/dri/r128/r128_screen.c |7 +-
src/mesa/drivers/dri/r128/r128_tex.c | 118 --
src/
---
src/mesa/drivers/dri/intel/intel_context.c| 52 +++
src/mesa/drivers/dri/intel/intel_tex.c|1 -
src/mesa/drivers/dri/intel/intel_tex.h|3 -
src/mesa/drivers/dri/intel/intel_tex_format.c | 201 -
src/mesa/main/texformat.c
Right now this is just tweaking the current code to look at the table.
Choosing actually supported formats will come later.
---
src/mesa/main/context.c |8 ++
src/mesa/main/mtypes.h|3 +
src/mesa/main/texformat.c | 235 +
3 files changed,
This drops the screen-depth-dependent texture formatting and
force-16-bits option. The (default) screen depth dependency of format
choice for unsized internal formats would have resulted in additional
banding on 16-bit screens since 32-bit textures would get truncated
down to 16 bits before dither
One of the uglier bits of the classic drivers, in my opinion, is the
ChooseTexFormat hook. Most drivers are trying to get to a similar set
of formats, and using similar fallbacks for unavailable formats.
Worse, they need to cleverly choose formats based on the incoming
type/format to avoid having
On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri wrote:
> Yes, that used to happen for me too.
>
> Just edit llvm-config to remove the offending text and ideally file a
> bug on the LLVM bug tracker.
>
looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220
thanks :)
It's sti
https://bugs.freedesktop.org/show_bug.cgi?id=29789
nobled changed:
What|Removed |Added
CC||nob...@dreamwidth.org
--- Comment #6 from noble
> In any case, this change causes a ton of conformance failures. Several
> piglit tests in the "general" category also fail.
Yes, sorry, I actually run piglit, but twice on the same binary...
The problem was that last_tile_addr must be invalidated on any change
including flushes.
This was automat
Changes in v2:
- Invalidate last_tile_addr on any change, fixing regressions
- Correct coding style
Currently softpipe ends up allocating more than 200 MB of memory
for each context due to the tile caches.
Even worse, this memory is all explicitly cleared, which means that the
kernel must actuall
I'm fine with that. When I first started contributing, I didn't have it
installed and wondered why everything was so broken. Somehow I misread the
'makedepend' line in the output as 'make depend', and didn't realize that it
was a separate program I needed to install.
__
On Wed, Sep 22, 2010 at 6:15 AM, Dave Airlie wrote:
> On Wed, Sep 22, 2010 at 7:50 PM, Keith Whitwell
> wrote:
>> On Wed, Sep 22, 2010 at 10:30 AM, Dave Airlie wrote:
>>> So Evergreen hardware appears to have only completely separate depth
>>> and stencil buffers and doesn't natively support a c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It looks like most of the bugs on the tracker have been fixed. The
remaining bugs are:
Bug 27831 - [regression] DynamicBranching3 does not render correctly:
I've been looking into this, but I haven't made much progress. I don't
know that it will ge
https://bugs.freedesktop.org/show_bug.cgi?id=30353
--- Comment #2 from Sergey Kondakov 2010-09-24 08:09:19
PDT ---
so, it did built with '-j1' passed to make and with llvm support disabled.
but it was fruitless - it just installed 32 bit binaries into supplied libdir.
--
Configure bugmail: htt
On 09/24/2010 07:20 AM, Luca Barbieri wrote:
Currently softpipe ends up allocating more than 200 MB of memory
for each context due to the tile caches.
Even worse, this memory is all explicitly cleared, which means that the
kernel must actually back it with physical RAM right away.
This change a
https://bugs.freedesktop.org/show_bug.cgi?id=30333
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Currently makedepend is used by the Mesa Makefile-based build system,
but not required.
Unfortunately, not having it makes dependency resolution non-existent,
which is a source of subtle bugs, and is a rarely tested
configuration, since all Mesa developers likely have it installed.
Furthermore so
This is needed to be able to use EGL on any existing X window, and
seems a good idea in general,
Rejecting single-buffered configs should be done in EGL itself if
necessary, and not in the native API.
---
src/gallium/state_trackers/egl/x11/native_dri2.c |4
1 files changed, 0 insertions(
Currently softpipe ends up allocating more than 200 MB of memory
for each context due to the tile caches.
Even worse, this memory is all explicitly cleared, which means that the
kernel must actually back it with physical RAM right away.
This change allocates tile memory on demand.
---
src/galliu
Currently softpipe ends up allocating more than 200 MB of memory
for each context due to the tile caches.
Even worse, this memory is all explicitly cleared, which means that the
kernel must actually back it with physical RAM right away.
This change allocates tile memory on demand.
---
src/galliu
This is needed to be able to use EGL on any existing X window, and
seems a good idea in general,
Rejecting single-buffered configs should be done in EGL itself if
necessary, and not in the native API.
---
src/gallium/state_trackers/egl/x11/native_dri2.c |4
1 files changed, 0 insertions(
Yes, that used to happen for me too.
Just edit llvm-config to remove the offending text and ideally file a
bug on the LLVM bug tracker.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Looks good to me Marek -- good catch.
Keith
On Thu, 2010-09-23 at 17:42 -0700, Marek Olšák wrote:
> NOTE: This is a candidate for the 7.9 branch.
> ---
> src/gallium/auxiliary/util/u_pack_color.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/gallium/auxiliar
On Fri, Sep 24, 2010 at 14:06:51 +0200, Xavier Chantry wrote:
> When gallium llvm is enabled, configure.ac does the following :
> LLVM_CFLAGS=`$LLVM_CONFIG --cflags`
>
> This is the result on my system :
> -I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -O2
When gallium llvm is enabled, configure.ac does the following :
LLVM_CFLAGS=`$LLVM_CONFIG --cflags`
This is the result on my system :
-I/usr/include -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC
I specifically set -O0 to easier gdb debugging
Currently makedepend is used by the Mesa Makefile-based build system,
but not required.
Unfortunately, not having it makes dependency resolution non-existent,
which is a source of subtle bugs, and is a rarely tested
configuration, since all Mesa developers likely have it installed.
Furthermore so
I think this is a good idea. It might reduce the number of bugs fixed by git
clean -fdx + rebuild. However we have discussed this before and there were
some objections.
Marek
On Fri, Sep 24, 2010 at 11:55 AM, Luca Barbieri wrote:
> Currently makedepend is used by the Mesa Makefile-based build sy
https://bugs.freedesktop.org/show_bug.cgi?id=30355
--- Comment #6 from Martin Stolpe 2010-09-24 03:39:54
PDT ---
Created an attachment (id=38928)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38928)
mesa configure options
Now it compiles. Thank you!
The d3d1x state tracker is the only p
https://bugs.freedesktop.org/show_bug.cgi?id=30355
--- Comment #5 from Luca Barbieri 2010-09-24 03:01:02
PDT ---
Unfortunately, the Mesa build system still uses makedepend.
It would be a good idea to make it an hard dependency though, since it causes
silent errors otherwise.
The link error shou
Currently makedepend is used by the Mesa Makefile-based build system,
but not required.
Unfortunately, not having it makes dependency resolution non-existent,
which is a source of subtle bugs, and is a rarely tested
configuration, since all Mesa developers likely have it installed.
Furthermore so
https://bugs.freedesktop.org/show_bug.cgi?id=30355
--- Comment #4 from Martin Stolpe 2010-09-24 02:36:22
PDT ---
makedepend was indeed missing. Learned something new today. ;-)
On wikipedia I read, that makedepend isn't really used anymore: "makedepend...
has since become superseded by the depe
https://bugs.freedesktop.org/show_bug.cgi?id=30345
Nikolay Rysev changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30355
--- Comment #3 from Luca Barbieri 2010-09-24 02:09:22
PDT ---
Yes, but it should be automatically generated.
Are you perhaps compiling without /usr/bin/makedepend installed?
If so, installing the makedepend package should fix this.
I'll see wh
https://bugs.freedesktop.org/show_bug.cgi?id=30355
--- Comment #2 from Martin Stolpe 2010-09-24 01:59:23
PDT ---
No, it doesn't compile. The reason is that there is no "sm4_defs.h" file in
"mesa/src/gallium/state_trackers/d3d1x/d3d1xshader/include/".
--
Configure bugmail: https://bugs.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=29646
--- Comment #5 from Michel Dänzer 2010-09-24 00:29:00 PDT
---
(In reply to comment #4)
> So, I'd think that if glxDestroyPixmap() can follow XDestroyPixmap() the GLX
> pixmap X ID has to be kept around and not deallocated in the server until
> g
37 matches
Mail list logo
