Ian Romanick writes:
> tom fogal wrote:
> > $ lib nm libOSMesa.so | grep "EGL"
> > 00064254 t _mesa_EGLImageTargetRenderbufferStorageOES
> > 000b30c0 t _mesa_EGLImageTargetTexture2DOES
> >U glEGLImageTargetRenderbufferStorageOES
> >U g
On Mon, Mar 15, 2010 at 8:04 PM, Keith Whitwell wrote:
> On Mon, 2010-03-15 at 04:27 -0700, Chia-I Wu wrote:
>> Hi list,
>>
>> gallium-st-api has come to the point that st/glx passes as many piglit
>> quick tests as st/glx in master does. I'd like to merge it to master
>> some time this week.
>>
http://bugs.freedesktop.org/show_bug.cgi?id=27097
Brian Paul changed:
What|Removed |Added
AssignedTo|mesa3d- |sitewrangl...@lists.freedesk
http://bugs.freedesktop.org/show_bug.cgi?id=27097
--- Comment #1 from Christopher Li 2010-03-15 15:17:31 PST
---
Created an attachment (id=34088)
--> (http://bugs.freedesktop.org/attachment.cgi?id=34088)
chrisl SSH public key
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.c
http://bugs.freedesktop.org/show_bug.cgi?id=27097
Summary: Rquest new fdo account for chr...@vmware.com
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: mediu
http://bugs.freedesktop.org/show_bug.cgi?id=27093
Summary: mesa-7.5.2: crash in wine tests (wine-1.1.40-122-
g693c991)
Product: Mesa
Version: 7.5
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Se
On Mon, 2010-03-15 at 12:20 -0700, michal wrote:
> Hi,
>
> I think the branch is now ready to be merged back to master. This is a
> non-trivial change, so things may break in the process. In particular,
> radeon and nv drivers haven't been even test-built, so if there's
> somebody who could tak
Hi,
I think the branch is now ready to be merged back to master. This is a
non-trivial change, so things may break in the process. In particular,
radeon and nv drivers haven't been even test-built, so if there's
somebody who could take a look at them in the following 24 hours, it
would be grea
On Mon, Mar 15, 2010 at 6:36 PM, Luca Barbieri wrote:
> This is a different approach to solving this problem that the patch
> I previously posted, and unlike that, should not cause any problems.
>
> Right now undefined symbols in DRI drivers will still allow the
> build to succeed.
>
> As a result
This is a different approach to solving this problem that the patch
I previously posted, and unlike that, should not cause any problems.
Right now undefined symbols in DRI drivers will still allow the
build to succeed.
As a result, people modifying drivers they cannot test risk creating
unloadabl
http://bugs.freedesktop.org/show_bug.cgi?id=27090
Summary: xorg_crtc.c won't compile because of change in libdrm
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: All
Status: NEW
Severity: normal
Priority:
On Mon, Mar 15, 2010 at 4:26 PM, Luca Barbieri wrote:
> Why not softpipe_dri.so?
> It would also be nice to have llvmpipe_dri.so (and once it is mature,
> make this the default one instead of swrast, since it is much faster).
>
it will support both softpipe and llvmpipe, gallium allows
interchang
Dan Nicholson writes:
> On Sun, Mar 14, 2010 at 5:38 PM, tom fogal wrote:
> > [I] volunteer[ed] to detect platform TLS support, + enable it in
> > Mesa / the X server if available.
> >
> > One thing I'm worried about is using an AC macro archive macro here;
> > it's GPL + an exception [. . .]
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marcin Baczyński wrote:
> 2010/3/13 Karl Schultz :
>> In some locales, a comma can be used as a decimal place. That is, 5,2 is a
>> number between 5 and 6. (I think I have that right) I would guess that the
>> shader language, like C, wouldn't allow
You are right: I'll see if I can find a better solution that does not
cause libGL to be loaded.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and f
>> Except that AC_PATH_XTRA returns X_LIBS without '-lX11', while
>> PKG_CHECK_MODULES returns X_LIBS with it. In the attached patch
>> I add '-lX11' to the former. Of course, with '-lX11' as part of X_LIBS, the
>> explicit '-lX11' can be removed from the places that use X_LIBS.
>
>Jeff, it shou
On Mon, 2010-03-15 at 15:00 +0100, Luca Barbieri wrote:
>
> Note that this introduces a dependency from the DRI drivers on libGL.so.1.
> However, the driver loader calls dlopen on libGL.so.1 with
> RTLD_GLOBAL | RTLD_NOW before loading any DRI driver, so the added
> dependency shouldn't cause cha
On Mon, 2010-03-15 at 14:30 +0100, Luca Barbieri wrote:
> Adding both -Wl,--no-undefined and -lGL (in
> src/gallium/winsys/drm/Makefile.template) seems to work for me.
>
> The driver loader is already loading libGL.so.1 with RTLD_NOW |
> RTLD_GLOBAL, so I think that the DRI driver depending on li
Why not softpipe_dri.so?
It would also be nice to have llvmpipe_dri.so (and once it is mature,
make this the default one instead of swrast, since it is much faster).
--
Download Intel® Parallel Studio Eval
Try the new soft
On Mon, 2010-03-15 at 07:24 -0700, michal wrote:
> Keith Whitwell wrote on 2010-03-15 15:19:
> > On Mon, 2010-03-15 at 07:08 -0700, michal wrote:
> >
> >> michal wrote on 2010-03-12 15:00:
> >>
> >>> michal wrote on 2010-03-11 17:59:
> >>>
> >>>
> Keith Whitwell wrote on 2010
Keith Whitwell wrote on 2010-03-15 15:19:
> On Mon, 2010-03-15 at 07:08 -0700, michal wrote:
>
>> michal wrote on 2010-03-12 15:00:
>>
>>> michal wrote on 2010-03-11 17:59:
>>>
>>>
Keith Whitwell wrote on 2010-03-11 16:16:
> On Thu, 2010-03
On Mon, 2010-03-15 at 07:08 -0700, michal wrote:
> michal wrote on 2010-03-12 15:00:
> > michal wrote on 2010-03-11 17:59:
> >
> >> Keith Whitwell wrote on 2010-03-11 16:16:
> >>
> >>
> >>> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> >>>
> >>>
> >>>
> Keith Whi
On Mon, Mar 15, 2010 at 9:35 AM, Luca Barbieri wrote:
> ---
> src/gallium/drivers/nv40/nv40_transfer.c | 181
> --
> 1 files changed, 0 insertions(+), 181 deletions(-)
> delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c
>
> diff --git a/src/gallium/drivers
michal wrote on 2010-03-12 15:00:
> michal wrote on 2010-03-11 17:59:
>
>> Keith Whitwell wrote on 2010-03-11 16:16:
>>
>>
>>> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
>>>
>>>
>>>
Keith Whitwell wrote on 2010-03-11 14:21:
>>
Right now undefined symbols in DRI drivers will still allow the
build to succeed.
As a result, people modifying drivers they cannot test risk creating
unloadable drivers with no easy way of automatically avoiding it.
For instance, the modifications to nv50 for context transfers caused
such an iss
On Mon, Mar 15, 2010 at 2:30 PM, Luca Barbieri wrote:
> Adding both -Wl,--no-undefined and -lGL (in
> src/gallium/winsys/drm/Makefile.template) seems to work for me.
>
Oh great, that works for me too !
--
Download Intel®
Adding both -Wl,--no-undefined and -lGL (in
src/gallium/winsys/drm/Makefile.template) seems to work for me.
The driver loader is already loading libGL.so.1 with RTLD_NOW |
RTLD_GLOBAL, so I think that the DRI driver depending on libGL.so.1
shouldn't introduce any issue.
--
---
src/gallium/drivers/nv40/nv40_transfer.c | 181 --
1 files changed, 0 insertions(+), 181 deletions(-)
delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c
diff --git a/src/gallium/drivers/nv40/nv40_transfer.c
b/src/gallium/drivers/nv40/nv40_transfer.c
del
On Sun, Mar 14, 2010 at 5:38 PM, tom fogal wrote:
> It was a long while back that I wondered && somehow ended up
> volunteering to detect platform TLS support, + enable it in Mesa / the
> X server if available.
>
> I got distracted before finishing the X parts, but rebased the Mesa
> parts, which
On Mon, Mar 15, 2010 at 5:24 AM, Julien Cristau wrote:
> On Sat, Mar 13, 2010 at 20:20:36 -0800, Jeff Smith wrote:
>> Except that AC_PATH_XTRA returns X_LIBS without '-lX11', while
>> PKG_CHECK_MODULES returns X_LIBS with it. In the attached patch
>> I add '-lX11' to the former. Of course, with
On Sat, Mar 13, 2010 at 20:20:36 -0800, Jeff Smith wrote:
> Except that AC_PATH_XTRA returns X_LIBS without '-lX11', while
> PKG_CHECK_MODULES returns X_LIBS with it. In the attached patch
> I add '-lX11' to the former. Of course, with '-lX11' as part of X_LIBS, the
> explicit '-lX11' can be remo
2010/3/15 Michel Dänzer :
>
> One problem is that drivers can be loaded from several paths; if the HW
> driver fails to load from the first path but succeeds from the next one,
> any error messages from the first attempt would be confusing.
>
If it fails to load because it does not exist ? Or beca
On Mon, 2010-03-15 at 04:27 -0700, Chia-I Wu wrote:
> Hi list,
>
> gallium-st-api has come to the point that st/glx passes as many piglit
> quick tests as st/glx in master does. I'd like to merge it to master
> some time this week.
>
> gallium-st-api implements a new interface, st_api.h, that ai
http://bugs.freedesktop.org/show_bug.cgi?id=27065
Chia-I Wu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
Hi list,
gallium-st-api has come to the point that st/glx passes as many piglit
quick tests as st/glx in master does. I'd like to merge it to master
some time this week.
gallium-st-api implements a new interface, st_api.h, that aims to be a
replacement for st_public.h. The new interface paves t
On Mon, Mar 15, 2010 at 3:11 AM, Ian Romanick wrote:
>
> If you're going to do this, please make a separate driver. Call it
> swrastg or something. I use swrast for testing new core Mesa features
> that I implement, and I don't want to be forced to muck about with
> Gallium to do that.
>
sure, i
Something in the recent statetracker and/or dri work
Here is some gdb,
I noticed this comment also:
/* DRI co-state tracker currently overrides flush_frontbuffer.
* When this is fixed, will need to pass the drawable in the
* fourth parameter here so that when Mesa calls
On Wed, Mar 10, 2010 at 6:47 AM, Keith Whitwell wrote:
> On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote:
>> On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell wrote:
>> > On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote:
>> >> On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell wrote:
>> >>
On Mon, 2010-03-15 at 00:09 +0100, Xavier Chantry wrote:
> 14:47 < lb1> the fact is that if you remove a function from mesa .c file,
> everything will succeed, but the resulting driver will fail to
> load
> 14:47 < lb1> because it cannot resolve that symbol
> 14:48 < lb1> not sure wh
39 matches
Mail list logo
