headers
Jose Fonseca | 1 Feb 2011 01:15
Favicon

Re: Flex and bison generated files in revision control

Sounds good.

I've been planning to setup bison/flex on our build daemons for some time now, but other important stuff
keeps popping up, but once this is done I wont be able to delay it further :)

It can be it earlier as far as I'm concerned -- I think 7th Feb should give enough time.

Jose
________________________________________
From: mesa-dev-bounces+jfonseca=vmware.com <at> lists.freedesktop.org
[mesa-dev-bounces+jfonseca=vmware.com <at> lists.freedesktop.org] On Behalf Of Ian Romanick [idr <at> freedesktop.org]
Sent: Monday, January 31, 2011 23:46
To: mesa-dev <at> lists.freedesktop.org
Subject: [Mesa-dev] Flex and bison generated files in revision control

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

Tracking files generated by flex and bison puts an undue burden on
people doing work on the various parers and lexers in Mesa.

Tracking files generated by flex and bison generates extraneous noise in
commit logs.

Tracking files generated by flex and bison makes cherry-picking fixes
from the development branch back to stable branches more difficult than
it needs to be.

Tracking files generated by flex and bison is a just plain bad idea.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Feb 2011 01:50

[Bug 33758] CreateDRIDrawable can't fail gracefully

https://bugs.freedesktop.org/show_bug.cgi?id=33758

--- Comment #2 from nobled <nobled <at> dreamwidth.org> 2011-01-31 16:50:38 PST ---
Okay, with debug symbols now the backtrace is:

#0  0x00434e18 in XCreateDrawable (base=0x811caa0, xDrawable=102760449, 
    drawable=102760449, modes=0x8170ff0) at drisw_glx.c:94
#1  driCreateDrawable (base=0x811caa0, xDrawable=102760449, 
    drawable=102760449, modes=0x8170ff0) at drisw_glx.c:377
#2  0x004356a7 in driFetchDrawable (gc=0x8167468, glxDrawable=102760449)
    at dri_common.c:373
#3  0x004346f2 in drisw_bind_context (context=0x8167468, old=0x44a1c0, 
    draw=102760449, read=102760449) at drisw_glx.c:266
#4  0x00412c3f in MakeContextCurrent (dpy=0x81400c0, draw=102760449, 
    read=102760449, gc_user=0x8167468) at glxcurrent.c:263
#5  0x00412dd3 in glXMakeCurrent (dpy=0x81400c0, draw=102760449, gc=0x8167468)
    at glxcurrent.c:287
#6  0x00462e8c in GLX_eglMakeCurrent (drv=0x80ec2e0, disp=0x80eb680, 
    dsurf=0x8164370, rsurf=0x8164370, ctx=0x816ed10) at egl_glx.c:760
#7  0x00454f8f in eglMakeCurrent (dpy=0x80eb680, draw=0x8164370, 
    read=0x8164370, ctx=0x816ed10) at eglapi.c:478

XGetVisualInfo() returned null, and that doesn't get checked for.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Feb 2011 09:42

[Bug 33797] New: memcpy segfault in st_cb_texture.c:171

https://bugs.freedesktop.org/show_bug.cgi?id=33797

           Summary: memcpy segfault in st_cb_texture.c:171
           Product: Mesa
           Version: git
          Platform: x86 (IA32)
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mesa-dev <at> lists.freedesktop.org
        ReportedBy: nobled <at> dreamwidth.org

Mesa git: 2f7c876ff5af86c78c0f3debfbdc2a56c7b4d1fe

This happens when using EGL_DRIVER=egl_gallium with pipe_swrast and creating a
texture from a bitmap file that's mmap()'d read-only, like this:

buffer->data = mmap(NULL, buffer->size, PROT_READ, MAP_SHARED, fd, 0);

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x037529f4 in __memcpy (to=0xb61ca044, from=0xb6c8e400, n=4096)
    at state_tracker/st_cb_texture.c:171
171       __asm__ __volatile__("rep ; movsl\n\t"
(gdb) bt
#0  0x037529f4 in __memcpy (to=0xb61ca044, from=0xb6c8e400, n=4096)
    at state_tracker/st_cb_texture.c:171
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Morgan | 1 Feb 2011 04:16
Picon

git compile error

Hello.

I'm seeing some errors compiling the git version:

make
make[1]: Entering directory `/home/cmorgan/wayland/mesa/src'
Making sources for autoconf
make[2]: Entering directory `/home/cmorgan/wayland/mesa/src/mapi/shared-glapi'
make[3]: Entering directory `/home/cmorgan/wayland/mesa/src/mapi/glapi/gen-es'
make[3]: Nothing to be done for `shared-glapi'.
make[3]: Leaving directory `/home/cmorgan/wayland/mesa/src/mapi/glapi/gen-es'
gcc -c -I../../../include -I../../../src/mapi -DMAPI_MODE_GLAPI
-DMAPI_ABI_HEADER=\"shared-glapi/glapi_mapi_tmp.h\" -g -O2 -Wall
-Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
../../../src/mapi/mapi/entry.c -o entry.o
../../../src/mapi/mapi/entry.c: In function ‘entry_get_public’:
../../../src/mapi/mapi/entry.c:82: error: ‘public_entries’ undeclared
(first use in this function)
../../../src/mapi/mapi/entry.c:82: error: (Each undeclared identifier
is reported only once
../../../src/mapi/mapi/entry.c:82: error: for each function it appears in.)
make[2]: *** [entry.o] Error 1
make[2]: Leaving directory `/home/cmorgan/wayland/mesa/src/mapi/shared-glapi'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/cmorgan/wayland/mesa/src'
make: *** [default] Error 1
cmorgan <at> laptop:~/wayland/mesa$
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arthur Zhu | 1 Feb 2011 14:41
Picon

[PATCH] Adding -enable-egl-dri2 option. Happy Chinese Spring Festival!

From: Arthur Zhu <arthur.zhuyong <at> gmail.com>

---
 configure.ac |   29 +++++++++++++++--------------
 1 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index 46938f4..8a429a7 100644
--- a/configure.ac
+++ b/configure.ac
 <at>  <at>  -1100,23 +1100,24  <at>  <at>  if test "x$enable_egl" = xyes; then
         if test "$mesa_driver" = xlib -o "$mesa_driver" = dri; then
             EGL_DRIVERS_DIRS="glx"
         fi
+    fi
+fi

+AC_ARG_ENABLE([egl-dri2],
+    [AS_HELP_STRING([--enable-egl-dri2],
+        [enable egl-dri2 driver.  <at> <: <at> default=disabled <at> :> <at> ])],
+    [enable_egl_dri2="$enableval"],
+    [enable_egl_dri2=no])
+if test "x$enable_egl_dri2" = xyes; then
+    if test "$enable_static" != yes; then
         if test "$mesa_driver" = dri; then
             # build egl_dri2 when xcb-dri2 is available
-            PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes],
-            		  [have_xcb_dri2=yes],[have_xcb_dri2=no])
-            PKG_CHECK_MODULES([LIBUDEV], [libudev > 150],
-            		  [have_libudev=yes],[have_libudev=no])
(Continue reading)

Permalink | Reply | 8 comments |
headers
bugzilla-daemon | 1 Feb 2011 15:25

[Bug 31940] [r300g] Crash in dri2_invalidate_drawable

https://bugs.freedesktop.org/show_bug.cgi?id=31940

Kai <debian <at> carbon-project.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |debian <at> carbon-project.org

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Feb 2011 15:32

[Bug 33809] New: [glsl] Unigine Sanctuary: freeze while loading

https://bugs.freedesktop.org/show_bug.cgi?id=33809

           Summary: [glsl] Unigine Sanctuary: freeze while loading
           Product: Mesa
           Version: git
          Platform: Other
               URL: http://unigine.com/download/#sanctuary
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mesa-dev <at> lists.freedesktop.org
        ReportedBy: pavel.ondracka <at> email.cz

Sanctuary used to work quite fine with r300g driver, now it freezes with with
black screen (100% CPU and slowly increasing memory consumption) while loading.

14880a510a1a288df0778395097d5a52806abfb0 is the first bad commit
commit 14880a510a1a288df0778395097d5a52806abfb0
Author: Ian Romanick <ian.d.romanick <at> intel.com>
Date:   Mon Jan 31 15:02:24 2011 -0800

    glsl: Reject shader versions not supported by the implementation

    Previously we'd happily compile GLSL 1.30 shaders on any driver.  We'd
    also happily compile GLSL 1.10 and 1.20 shaders in an ES2 context.
    This has been a long standing FINISHME in the compiler.

    NOTE: This is a candidate for the 7.9 and 7.10 branches
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugzilla-daemon | 1 Feb 2011 15:51

[Bug 33809] [glsl] Unigine Sanctuary: freeze while loading

https://bugs.freedesktop.org/show_bug.cgi?id=33809

--- Comment #1 from Fabio Pedretti <fabio.ped <at> libero.it> 2011-02-01 06:51:59 PST ---
Same problem with sauerbraten (BTW this game seems to use many OpenGL features
and it's a useful test to find regressions).

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Keith Whitwell | 1 Feb 2011 18:55
Favicon

Re: Gallium proposal: add a user pointer in pipe_resource

On Mon, 2011-01-31 at 10:46 -0800, Marek Olšák wrote:
> Hi Keith,
> 
> From my point of view, user buffers are just pointers passed through
> the Gallium interface and are well-defined from what I can see. They
> might be owned by the application (e.g. set via glVertexPointer etc.),
> therefore using the transfer functions on user buffers is invalid per
> se. Moreover, the application may change the content of user buffers
> any time,

Up until now we've always worked as if user buffers were not mutable
either by the application or the driver.  This means that userbuffers
behave very much like normal buffers which have some initial data but no
transfer mechanism.  

One upshot of this is that the driver can safely promote userbuffers to
true buffers in a one-off operation. A second upshot is that userbuffers
which may change will need to be deleted & recreated by the
state-tracker.

This is more expressive than a situation where the driver has to always
assume that userbuffers may have changed between arbitrary draw calls --
if the buffer is being reused, the driver knows it has not changed.

>  meaning that drivers should convert the user buffers to real buffers
> in the draw_vbo function, then draw vertices, and then forget the real
> buffers, keeping the user buffers bound for the next draw operation.
> Drivers should not upload user buffers anywhere else, because the
> application may change the contents between glDraw* calls. If they are
> bound as vertex buffers, we don't need to know their size and
(Continue reading)

Permalink | Reply | 7 comments |
headers
bugzilla-daemon | 1 Feb 2011 19:11

[Bug 31940] [r300g] Crash in dri2_invalidate_drawable

https://bugs.freedesktop.org/show_bug.cgi?id=31940

--- Comment #16 from Kai <debian <at> carbon-project.org> 2011-02-01 10:11:06 PST ---
I can confirm, that the patch presented in comment #7 (attachment 40689) fixes
the problem with Mesa 7.10. Please consider applying the patch and making it a
candidate for the Mesa 7.10 branch.

My "test case": http://bugs.winehq.org/show_bug.cgi?id=25712

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |

Gmane