mesa3d-dev

[Mesa3d-dev] r300g broken frontbuffer rendering.

[Dave A. <ai...@gm...>]

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
       * flush_frontbuffer directly (in front-buffer rendering), it
       * will have access to the drawable argument:
       */

gdb) r
Starting program: /home/airlied/mesa/progs/trivial/clear
[Thread debugging using libthread_db enabled]
GL_RENDERER   = Gallium 0.4 on RV530
GL_VERSION    = 2.1 Mesa 7.9-devel
GL_VENDOR     = X.Org R300 Project

Program received signal SIGSEGV, Segmentation fault.
dri_flush_frontbuffer (screen=0x805dda8, surf=0x80e9c50, context_private=0x0)
    at dri_drawable.c:313
313	   __DRIdrawable *dri_drawable = ctx->dPriv;
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-8.fc12.i686 libICE-1.0.6-1.fc12.i686
libSM-1.1.0-7.fc12.i686 libX11-1.3-1.fc12.i686
libXdamage-1.1.2-1.fc12.i686 libXext-1.1-2.fc12.i686
libXfixes-4.0.4-1.fc12.i686 libXi-1.3-2.fc12.i686
libXmu-1.0.5-1.fc12.i686 libXt-1.0.7-1.fc12.i686
libXxf86vm-1.1.0-1.fc12.i686 libgcc-4.4.3-4.fc12.i686
libstdc++-4.4.3-4.fc12.i686 libuuid-2.16.2-5.fc12.i686
libxcb-1.5-1.fc12.i686
(gdb) print ctx
$1 = (struct dri_context *) 0x0
(gdb) bt
#0  dri_flush_frontbuffer (screen=0x805dda8, surf=0x80e9c50,
    context_private=0x0) at dri_drawable.c:313
#1  0xb7cb2029 in display_front_buffer (st=<value optimized out>)
    at state_tracker/st_cb_flush.c:81
#2  st_glFlush (st=<value optimized out>) at state_tracker/st_cb_flush.c:140
#3  0xb7cd4b42 in _mesa_flush (ctx=0x8083e30) at main/context.c:1501
#4  0xb7cd4cdd in _mesa_Flush () at main/context.c:1533
#5  0x08048c03 in Draw () at clear.c:74
#6  0xb7fd71be in processWindowWorkList (window=<value optimized out>)
    at glut_event.c:1307
#7  0xb7fd81b1 in __glutProcessWindowWorkLists () at glut_event.c:1358
#8  glutMainLoop () at glut_event.c:1379
#9  0x08048bc5 in main (argc=1, argv=0xbffff2d4) at clear.c:126
(gdb) break st_make_current
Breakpoint 1 at 0xb7cb2f2d: file state_tracker/st_context.c, line 277.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/airlied/mesa/progs/trivial/clear
[Thread debugging using libthread_db enabled]

Breakpoint 1, st_make_current (st=0x80c0188, draw=0x80e95c8, read=0x80e95c8,
    winsys_drawable_handle=0x0) at state_tracker/st_context.c:277
277	{
(gdb) bt
#0  st_make_current (st=0x80c0188, draw=0x80e95c8, read=0x80e95c8,
    winsys_drawable_handle=0x0) at state_tracker/st_context.c:277
#1  0xb7c8b719 in dri_make_current (cPriv=0x8061238, driDrawPriv=0x80e78c8,
    driReadPriv=0x80e78c8) at dri_context.c:170
#2  0xb7c86c36 in driBindContext (pcp=0x8061238, pdp=0x80e78c8, prp=0x80e78c8)
    at ../common/dri_util.c:187
#3  0xb7f4157c in dri2BindContext (context=0x8055600, draw=0x80e7828,
    read=0x80e7828) at dri2_glx.c:112
#4  0xb7f1d1da in MakeContextCurrent (dpy=0x804a048, draw=71303169,
    read=71303169, gc=0x8063010) at glxcurrent.c:376
#5  0xb7f1d573 in glXMakeCurrent (dpy=0x804a048, draw=71303169, gc=0x8063010)
    at glxcurrent.c:502
#6  0xb7fe1db9 in __glutSetWindow (window=0x8055028) at glut_win.c:157
#7  0xb7fe26a6 in __glutCreateWindow (parent=0x0, x=0, y=0, width=256,
    height=256, gameMode=0) at glut_win.c:698
#8  0xb7fe291e in glutCreateWindow (
    title=0xbffff46f "/home/airlied/mesa/progs/trivial/clear")
    at glut_win.c:731
#9  0x08048aee in main (argc=1, argv=0xbffff2d4) at clear.c:117
(gdb) up
#1  0xb7c8b719 in dri_make_current (cPriv=0x8061238, driDrawPriv=0x80e78c8,
    driReadPriv=0x80e78c8) at dri_context.c:170
170	      st_make_current(ctx->st, draw->stfb, read->stfb, NULL);

Dave.

Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!

[Dave A. <ai...@gm...>]

On Wed, Mar 10, 2010 at 6:47 AM, Keith Whitwell <ke...@vm...> wrote:
> On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote:
>> On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell <ke...@vm...> wrote:
>> > On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote:
>> >> On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell <ke...@vm...> wrote:
>> >> > This leaves r300g as the only remaining user of
>> >> > pipe_winsys/u_simple_screen - which means we can rename that code
>> >> > r300_winsys and pull it into that driver...
>> >>
>> >> Dave had some code that "fixes" this, I think. I more or less agreed
>> >> to stay out of it, but I might take a look if killing u_simple_screen
>> >> is a priority.
>> >
>> > It's just a cleanup at this point, no urgency.
>>
>> I'll try and merge the easy bits of my branch to get drop u_simple_screen
>> first.
>>
>> then worry about the cached mgr stuff.
>
> Sure, whenever it's convenient.

Okay I've pushed the r300g winsys/screen interface update, feel free to
kill u_simple_screen with fire.

Dave.

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

[Michel D. <mi...@da...>]

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 why
> 14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on
>              undefined symbols
> 14:48 < lb1> maybe the makefiles disable that checking
> 
> Can anyone shed any light on this, why the driver always succeeds to
> build and link even in the case of undefined symbols ?

One complication is that the driver needs symbols from libGL and vice
versa. Probably nothing that can't be solved with sufficient
toolchain-fu though.


> The second question is why the dlopen errors are not visible by
> default and require LIBGL_DEBUG=verbose to be displayed.
> It does not make sense to always print these errors by default ?

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.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification

[Younes M. <you...@gm...>]

On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri <lu...@lu...> wrote:
> Currently the nv30 and nv40 Gallium drivers are very similar, and
> contain about 5000 lines of essentially duplicate code.
>
> I prepared a patchset (which can be found at
> http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes)
> which gradually unifies the drivers, one file per the commit.
>
> A new "nvfx" directory is created, and unified files are put there one by one.
> After all patches are applied, the nv30 and nv40 directories are
> removed and the only the new nvfx directory remains.
>
> The first patches unify the engine naming (s/curie/eng3d/g;
> s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants.
> Initial versions of this work changed renouveau.xml to create a new
> "NVFXTCL" object, but the current version doesn't need any
> renouveau.xml modification at all.
>
> The "unification+fixes" branch referenced above is the one that should
> be tested.
> The "unification" branch contains just the unification, with no
> behavior changes, while "unification+fixes" also fixes swtnl and quad
> rendering, allowing to better test the unification. Some cleanups on
> top of the unfication are also included.
>
> That same repository also contains other branches with significant
> improvements on top of the unification, but I'm still not proposing
> them for inclusion as they need more testing and some fixes.
>
> While there are some branches in the Mesa repository that would
> conflict with this, such branches seem to be popping up continuously
> (and this is good!), so waiting until they are merged probably won't
> really work.
>
> The conflicts are minimal anyway and the driver fixes can be very
> easily reconstructed over the unified codebase.
>
> How about merging this?
> Any objections? Any comments?

Pushed. Thanks.

[Mesa3d-dev] [PATCH] Correct GL_EQUIV code in r67/7xx.

[Matthew W. S. B. <ma...@be...>]

From 247e121106e8d3e389f2e5a6edf13ea70ac18df7 Mon Sep 17 00:00:00 2001

These seem to be documented in
<http://www.svgopen.org/2003/papers/RasterOperationsUsingFilterElements/index.html>.
---
 src/mesa/drivers/dri/r600/r700_state.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/r600/r700_state.c
b/src/mesa/drivers/dri/r600/r700_state.c
index 6f156b5..12eaebb 100644
--- a/src/mesa/drivers/dri/r600/r700_state.c
+++ b/src/mesa/drivers/dri/r600/r700_state.c
@@ -614,7 +614,7 @@ static GLuint translate_logicop(GLenum logicop)
 	case GL_XOR:
 		return 0x66;
 	case GL_EQUIV:
-		return 0xaa;
+		return 0x99;
 	case GL_AND_REVERSE:
 		return 0x44;
 	case GL_AND_INVERTED:
-- 
1.7.0

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

George Sapountzis wrote:
> Hi,
> 
> I put some patches at
> http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do
> the plumbing in order to build the swrast_dri wrapper around gallium
> instead of classic mesa. For reference, swrast_dri is the fallback
> driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It
> must not link with libdrm, nor use any drm headers during building
> because it is also used on platforms without drm.
> 
> The branch is to the point where glxinfo runs and needs some glue with
> __DRIswrastLoaderExtension in order to show something other than black
> windows. The problem is that there seems to be two places where to put
> the glue, either in st/.../dri_drawable.c or in
> ws/.../swrast_drm_api.c . Can someone more familiar with gallium take
> a look at the branch and provide hints ?

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.

Thanks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkudiSoACgkQX1gOwKyEAw8lTgCeIivQ/MSPks11BOP6I/JRrCGj
rwEAnRkZ0ZYPUFsD3Bs1+qOXjWiTbXaM
=T1u6
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

[Xavier C. <cha...@gm...>]

On Mon, Mar 15, 2010 at 1:18 AM, tom fogal <tf...@al...> wrote:
> Xavier Chantry <cha...@gm...> writes:
>> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
>> 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \
>>               ../../common/driverfuncs.o ../common/utils.o swrast.o swrast_sp
>> an.o
>>  ../../../../../src/mesa/libmesa.a    -ldrm   -lexpat -lm -lpthread
>> -ldl
>> mklib: Making Linux shared library:  swrast_dri.so
>> LDFLAGS : -Wl,--no-allow-shlib-undefined
>> /lib/libpthread.so.0: undefined reference to `_dl_allocate_tls@GLIBC_PRIVATE'
>> /lib/libpthread.so.0: undefined reference to
>> `_dl_get_tls_static_info@GLIBC_PRIVATE'
>
> These look like TLS issues.
>
> Did you provide --enable-glx-tls to configure?  Looks like you probably
> want to, for your platform.
>

I did have --enable-glx-tls
I wonder if there are some problems with my system :
$ readelf -s /lib/libpthread.so.0  | grep tls
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls_init@GLIBC_PRIVATE (11)
    29: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls@GLIBC_PRIVATE (11)
    30: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_deallocate_tls@GLIBC_PRIVATE (11)
    39: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
__tls_get_addr@GLIBC_2.3 (15)
    43: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_get_tls_static_info@GLIBC_PRIVATE (11)
   216: 000000000021b308     8 OBJECT  LOCAL  HIDDEN   29 __static_tls_align_m1
   274: 0000000000006390   314 FUNC    LOCAL  HIDDEN   12
__pthread_init_static_tls
   282: 0000000000010e04    12 OBJECT  LOCAL  DEFAULT   15
_thread_db_link_map_l_tls
   396: 000000000021b320     8 OBJECT  LOCAL  HIDDEN   29 __static_tls_size
   457: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls_init@@GL
   552: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_allocate_tls@@GLIBC_P
   555: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_deallocate_tls@@GLIBC
   587: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
__tls_get_addr@@GLIBC_2.3
   625: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_dl_get_tls_static_info@@

Assuming UND means undefined. This does not look too good.
I am curious to know how it looks like on other systems.

[Mesa3d-dev] [PATCHes] RFC: detect TLS during configuration

[tom f. <tf...@al...>]

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 are attached.

One thing I'm worried about is using an AC macro archive macro here;
it's GPL + an exception that "configure" (the output) is unrestricted.
I'm not sure that'll be kosher for Mesa.

OTOH, the macro is dead simple.

Comments?

-tom

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

[tom f. <tf...@al...>]

Xavier Chantry <cha...@gm...> writes:
> On Mon, Mar 15, 2010 at 12:41 AM, tom fogal <tf...@al...> wrote:
> >
> > You can emulate the [undefined link errors] by building with
> > -Wl,--no-undefined (or maybe -no-undefined, something like that,
> > see ld(1)).
>
> With -Wl,--no-undefined, I get so many errors that it did not fit in
> my terminal buffer :P
> 
> With -Wl,--no-allow-shlib-undefined it's a bit better but it is still scary :

Oops, sorry; I was thinking of that flag, but I forgot about the shlib
variant && expected --no-undefined to do --no-allow-shlib-undefined.
Anyway, mea culpa, glad you figured out what I meant && not what I said
;)

> /bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
> 'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \
> 		../../common/driverfuncs.o ../common/utils.o swrast.o swrast_sp
> an.o
>  ../../../../../src/mesa/libmesa.a    -ldrm   -lexpat -lm -lpthread
> -ldl
> mklib: Making Linux shared library:  swrast_dri.so
> LDFLAGS : -Wl,--no-allow-shlib-undefined
> /lib/libpthread.so.0: undefined reference to `_dl_allocate_tls@GLIBC_PRIVATE'
> /lib/libpthread.so.0: undefined reference to
> `_dl_get_tls_static_info@GLIBC_PRIVATE'

These look like TLS issues.

Did you provide --enable-glx-tls to configure?  Looks like you probably
want to, for your platform.

-tom

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

[Xavier C. <cha...@gm...>]

On Mon, Mar 15, 2010 at 12:41 AM, tom fogal <tf...@al...> wrote:
>
> That's just the default compiler/linker setup on Linux.  This is in
> contrast to, say, OS X, where undefined symbols cause link errors.
>
> You can emulate the above by building with -Wl,--no-undefined (or maybe
> -no-undefined, something like that, see ld(1)).
>

Looks like I am entering in a dangerous territory.
With -Wl,--no-undefined, I get so many errors that it did not fit in
my terminal buffer :P
http://paste.pocoo.org/show/189694/

With -Wl,--no-allow-shlib-undefined it's a bit better but it is still scary :

/bin/sh ../../../../../bin/mklib -o swrast_dri.so -noprefix -linker
'gcc' -ldflags '-Wl,--no-allow-shlib-undefined' \
		../../common/driverfuncs.o ../common/utils.o swrast.o swrast_span.o
 ../../../../../src/mesa/libmesa.a    -ldrm   -lexpat -lm -lpthread
-ldl
mklib: Making Linux shared library:  swrast_dri.so
LDFLAGS : -Wl,--no-allow-shlib-undefined
/lib/libpthread.so.0: undefined reference to `_dl_allocate_tls@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to
`_dl_get_tls_static_info@GLIBC_PRIVATE'
/lib/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdl.so:
undefined reference to `_rtld_global_ro@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `__tls_get_addr@GLIBC_2.3'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdrm.so:
undefined reference to `clock_gettime@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.3/../../../../lib/libdl.so:
undefined reference to `_dl_rtld_di_serinfo@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to
`_dl_make_stack_executable@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to
`_dl_allocate_tls_init@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `_rtld_global@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `__libc_stack_end@GLIBC_2.2.5'
/lib/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE'
/lib/libpthread.so.0: undefined reference to `_dl_deallocate_tls@GLIBC_PRIVATE'
collect2: ld returned 1 exit status

This is with swrast, but the result with nouveau was quite similar.

Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification

[STEVE555 <ste...@ho...>]

Dear Luca,
               I got your latest commits for your branch,did a make clean
instead of make -B realclean as I usaully do and did an autoreconf -iv,then
.autogen.sh with my configure options I mentioned earlier to ths thread.I
then ran make and make install instead of gmake and gmake install,and
rebooted.
When I did export LIBGL_DRIVERS_PATH=/usr/local/lib/dri(then return) and ran
glxinfo again,the error message appeared again.I then did a ldd
/usr/bin/glxinfo in terminal I exported on and it was showing that it was
pointing to libGL.so in /usr/lib.
So I exported LD_LIBRARY_PATH=/usr/local/lib in the same Konsole window and
ran glxinfo again.This time,the errors disappeared.I like to thank you for
your advice.
Regards,
            STEVE555


 

Xavier Chantry-3 wrote:
> 
> On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell
> <kei...@go...> wrote:
>> On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell
>> <kei...@go...> wrote:
>>> Sounds good to me - fewer driver directories to fix up after changes...
>>>
>>
>> It'd be good to get this merged sooner rather than later as I'll soon
>> be starting on pipe_resources conversion for the nv drivers.  Once I
>> do that, there will be heaps of conflicts with your patches, but if I
>> can merge them in before I do the conversion all will be well...
>>
> 
> I tested unification+fixes branch on nv35 with 11 games that you can
> see on that page :
> http://nouveau.freedesktop.org/wiki/XavierChantry
> 
> No regression to report compared to mesa master.
> 
> A benefit worth mentioning is the SWTNL support which allows to run
> the 4 games currently broken with mesa master.
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/-PATCH--nv30-nv40-Gallium-drivers-unification-tp27889377p27899191.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

[tom f. <tf...@al...>]

Xavier Chantry <cha...@gm...> writes:
> 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 l
> oad
> 14:47 < lb1> because it cannot resolve that symbol
> 14:48 < lb1> not sure why
> 14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on
>              undefined symbols
> 14:48 < lb1> maybe the makefiles disable that checking
> 
> Can anyone shed any light on this, why the driver always succeeds to
> build and link even in the case of undefined symbols ?

That's just the default compiler/linker setup on Linux.  This is in
contrast to, say, OS X, where undefined symbols cause link errors.

You can emulate the above by building with -Wl,--no-undefined (or maybe
-no-undefined, something like that, see ld(1)).

> The second question is why the dlopen errors are not visible by
> default and require LIBGL_DEBUG=verbose to be displayed.
> It does not make sense to always print these errors by default ?

Doesn't effect me personally, but errors coming up on stderr does seem
like reasonable default behavior to me.  Is it actually the case that
these are always errors though (i.e. if a dlopen fails, does a higher
level try loading a different driver which might succeed?)?

-tom

Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification

[Xavier C. <cha...@gm...>]

On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell
<kei...@go...> wrote:
> On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell
> <kei...@go...> wrote:
>> Sounds good to me - fewer driver directories to fix up after changes...
>>
>
> It'd be good to get this merged sooner rather than later as I'll soon
> be starting on pipe_resources conversion for the nv drivers.  Once I
> do that, there will be heaps of conflicts with your patches, but if I
> can merge them in before I do the conversion all will be well...
>

I tested unification+fixes branch on nv35 with 11 games that you can
see on that page :
http://nouveau.freedesktop.org/wiki/XavierChantry

No regression to report compared to mesa master.

A benefit worth mentioning is the SWTNL support which allows to run
the 4 games currently broken with mesa master.

Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification

[Keith W. <kei...@go...>]

On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell
<kei...@go...> wrote:
> Sounds good to me - fewer driver directories to fix up after changes...
>

It'd be good to get this merged sooner rather than later as I'll soon
be starting on pipe_resources conversion for the nv drivers.  Once I
do that, there will be heaps of conflicts with your patches, but if I
can merge them in before I do the conversion all will be well...

Keith

[Mesa3d-dev] undefined symbols and silent fallback to swrast

[Xavier C. <cha...@gm...>]

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 why
14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on
             undefined symbols
14:48 < lb1> maybe the makefiles disable that checking

Can anyone shed any light on this, why the driver always succeeds to
build and link even in the case of undefined symbols ?

The second question is why the dlopen errors are not visible by
default and require LIBGL_DEBUG=verbose to be displayed.
It does not make sense to always print these errors by default ?

Re: [Mesa3d-dev] Compiler warnings when building Mesa

[Jeff S. <why...@ya...>]

>From: Johannes Obermayr <joh...@gm...>

>To: mesa3d-dev <mes...@li...>
>Sent: Sun, March 14, 2010 1:30:27 PM
>Subject: [Mesa3d-dev] Compiler warnings when building Mesa
>
>Hi,
>
>here is a list with compiler warnings I have seen for a longer time.
>
>Just for info:
>libdrm: 20100313
>XServer: 1.7.5
>protos/macros: 20100311 
>
>I can also provide a full log (~1.4 MiB).
>
>Please decide whether fixing them is necessary/worth ...
>
>Thanks.
>Johannes

I sent patches for some of the warnings I found recently.  Most were
accepted, and one is still under review (for the dri2_glx.c warnings).

Most of the warnings are related to pointer casting, or unreferenced code.
But one of the remaining warnings appears to point to a real issue:
...
brw_vs_emit.c: In function 'brw_vs_emit':
brw_vs_emit.c:1156: warning: array subscript is above array bounds
...
c->regs is declared [TGSI_FILE_COUNT][128] , where TGSI_FILE_COUNT = 11
but this line tries to reference c->regs[TGSI_FILE_OUTPUT][VERT_RESULT_PSIZ] ,
   where TGSI_FILE_OUTPUT = 3  and  VERT_RESULT_PSIZ is #defined as 10000 !

 -- Jeff


      

Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification

[Luca B. <luc...@gm...>]

Perhaps try running make clean and make if you haven't already?
And perhaps make sure that the installed libGL.so and DRI drivers are
build from the same codebase.

The changes in my branch definitely shouldn't affect this.

> I wanted to merge Lucsa' branch in to my copy of Mesa master to test it
> out,but it would let me for some reason,any advice on that?
What reason?
git merge should work.

[Mesa3d-dev] Compiler warnings when building Mesa

[Johannes O. <joh...@gm...>]

Hi,

here is a list with compiler warnings I have seen for a longer time.

Just for info:
libdrm: 20100313
XServer: 1.7.5
protos/macros: 20100311 

I can also provide a full log (~1.4 MiB).

Please decide whether fixing them is necessary/worth ...

Thanks.
Johannes

Re: [Mesa3d-dev] i965 shader regression [bisected]

[Maxim L. <max...@gm...>]

On Sat, 2010-03-13 at 16:52 +0200, Maxim Levitsky wrote:
> This time I caught it early.
> 
> 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a is first bad commit
> commit 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a
> Author: Eric Anholt <er...@an...>
> Date:   Wed Mar 10 17:38:33 2010 -0800
> 
>     i965: Do FS SLT, SGT, and friends using CMP, SEL instead of CMP, MOV, MOV.
> 
> :040000 040000 d6abcec74652e20faf81feac8486cfb8ef979494 d5b5c11b472e463525965d9673c0170b0eb206f1 M	src
> 
> 
> (Revert helps restore correct behaviour)
> 
> This breaks several shaders in my examples folder, that I downloaded from GLSL tutorial site.
> (http://www.lighthouse3d.com/opengl/glsl/)
> 
> 
> 
> Attached two example shaders.
> 
> Best regards,
> 	Maxim Levitsky
> 
> 

Ping

[Mesa3d-dev] [Bug 27065] build failure: No rule to make target `../../../../src/gallium/drivers/softpipe/sp_winsys.h', needed by `x11/native_ximage.o'.

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27065





--- Comment #2 from David Ronis <Dav...@Mc...>  2010-03-14 09:50:58 PST ---
Actually, I had run make clean and that didn't help; however, explicitly
removing the depend file as you suggested seems to have worked.

Thanks


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification

[STEVE555 <ste...@ho...>]

Hi guys,
           I came across this post and downloaded luca's version of Mesa
(mesa-lb) using:
git clone git://repo.or.cz/mesa/mesa-lb.git and then git checkout --track -b
unification+fixes+stable origin/unification+fixes+stable and switched to
that branch. I then for safety,I compiled and installed with:
./configure --prefix=/usr/local --enable-32-bit --enable-xcb
--enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
--enable-motif --enable-gl-osmesa --disable-gallium-intel
--disable-gallium-radeon --with-expat=/usr/lib
--with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast
--enable-gallium-swrast --enable-gallium-svga --with-max-width=4096
--with-max-height=4096 --enable-debug

http://old.nabble.com/file/p27895301/glxinfo-error.txt glxinfo-error.txt
There were no compilation problems when I compiled Luca's version of Mesa.I
re-booted into my root account.I fired up Konsole and ran glxinfo for the
packaged version of Mesa for Fedora Rawhide,and that showed up fine.To see
Luca'a version,I used :
export LIBGL_DRIVERS_PATH=/usr/local/lib/dri and then glxinfo.I found a
strange error near the top:

Mesa: CPU name: AMD Athlon(tm) XP 3000+
Mesa warning: failed to remap index 390
Mesa warning: failed to remap index 391
Mesa warning: failed to remap index 392
Mesa warning: failed to remap index 398
Mesa warning: failed to remap index 399

I've attached a txt file with the full output.My graphics card is an Nvidia
NV40 (6,600 GT),and I also compile DRM the nouveau kernel modules and the
nouveau driver from git
I wanted to merge Lucsa' branch in to my copy of Mesa master to test it
out,but it would let me for some reason,any advice on that?
Regards,
             STEVE555


Keith Whitwell-4 wrote:
> 
> Sounds good to me - fewer driver directories to fix up after changes...
> 
> Keith
> 
> On Sat, Mar 13, 2010 at 5:29 PM, Luca Barbieri <lu...@lu...>
> wrote:
>> Currently the nv30 and nv40 Gallium drivers are very similar, and
>> contain about 5000 lines of essentially duplicate code.
>>
>> I prepared a patchset (which can be found at
>> http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes)
>> which gradually unifies the drivers, one file per the commit.
>>
>> A new "nvfx" directory is created, and unified files are put there one by
>> one.
>> After all patches are applied, the nv30 and nv40 directories are
>> removed and the only the new nvfx directory remains.
>>
>> The first patches unify the engine naming (s/curie/eng3d/g;
>> s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants.
>> Initial versions of this work changed renouveau.xml to create a new
>> "NVFXTCL" object, but the current version doesn't need any
>> renouveau.xml modification at all.
>>
>> The "unification+fixes" branch referenced above is the one that should
>> be tested.
>> The "unification" branch contains just the unification, with no
>> behavior changes, while "unification+fixes" also fixes swtnl and quad
>> rendering, allowing to better test the unification. Some cleanups on
>> top of the unfication are also included.
>>
>> That same repository also contains other branches with significant
>> improvements on top of the unification, but I'm still not proposing
>> them for inclusion as they need more testing and some fixes.
>>
>> While there are some branches in the Mesa repository that would
>> conflict with this, such branches seem to be popping up continuously
>> (and this is good!), so waiting until they are merged probably won't
>> really work.
>>
>> The conflicts are minimal anyway and the driver fixes can be very
>> easily reconstructed over the unified codebase.
>>
>> How about merging this?
>> Any objections? Any comments?
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Mesa3d-dev mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/-PATCH--nv30-nv40-Gallium-drivers-unification-tp27889377p27895301.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.

[Keith W. <kei...@go...>]

On Sun, Mar 14, 2010 at 10:28 AM, Chia-I Wu <ol...@gm...> wrote:
> On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell
> <kei...@go...> wrote:
>> This looks like it introduces an extra full-window copying operation
>> at every swapbuffers...  is that correct?
>> If so, I think we should try to figure out an alternative approach
>> without the copying...  would actually flipping between two textures
>> (thus preserving the old back/new front) contents be workable?
> Buffers swapping is handled in xmesa_swap_st_framebuffer.  It is a zero-copy
> operation.
>
> This commit is to fix a bug when this code path is hit
>
>  /* draw something and ... */
>  glXSwapBuffers();
>  glReadBuffer(GL_FRONT);
>  glReadPixels();
>
> In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be
> added on demand as can be seen in st_ReadBuffer.  The validation list would
> become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }.  When
> glReadPixels is called, st/mesa will validate with the list and read from the
> front buffer.
>
> On the st/glx side, this use pattern is catched.  When the front buffer is
> allocated, the contents of the back buffer will be copied to the front buffer.
> This happens only once.  When the same code is run again, glXSwapBuffers will
> swap the buffers.
>
> The copying is required because xmesa_swap_st_framebuffer does not always swap
> the buffers.  It is so that only the back buffer is allocated when the
> application never draws/reads the front buffer.
>
> --
> ol...@Lu...
>

OK, sorry for being slow & thanks for explaining...

Keith

Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.

[Chia-I Wu <ol...@gm...>]

On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell
<kei...@go...> wrote:
> This looks like it introduces an extra full-window copying operation
> at every swapbuffers...  is that correct?
> If so, I think we should try to figure out an alternative approach
> without the copying...  would actually flipping between two textures
> (thus preserving the old back/new front) contents be workable?
Buffers swapping is handled in xmesa_swap_st_framebuffer.  It is a zero-copy
operation.

This commit is to fix a bug when this code path is hit

  /* draw something and ... */
  glXSwapBuffers();
  glReadBuffer(GL_FRONT);
  glReadPixels();

In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be
added on demand as can be seen in st_ReadBuffer.  The validation list would
become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }.  When
glReadPixels is called, st/mesa will validate with the list and read from the
front buffer.

On the st/glx side, this use pattern is catched.  When the front buffer is
allocated, the contents of the back buffer will be copied to the front buffer.
This happens only once.  When the same code is run again, glXSwapBuffers will
swap the buffers.

The copying is required because xmesa_swap_st_framebuffer does not always swap
the buffers.  It is so that only the back buffer is allocated when the
application never draws/reads the front buffer.

-- 
ol...@Lu...

[Mesa3d-dev] plumbing for gallium swrast_dri.so

[George S. <gsa...@gm...>]

Hi,

I put some patches at
http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do
the plumbing in order to build the swrast_dri wrapper around gallium
instead of classic mesa. For reference, swrast_dri is the fallback
driver loaded by libGL (with LIBGL_ALWAYS_SOFTWARE) and xserver. It
must not link with libdrm, nor use any drm headers during building
because it is also used on platforms without drm.

The branch is to the point where glxinfo runs and needs some glue with
__DRIswrastLoaderExtension in order to show something other than black
windows. The problem is that there seems to be two places where to put
the glue, either in st/.../dri_drawable.c or in
ws/.../swrast_drm_api.c . Can someone more familiar with gallium take
a look at the branch and provide hints ?

thanks,
George.

Re: [Mesa3d-dev] Mesa (gallium-st-api): st/glx: Sync the back buffer to the front buffer.

[Keith W. <kei...@go...>]

Chia-I,

This looks like it introduces an extra full-window copying operation
at every swapbuffers...  is that correct?

If so, I think we should try to figure out an alternative approach
without the copying...  would actually flipping between two textures
(thus preserving the old back/new front) contents be workable?

Keith

On Sun, Mar 14, 2010 at 5:17 AM, Chia-I Wu <ol...@ke...> wrote:
> Module: Mesa
> Branch: gallium-st-api
> Commit: d6262bdcfb64e1f88f6a890829f5c30c26bc372b
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=d6262bdcfb64e1f88f6a890829f5c30c26bc372b
>
> Author: Chia-I Wu <ol...@lu...>
> Date:   Sun Mar 14 12:01:27 2010 +0800
>
> st/glx: Sync the back buffer to the front buffer.
>
> Consider this rendering sequence
>
>  * render to the back buffer
>  * swap buffers
>  * read from the front buffer
>
> The front buffer is expected to have the contents of the back buffer.
>
> ---
>
>  src/gallium/state_trackers/glx/xlib/xm_st.c |   26 ++++++++++++++++++++++----
>  1 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/glx/xlib/xm_st.c b/src/gallium/state_trackers/glx/xlib/xm_st.c
> index de5a35e..bcb8285 100644
> --- a/src/gallium/state_trackers/glx/xlib/xm_st.c
> +++ b/src/gallium/state_trackers/glx/xlib/xm_st.c
> @@ -197,18 +197,36 @@ xmesa_st_framebuffer_validate(struct st_framebuffer_iface *stfbi,
>                               struct pipe_texture **out)
>  {
>    struct xmesa_st_framebuffer *xstfb = xmesa_st_framebuffer(stfbi);
> -   unsigned statt_mask, i;
> +   unsigned statt_mask, new_mask, i;
> +   boolean resized;
>
>    statt_mask = 0x0;
>    for (i = 0; i < count; i++)
>       statt_mask |= 1 << statts[i];
> +   /* record newly allocated textures */
> +   new_mask = statt_mask & ~xstfb->texture_mask;
> +
> +   resized = (xstfb->buffer->width != xstfb->texture_width ||
> +              xstfb->buffer->height != xstfb->texture_height);
>
>    /* revalidate textures */
> -   if (xstfb->buffer->width != xstfb->texture_width ||
> -       xstfb->buffer->height != xstfb->texture_height ||
> -       (xstfb->texture_mask & statt_mask) != statt_mask) {
> +   if (resized || new_mask) {
>       xmesa_st_framebuffer_validate_textures(stfbi,
>             xstfb->buffer->width, xstfb->buffer->height, statt_mask);
> +
> +      if (!resized) {
> +         enum st_attachment_type back, front;
> +
> +         back = ST_ATTACHMENT_BACK_LEFT;
> +         front = ST_ATTACHMENT_FRONT_LEFT;
> +         /* copy the contents if front is newly allocated and back is not */
> +         if ((statt_mask & (1 << back)) &&
> +             (new_mask & (1 << front)) &&
> +             !(new_mask & (1 << back))) {
> +            xmesa_st_framebuffer_copy_textures(stfbi, back, front,
> +                  0, 0, xstfb->texture_width, xstfb->texture_height);
> +         }
> +      }
>    }
>
>    for (i = 0; i < count; i++) {
>
> _______________________________________________
> mesa-commit mailing list
> mes...@li...
> http://lists.freedesktop.org/mailman/listinfo/mesa-commit
>