Re: [Mesa-dev] [RFC mesa-demos] Add --with-system-data-files configure option

[Paulo Zanoni]

2011/1/29 Henri Verbeet :
> If you pass -M to format-patch, it becomes a lot smaller.
>

Thanks for the tip. For some reason I had to use -M -C --find-copies-harder.
Attached is the same patch, but with these options.


-- 
Paulo Zanoni
From df235322ecbe969ce70dcf516111686ff1d59ee0 Mon Sep 17 00:00:00 2001
From: Paulo Zanoni 
Date: Fri, 28 Jan 2011 17:34:24 -0200
Subject: [PATCH] Add --with-system-data-files option

If you specify --with-system-data-files, binaries will try to find .dat and
image files inside ${datadir}/${PACKAGE}. If you don't specify, they will try to
find the files inside "../data" (keeping backwards compatibility).

Signed-off-by: Paulo Zanoni 
---
 .gitignore  |5 +++
 CMakeLists.txt  |2 +
 Makefile.am |3 +-
 configure.ac|   18 -
 index.html  |2 +-
 m4/ac_define_dir.m4 |   49 +++
 src/CMakeLists.txt  |2 +-
 src/Makefile.am |2 +-
 src/{images => data}/CMakeLists.txt |2 +-
 src/{images => data}/Makefile.am|9 +-
 src/{images => data}/arch.rgb   |  Bin 793398 -> 793398 bytes
 src/{images => data}/bw.rgb |  Bin 206452 -> 206452 bytes
 src/{demos => data}/geartrain.dat   |0
 src/{images => data}/girl.rgb   |  Bin 117075 -> 117075 bytes
 src/{images => data}/girl2.rgb  |  Bin 117139 -> 117139 bytes
 src/{demos => data}/isosurf.dat |0
 src/{images => data}/reflect.rgb|  Bin 39632 -> 39632 bytes
 src/{images => data}/s128.rgb   |  Bin 54258 -> 54258 bytes
 src/{demos => data}/terrain.dat |0
 src/{images => data}/tile.rgb   |  Bin 206534 -> 206534 bytes
 src/{images => data}/tree2.rgba |  Bin 66048 -> 66048 bytes
 src/{images => data}/tree3.rgb  |  Bin 24816 -> 24816 bytes
 src/{images => data}/wrs_logo.rgb   |  Bin 37574 -> 37574 bytes
 src/demos/CMakeLists.txt|4 ---
 src/demos/Makefile.am   |5 +---
 src/demos/copypix.c |2 +-
 src/demos/dissolve.c|4 +-
 src/demos/drawpix.c |2 +-
 src/demos/engine.c  |2 +-
 src/demos/fbo_firecube.c|7 +++--
 src/demos/fire.c|7 +++--
 src/demos/geartrain.c   |2 +-
 src/demos/gloss.c   |4 +-
 src/demos/ipers.c   |2 +-
 src/demos/isosurf.c |4 +-
 src/demos/lodbias.c |2 +-
 src/demos/multiarb.c|4 +-
 src/demos/projtex.c |8 +++---
 src/demos/rain.cxx  |3 +-
 src/demos/readpix.c |2 +-
 src/demos/reflect.c |2 +-
 src/demos/teapot.c  |4 +-
 src/demos/terrain.c |2 +-
 src/demos/texcyl.c  |2 +-
 src/demos/textures.c|8 +++---
 src/demos/tunnel.c  |4 +-
 src/demos/tunnel2.c |4 +-
 src/demos/winpos.c  |2 +-
 src/fp/fp-tri.c |2 +-
 src/fp/tri-tex.c|2 +-
 src/fpglsl/fp-tri.c |2 +-
 src/glsl/bump.c |2 +-
 src/glsl/convolutions.c |2 +-
 src/glsl/multitex.c |4 +-
 src/glsl/texdemo1.c |2 +-
 src/perf/glslstateschange.c |8 +++---
 src/samples/sphere.c|2 +-
 src/tests/afsmultiarb.c |4 +-
 src/tests/arbfptexture.c|2 +-
 src/tests/arbfptrig.c   |2 +-
 src/tests/arbnpot.c |2 +-
 src/tests/arraytexture.c|   16 +-
 src/tests/blendxor.c|2 +-
 src/tests/bug_3195.c|2 +-
 src/tests/bumpmap.c |2 +-
 src/tests/ext422square.c|2 +-
 src/tests/fillrate.c|4 +-
 src/tests/floattex.c|2 +-
 src/tests/fptexture.c   |2 +-
 src/tests/invert.c  |2 +-
 src/tests/mipmap_limits.c   |2 +-
 src/tests/mipmap_view.c |2 +-
 src/tests/multipal.c|4 +-
 src/tests/pbo.c |2 +-
 src/tests/rubberband.c  |2 +-
 src/tests/texcmp.c  |2 +-
 src/tests/texcompress2.c|2 +-
 src/tests/texline.c |2 +-
 src/tests/texrect.c |4 +-
 src/tests/vparray.c |2 +-
 src/tests/yuvrect.c |2 +-
 src/tests/yuvsquare.c   |2 +-
 src/xdemos/yuvrect_client.c |2 +-
 83 files changed, 180 insertions(+), 106 deletions(-)
 create mode 100644 m4/ac_define_dir.m4
 rename src/{images => data}/CMakeLists.txt (55%)
 rename src/{imag

[Mesa-dev] [Bug 33758] New: CreateDRIDrawable can't fail gracefully

[bugzilla-daemon]

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

   Summary: CreateDRIDrawable can't fail gracefully
   Product: Mesa
   Version: git
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: nob...@dreamwidth.org


(I'm running on Ubuntu 10.04 x86-32 with mesa from the 7.10 Natty package, just
for the record - but this bug is also in git and older versions.)

In src/glx/glx_pbuffer.c, CreateDRIDrawable can fail, in which case it prints
"failed to create drawable", but the caller has no way of knowing that it
failed at all and just keeps going.

Whenever I called eglCreatePbuffer, "failed to create drawable" gets printed
(not sure why - because Ubuntu 10.04 has a slightly older X server?), but I got
a seemingly valid EGLSurface anyway. And when I tried to use it in
eglMakeCurrent(), I get a mysterious segfault:

Breakpoint 4, GLX_eglMakeCurrent (drv=0x80ec2e0, disp=0x80eb680, 
dsurf=0x8164370, rsurf=0x8164370, ctx=0x816ed10) at egl_glx.c:738
(gdb) next
(...)
760  ret = GLX_drv->glXMakeCurrent(GLX_dpy->dpy, ddraw, cctx);
(gdb) next

Program received signal SIGSEGV, Segmentation fault.
0x00434e18 in ?? () from /usr/lib/mesa/libGL.so.1
(gdb) bt
#0  0x00434e18 in ?? () from /usr/lib/mesa/libGL.so.1
#1  0x004356a7 in ?? () from /usr/lib/mesa/libGL.so.1
#2  0x004346f2 in ?? () from /usr/lib/mesa/libGL.so.1
#3  0x00412c3f in glXMakeCurrentReadSGI () from /usr/lib/mesa/libGL.so.1
#4  0x00412dd3 in glXMakeCurrent () from /usr/lib/mesa/libGL.so.1
#5  0x00462e8c in GLX_eglMakeCurrent (drv=0x80ec2e0, disp=0x80eb680, 
dsurf=0x8164370, rsurf=0x8164370, ctx=0x816ed10) at egl_glx.c:760
#6  0x00454f8f in eglMakeCurrent (dpy=0x80eb680, draw=0x8164370, 
read=0x8164370, ctx=0x816ed10) at eglapi.c:478

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

[Keith Whitwell]

On Sat, 2011-01-29 at 15:12 -0800, Marek Olšák wrote:
> 
> 
> Hi,
> 
> I am proposing to add a pointer to a user buffer in pipe_resource.
> There are two reasons for this:
> 
> 1) I would like to have a way to query outside of a driver whether a
> buffer is a user buffer. Simply comparing the pointer with NULL would
> do the trick.
> 
> 2) I would like to efficiently obtain a pointer to a user buffer
> outside of a driver without going through the sequence of functions
> get_transfer, transfer_map, transfer_unmap, and transfer_destroy.
> 
> This will allow to move more driver-specific code to auxiliary/util.
> 
> 


Marek,

I have to say my preference would have been to see user buffers fade
away in favour of things like inline transfers.  That said you're much
more active than I am in looking at this right now, so I don't want to
get in the way of your progress.

I guess my biggest problem with user buffers is how poorly defined their
semantics are.  For instance, what does it really mean to get write
transfer into a userbuffer?   Will you be updating the original
application-owned memory?

And user-buffers tend not to stay user-buffers - they can be promoted to
regular buffers behind the scenes by the driver.  Would that be
reflected in this interface somehow?

From the point of view of recording, replaying, debugging, remoting,
etc. at the gallium boundary, it's preferable if all actions are
interposable - ie. all actions are mediated by a function call of some
sort into the gallium interface.  Giving a component a direct memory
access into buffer contents would tend to defeat that and make
record/replay of that action difficult.

Is it possible to get a description of what you're doing at a slightly
higher level to try and understand if there's a solution without these
drawbacks?

Keith 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 33758] CreateDRIDrawable can't fail gracefully

[bugzilla-daemon]

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

--- Comment #1 from nobled  2011-01-31 06:26:26 PST ---
It looks like the same problem is also in glxcmds.c:glXCreateGLXPixmap (it
returns the same xid whether or not driScreen->createDrawable() returned null)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa trunk not compiling?

[Alberich de megres]

yes, i'm pretty sure i did that on the correct path and on top.

This problem was solved by one of the updates did by git pull, so now
i can compile mesa with no errors.

thanks!

On Sat, Jan 29, 2011 at 9:14 PM, Chia-I Wu  wrote:
> On Fri, Jan 28, 2011 at 2:08 AM, Alberich de megres
>  wrote:
>> I did configure again, with the same error.
>>
>> I'm using this configure line:
>>
>> ./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2    \
>>      --enable-gallium-nouveau --with-state-trackers=glx,dri,egl         \
>>      --with-egl-platforms=drm --enable-gles-overlay                     \
>>      --enable-gallium-r600 --with-dri-drivers=i915,i965                 \
>>      --disable-gallium-{i915,i965}
> At the end of the screen output, did you see "nvc0" on the "Driver
> dirs:" line?  Did you execute "make" at the top directory of Mesa?
>>
>>
>> On Thu, Jan 27, 2011 at 6:49 PM, Lucas Stach  wrote:
>>> Just do ./configure again. After that it should compile just fine.
>>>
>>> -- Lucas
>>>
>>> Am Donnerstag, den 27.01.2011, 15:13 +0100 schrieb Alberich de megres:
 Hi,

 I'm trying to compile mesa trunk.
 But i get this error:

 gcc -c -o pipe_nouveau.o pipe_nouveau.c -I../../../../include
 -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
 -I../../../../src/gallium/include -I../../../../src/gallium/winsys
 -I/usr/include/libdrm    -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
 -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
 -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -g -O2 -Wall -Wmissing-prototypes
 -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC
 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
 -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
 -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV
 gmake[3]: *** No rule for target
 `../../../../src/gallium/drivers/nvc0/libnvc0.a', need for
 `../../../../lib/egl/pipe_nouveau.so'. Stop..
 gmake[3]: exiting from directory
 `/root/Mesa/Mesa-git/mesa/src/gallium/targets/egl'
 gmake[2]: *** [default] Error 1
 gmake[2]:exiting from directory 
 `/root/Mesa/Mesa-git/mesa/src/gallium/targets'
 make[1]: *** [subdirs] Error 1
 make[1]: exiting from directory `/root/Mesa/Mesa-git/mesa/src'
 make: *** [default] Error 1

 Alberich
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

>>>
>>>
>>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
> --
> o...@lunarg.com
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] more EXT_framebuffer_sRGB, 965 support

[Brian Paul]

On 01/27/2011 09:34 PM, Dave Airlie wrote:

Okay looking for some review/comments, esp on the addition to the
ctx->Const structure to denote if sRGB on FBOs is possible.

Since just enabling the extension doesn't mean anything, we should
probably enable it on anything that enables EXT_texture_sRGB.


I'm not sure.  What's the value in enabling an extension that doesn't 
do something useful?


The extension spec says "Implementations are encouraged to allow sRGB 
update and blending when rendering to sRGB textures using 
ARB_framebuffer_object but this is not required."


I guess I'd rather implement what's suggested than just enabling a 
no-op extension.


The patch looks fine.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] glx: fix length of GLXGetFBConfigsSGIX

[Brian Paul]

These patches look good to me.  I'll commit soon.  Thanks!

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

[Brian Paul]

These look good, Henri.  I'll commit them soon.

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

[Julien Cristau]

On Sun, Jan 30, 2011 at 00:00:48 +0100, Henri Verbeet wrote:

> @@ -918,12 +921,15 @@ dri2CreateScreen(int screen, struct glx_display * priv)
> return &psc->base;
>  
>  handle_error:
> +   if (psc->fd)
> +  close(psc->fd);

0 is a valid fd.  It might be better to initialize fd to -1 and check
for >= 0 here.

> +   if (psc->driver)
> +  dlclose(psc->driver);
> Xfree(driverName);
> Xfree(deviceName);
> +   glx_screen_cleanup(&psc->base);
> XFree(psc);
>  
> -   /* FIXME: clean up here */
> -
> return NULL;
>  }
>  
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

[Henri Verbeet]

On 31 January 2011 17:43, Julien Cristau  wrote:
> On Sun, Jan 30, 2011 at 00:00:48 +0100, Henri Verbeet wrote:
>
>> @@ -918,12 +921,15 @@ dri2CreateScreen(int screen, struct glx_display * priv)
>>     return &psc->base;
>>
>>  handle_error:
>> +   if (psc->fd)
>> +      close(psc->fd);
>
> 0 is a valid fd.  It might be better to initialize fd to -1 and check
> for >= 0 here.
>
Yes, but isn't 0 defined to be stdin on any platform we care about?
Though another reason to initialize to -1 would be that I just noticed
we'd technically be passing an invalid fd to close() if the open
failed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

[Henri Verbeet]

The attached patch should do.
From ab34026885f98914efa6ad671f3446621124a55a Mon Sep 17 00:00:00 2001
From: Henri Verbeet 
Date: Mon, 31 Jan 2011 18:09:19 +0100
Subject: [PATCH 1/1] glx: Properly check for a valid fd in dri2CreateScreen().

---
 src/glx/dri2_glx.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index ab7915c..a275ba5 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -804,6 +804,8 @@ dri2CreateScreen(int screen, struct glx_display * priv)
   return NULL;
 
memset(psc, 0, sizeof *psc);
+   psc->fd = -1;
+
if (!glx_screen_init(&psc->base, screen, priv)) {
   Xfree(psc);
   return NULL;
@@ -921,7 +923,7 @@ dri2CreateScreen(int screen, struct glx_display * priv)
return &psc->base;
 
 handle_error:
-   if (psc->fd)
+   if (psc->fd >= 0)
   close(psc->fd);
if (psc->driver)
   dlclose(psc->driver);
-- 
1.7.2.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

[Julien Cristau]

On Mon, Jan 31, 2011 at 18:18:22 +0100, Henri Verbeet wrote:

> The attached patch should do.

Looks good to me, thanks.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

[Brian Paul]

On Mon, Jan 31, 2011 at 10:20 AM, Julien Cristau  wrote:
> On Mon, Jan 31, 2011 at 18:18:22 +0100, Henri Verbeet wrote:
>
>> The attached patch should do.
>
> Looks good to me, thanks.

Committed.  Thanks, guys.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

[Marek Olšák]

On Mon, Jan 31, 2011 at 3:17 PM, Keith Whitwell  wrote:

> On Sat, 2011-01-29 at 15:12 -0800, Marek Olšák wrote:
> >
> >
> > Hi,
> >
> > I am proposing to add a pointer to a user buffer in pipe_resource.
> > There are two reasons for this:
> >
> > 1) I would like to have a way to query outside of a driver whether a
> > buffer is a user buffer. Simply comparing the pointer with NULL would
> > do the trick.
> >
> > 2) I would like to efficiently obtain a pointer to a user buffer
> > outside of a driver without going through the sequence of functions
> > get_transfer, transfer_map, transfer_unmap, and transfer_destroy.
> >
> > This will allow to move more driver-specific code to auxiliary/util.
> >
> >
>
>
> Marek,
>
> I have to say my preference would have been to see user buffers fade
> away in favour of things like inline transfers.  That said you're much
> more active than I am in looking at this right now, so I don't want to
> get in the way of your progress.
>
> I guess my biggest problem with user buffers is how poorly defined their
> semantics are.  For instance, what does it really mean to get write
> transfer into a userbuffer?   Will you be updating the original
> application-owned memory?
>

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, 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 sometimes we even can't (again, glVertexPointer etc.).
Instead, we can use pipe_draw_info::min_index and max_index and upload only
that range. This has proved to be a great optimization and it's how r300g
and r600g work now.

In theory, doing user buffer uploads at the state tracker side using inline
transfers might work and should remove some burden from drivers. In
practice, inline transfers may have a very large overhead compared to how
things work now. In transfer_inline_write, you usually want to map the
buffer, do a memcpy, and unmap it. The map/unmap overhead can be really
significant. There are applications that use glDrawElements to draw one
triangle at a time, and they draw hundreds of triangles with user buffers in
this way (yes, applications really do this). We can't afford doing any more
work than is absolutely necessary. When you get 1 or more draw_vbo calls
per second, everything matters.

Currently, the radeon drivers have one upload buffer for vertices and it
stays mapped until the command stream is flushed. When they get a user
buffer, they do one memcpy and that's all. They don't touch winsys unless
the upload buffer is full.



> And user-buffers tend not to stay user-buffers - they can be promoted to
> regular buffers behind the scenes by the driver.  Would that be
> reflected in this interface somehow?
>

I don't think it's needed. The pipe_resource fields can stay immutable and
drivers can internally replace vertex buffers with their private
pipe_resources. The state trackers don't need to know about it.



> From the point of view of recording, replaying, debugging, remoting,
> etc. at the gallium boundary, it's preferable if all actions are
> interposable - ie. all actions are mediated by a function call of some
> sort into the gallium interface.  Giving a component a direct memory
> access into buffer contents would tend to defeat that and make
> record/replay of that action difficult.
>

Indeed, record/replay would be difficult but not impossbie. FWIW I think the
interface shouldn't be specifically designed for record/replay. Instead,
record/replay should be made work with whatever interface there is.



> Is it possible to get a description of what you're doing at a slightly
> higher level to try and understand if there's a solution without these
> drawbacks?
>

I am quite content with the current interface for user buffers, but it will
need a few changes for it to be more... efficient. Below is my plan for
further improving Gallium and its interactions with user buffers in general.


1) New vertex buffer manager

This is how I'd like to put the burden of uploading user buffers out of the
drivers. I've made a new vertex buffer manager. It can be found here:
http://cgit.freedesktop.org/~mareko/mesa/commit/?h=vbuf-mgr&id=94a53b672dd238e6a50bb6b252614dc2e9f30ddf

And the corresponding branch is here:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=vbuf-mgr

It's a module that drivers can use and it does 2 things:
- upl

[Mesa-dev] [PATCH attempt2] mesa: Add -Werror=declaration-after-statement to core Mesa CFLAGS

[Chad Versace]

mesa: Add -Werror=declaration-after-statement to core Mesa CFLAGS

Add the flag only if the compiler is GCC.

Since MSVC does not support C99, explicit errors must be set within core
Mesa in order to prevent GCC users from breaking the MSVC build.

---
 configure.ac  |4 
 src/mesa/Makefile |2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 46938f4..26b6e8d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -157,6 +157,10 @@ if test "x$GCC" = xyes; then
 
 # Work around aliasing bugs - developers should comment this out
 CFLAGS="$CFLAGS -fno-strict-aliasing"
+
+# Since MSVC does not support C99, explicit errors must be set within core
+# Mesa in order to prevent GCC users from breaking the MSVC build.
+CORE_MESA_C_ERROR_FLAGS="-Werror=declaration-after-statement"
 fi
 if test "x$GXX" = xyes; then
 CXXFLAGS="$CXXFLAGS -Wall"
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index a6025e9..557b208 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -22,7 +22,7 @@ MESA_CPPFLAGS := $(API_DEFINES) $(DEFINES)
 MESA_CPPFLAGS += $(INCLUDE_DIRS)
 
 # tidy compiler flags
-CFLAGS := $(filter-out $(DEFINES), $(CFLAGS))
+CFLAGS := $(filter-out $(DEFINES), $(CFLAGS)) $(CORE_MESA_C_ERROR_FLAGS)
 CXXFLAGS := $(filter-out $(DEFINES), $(CXXFLAGS))
 
 # LLVM is needed for the state tracker
-- 
1.7.3.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

[Christoph Bumiller]

On 31.01.2011 19:46, Marek Olšák wrote:
>
> 1) New vertex buffer manager
>
> This is how I'd like to put the burden of uploading user buffers out
> of the drivers. I've made a new vertex buffer manager. It can be found
> here:
> http://cgit.freedesktop.org/~mareko/mesa/commit/?h=vbuf-mgr&id=94a53b672dd238e6a50bb6b252614dc2e9f30ddf
> 
>
> And the corresponding branch is here:
> http://cgit.freedesktop.org/~mareko/mesa/log/?h=vbuf-mgr
> 
>
> It's a module that drivers can use and it does 2 things:
> - uploads user buffers
> - takes care of converting unsupported vertex formats and unaligned
> vertex layouts to supported ones (there are vertex fetcher capability
> bits, see struct u_vbuf_caps)
>
> Besides some typos in a few commits, this work is already done.
>
> With this manager, the drivers don't have to deal with user buffers
> when they are bound as vertex buffers. They only get real hardware
> buffers.
>
Please do *not* take away my user buffers and put user vertex arrays at
the mercy of a state tracker !
In the DrawArrays case I usually use util/translate and interleave them
letting it write directly into my command buffer for immediate mode
vertex data submission.

Thanks.
> --
> So this all is my current plan to simplify hardware drivers a bit and
> add some nice optimizations. Another option would be to move the new
> vertex buffer manager or something equivalent to the state tracker and
> remove user buffers from the Gallium interface, but that would be
> additional work with uncertain performance implications, so I decided
> not to take this path (for now).
>
> Best regards
> Marek
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

[José Fonseca]

On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote:
> On 31.01.2011 19:46, Marek Olšák wrote:
> > With this manager, the drivers don't have to deal with user buffers when 
> > they are bound as vertex buffers. They only get real hardware buffers.
> 
> Please do *not* take away my user buffers and put user vertex arrays at the 
> mercy of a state tracker !
> In the DrawArrays case I usually use util/translate and interleave them 
> letting it write directly into my command buffer for immediate mode vertex 
> data submission.

Christoph,

Is there any reason for not wanting to the same optimization for
non-user buffers?

If the buffers are small and used only once, wouldn't you still want to
write them directly into the command buffer?

Because eliminating user buffers does not imply eliminating these
optimization opportunities -- the driver can still know how big a buffer
is, and the state tracker can set a flag such as PIPE_USAGE_ONCE to help
the pipe driver figure out this is a fire and forget buffer. Perhaps we
can have a PIPE_CAP for distinguishing the drivers that can inline small
buffers, vs those who can and prefer them batched up in big vbos.

And lets not forget the user arrays are a deprecated feature of GL.
Applications will have to create a vbo even if all they wanna do is a
draw a textured quad, therefore small vbos are worthwhile to optimize
regardless.

I'm not saying we must get rid of user buffers now, but I can't help
feeling that it is odd that while recent versions of GL/DX APIs are
eliminating index/vertex buffers in user memory, Gallium is optimizing
for them...

Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

[Marek Olšák]

On Mon, Jan 31, 2011 at 9:17 PM, José Fonseca  wrote:

> On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote:
> > On 31.01.2011 19:46, Marek Olšák wrote:
> > > With this manager, the drivers don't have to deal with user buffers
> when they are bound as vertex buffers. They only get real hardware buffers.
> >
> > Please do *not* take away my user buffers and put user vertex arrays at
> the mercy of a state tracker !
> > In the DrawArrays case I usually use util/translate and interleave them
> letting it write directly into my command buffer for immediate mode vertex
> data submission.
>
> Christoph,
>
> Is there any reason for not wanting to the same optimization for
> non-user buffers?
>
> If the buffers are small and used only once, wouldn't you still want to
> write them directly into the command buffer?
>
> Because eliminating user buffers does not imply eliminating these
> optimization opportunities -- the driver can still know how big a buffer
> is, and the state tracker can set a flag such as PIPE_USAGE_ONCE to help
> the pipe driver figure out this is a fire and forget buffer. Perhaps we
> can have a PIPE_CAP for distinguishing the drivers that can inline small
> buffers, vs those who can and prefer them batched up in big vbos.
>
> And lets not forget the user arrays are a deprecated feature of GL.
> Applications will have to create a vbo even if all they wanna do is a
> draw a textured quad, therefore small vbos are worthwhile to optimize
> regardless.
>
> I'm not saying we must get rid of user buffers now, but I can't help
> feeling that it is odd that while recent versions of GL/DX APIs are
> eliminating index/vertex buffers in user memory, Gallium is optimizing
> for them...
>

FWIW, the fact that something is deprecated in GL shouldn't concern us. Some
deprecated features are only removed in the Core profile, which is very
rarely used by developers. The GL4/Compatibility profile still contains
everything, no features have been eliminated there. And we have to implement
both the profiles, because people use both. The deprecation mechanism in
OpenGL really doesn't make our lives easier at all.

Whether user buffers should be exposed via the Gallium interface is an
entirely different question though. I see my effort as moving towards
eventually eliminating user buffers by simplifying the logic around them.
The section "1)" in my previous email is about eliminating any
user-buffer-related code from drivers (though this step is optional). The
section "2)" talks about removing some user-buffer-specific code from
st/mesa, optimizing things in the process. I can see nothing wrong with
those. ;)

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gallium proposal: add a user pointer in pipe_resource

[Christoph Bumiller]

On 31.01.2011 21:17, José Fonseca wrote:
> On Mon, 2011-01-31 at 11:48 -0800, Christoph Bumiller wrote:
>> On 31.01.2011 19:46, Marek Olšák wrote:
>>> With this manager, the drivers don't have to deal with user buffers when 
>>> they are bound as vertex buffers. They only get real hardware buffers.
>> Please do *not* take away my user buffers and put user vertex arrays at the 
>> mercy of a state tracker !
>> In the DrawArrays case I usually use util/translate and interleave them 
>> letting it write directly into my command buffer for immediate mode vertex 
>> data submission.
> Christoph,
>
> Is there any reason for not wanting to the same optimization for
> non-user buffers?
>
For non-user buffers this is not an optimization.
Immediate mode (sending vertices through the command buffer) bypasses
the vertex cache, which is perfectly fine for user buffers which I
cannot cache anyway since they might change at any time.
Also, non-user buffers are already accessible by the GPU so VFETCH can
go right ahead and do all the work.

> If the buffers are small and used only once, wouldn't you still want to
> write them directly into the command buffer?
>
As I said, they're already in GPU accessible system memory or even VRAM,
no reason to let the CPU move the data around before letting the GPU
read it.
Unless you're suggesting to do lazy transfers / "real" buffer allocations ?

> Because eliminating user buffers does not imply eliminating these
> optimization opportunities -- the driver can still know how big a buffer
> is, and the state tracker can set a flag such as PIPE_USAGE_ONCE to help
> the pipe driver figure out this is a fire and forget buffer. Perhaps we
The case where user buffers + immediate mode are a real win right now is
when the application asks you to pull e.g. vertices 0, 16, 25, and 8999
from the user memory.
You do not know it will do that at transfer time, and if you write min
index to max index to your scratch buffer, you copy around 8996 vertices
too many instead of just extracting these 4 directly from the source and
putting them into the command buffer.

> can have a PIPE_CAP for distinguishing the drivers that can inline small
> buffers, vs those who can and prefer them batched up in big vbos.
>
> And lets not forget the user arrays are a deprecated feature of GL.
> Applications will have to create a vbo even if all they wanna do is a
> draw a textured quad, therefore small vbos are worthwhile to optimize
> regardless.
>
That's true, but doesn't automatically make all the old OpenGL
applications use VBOs. I still want those to run as fast as possible.
Gallium's task shouldn't be to patronize me wherever possible, even if
it really enjoys doing that from time to time.

> I'm not saying we must get rid of user buffers now, but I can't help
> feeling that it is odd that while recent versions of GL/DX APIs are
> eliminating index/vertex buffers in user memory, Gallium is optimizing
> for them...
>
Gallium is not. The pipe driver is optimizing the case where they are
practical.

Christoph.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 32666] etqw triggers an assert in st_texture.c

[bugzilla-daemon]

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

Álmos  changed:

   What|Removed |Added

  Component|Drivers/Gallium/r300|Mesa core
 AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

--- Comment #1 from Álmos  2011-01-31 14:41:00 PST ---
Since 1dd8e2757852682af44b63193c89dff3c09c7703 it asserts at a different
position: at line 144 in st_gl_texture_dims_to_pipe_dims() in the
GL_TEXTURE_CUBE_MAP branch of the switch conditional. Removing that assert
(which seems pointless to me, because depthIn is not actually used in that
case) restores the old behavior.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 33786] New: Wayland terminal garbage starting with 1dd8e2757852682af44b63193c89dff3c09c7703

[bugzilla-daemon]

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

   Summary: Wayland terminal garbage starting with
1dd8e2757852682af44b63193c89dff3c09c7703
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: dar...@chaosreigns.com


commit 1dd8e2757852682af44b63193c89dff3c09c7703
Author: Brian Paul 
Date:   Fri Jan 28 20:25:27 2011 -0700

st/mesa: fix texture array dimensions


Wayland terminal output is garbage, and flips between two sets of garbage every
time I click it, starting with this commit.  Similar garbage when resizing
terminal or dnd client.  Comments from krh:

"it's probably the use of cairo_push_group that breaks somehow"
"it could be a cairo-gl too, I think"

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 33786] Wayland terminal garbage starting with 1dd8e2757852682af44b63193c89dff3c09c7703

[bugzilla-daemon]

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

Darxus  changed:

   What|Removed |Added

 CC||dar...@chaosreigns.com

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 32666] etqw triggers an assert in st_texture.c

[bugzilla-daemon]

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

--- Comment #2 from Brian Paul  2011-01-31 15:06:21 PST ---
Can you provide a gdb stack trace at the assertion?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 32666] etqw triggers an assert in st_texture.c

[bugzilla-daemon]

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

--- Comment #3 from Álmos  2011-01-31 15:24:22 PST ---
Created an attachment (id=42784)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=42784)
gdb backtrace

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Flex and bison generated files in revision control

[Ian Romanick]

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

Flex and bison have working ports for every platform on which we support
building Mesa.  It even works when building projects from within Visual
Studio (http://msdn.microsoft.com/en-us/library/aa730877%28vs.80%29.aspx).

I have just pused a branch called flex-and-bison-required that removes
these files.  What still needs to be done in that branch:

  - Generate the files that have been removed during tarball creation.

  - Checks for flex and bison in configure.ac.

  - Fixes for your platform.  If this branch does not work
out-of-the-box on your platform, push fixes.

On March 1st (or sooner with consensus) this branch will be merged to
master.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1HSc4ACgkQX1gOwKyEAw8G5ACfarVmooeUeIeD42RDmJesfSmX
Y2MAoJxeXryvDTrSsXDtd8KAdjT1xrrE
=mEnX
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Flex and bison generated files in revision control

[Jose Fonseca]

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@lists.freedesktop.org 
[mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Ian 
Romanick [i...@freedesktop.org]
Sent: Monday, January 31, 2011 23:46
To: mesa-dev@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.

Flex and bison have working ports for every platform on which we support
building Mesa.  It even works when building projects from within Visual
Studio (http://msdn.microsoft.com/en-us/library/aa730877%28vs.80%29.aspx).

I have just pused a branch called flex-and-bison-required that removes
these files.  What still needs to be done in that branch:

  - Generate the files that have been removed during tarball creation.

  - Checks for flex and bison in configure.ac.

  - Fixes for your platform.  If this branch does not work
out-of-the-box on your platform, push fixes.

On March 1st (or sooner with consensus) this branch will be merged to
master.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1HSc4ACgkQX1gOwKyEAw8G5ACfarVmooeUeIeD42RDmJesfSmX
Y2MAoJxeXryvDTrSsXDtd8KAdjT1xrrE
=mEnX
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 33758] CreateDRIDrawable can't fail gracefully

[bugzilla-daemon]

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

--- Comment #2 from nobled  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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev