mesa3d-dev

[Mesa3d-dev] [Bug 27150] glBlitFramebuffer defined on 64bit but not 32bit of Ubuntu with Mesa7.7

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

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





--- Comment #6 from Alan <al...@au...>  2010-03-21 18:58:07 PST ---
I also noticed that glBlitFramebufferEXT is defined on the header file but the
symbol is not exported into libGL.so for both 32bit and 64bit.


-- 
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] DRI SDK and modularized drivers.

[Luc V. <li...@sk...>]

On Fri, Mar 19, 2010 at 11:33:02AM -0700, Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've been busy trying to get a release out the door, so I haven't looked
> at these patches yet.  I won't have a chance to look at the patches
> until at least late next week.  I also wasn't at FOSDEM, so I don't have
> any of the background info.

I've grouped the slides and the recordings at the top of my blog entry 
about this.

The patches themselves are actually copies of eachother, with minor 
differences to adjust for changes of the tree around it (there are 16 or 
so versions of the sdk done from 7.0 through 7.8). Any actual patch is 
small, and it is build system only.

> If these patches try to enforce a "stable" interface between core Mesa
> and the classic DRI drivers, we're not interested.  At all.  This has
> been discussed and rejected many, many times before.

Ah, prepossession.

Ask yourself, did the fact that xf86 video drivers were out of tree, 
ever stop anyone from _really_ bad api breakage stunts?

The difference with in-tree and out-of-tree here is that out-of-tree 
should, theoretically, lead to more prudent interface changes. This 
without having to enforce anything, it happens naturally.

Out of tree drivers never stop interface changes, they just make them a
tiny bit more involved, and therefor, hopefully, causes the person 
making those changes to consider his actions a bit better.

But as said in an earlier email, what you incur on overhead here you 
can easily make up in the driver internal interfaces. And then the other 
synergies come weighing in.

Luc Verhaegen.

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc V. <li...@sk...>]

On Fri, Mar 19, 2010 at 12:44:39PM -0500, Bridgman, John wrote:
> Pulling drm back out of the kernel tree seems like a hard sell, but the ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for grouping. 
> 
> I guess the core question is whether we expect the X-to-ddx and mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of years. 
> 
> On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, and on the libdrm interface side we have ongoing improvements in memory management and command submission. Tough call.
> 
> I guess another option would be a "pseudo-modular" approach where the code stays in the current trees but we adopt versioning and build/test procedures which treat ddx/mesahw/libdrm as a single code base even if the code is still living in multiple projects. That might be an easy first step, but repartitioning the code does seem like a better long-term approach.
> 
> If the drm code were omitted from the proposal and we focused only on ddx/libdrm/mesahw would that help ?

Well, to continue down the same path: It doesn't really matter how 
driver developers want to scatter their own different driver bits around 
today. It should be up to them.

It shouldn't matter, but sadly it does (as you're forced to have them 
into the main trees).

If those developers are free to choose how they want to handle this, 
then it will quickly become clear for some what the best mode of working 
for them really is, as opposed to being forced to work one way.

Then there will be pressure from users, hw and distro vendors, who 
might like one or another way of working better. And i guess that this 
is what those reasoning against this are mostly afraid of. Ideas like 
this can no longer be swept under the carpet with "impossible".

Luc Verhaegen.

Re: [Mesa3d-dev] DRI SDK and modularized drivers.

[Luc V. <li...@sk...>]

On Fri, Mar 19, 2010 at 06:26:03PM +0100, Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <li...@sk...> wrote:
> > So, identify the volatile interfaces, and the more stable interfaces,
> > and then isolate the volatile ones, and then you come to only one
> > conclusion.
> 
> Except that the Mesa core <-> classic driver interface also wants to
> change from time to time in non-trivial ways, and trying to force a
> separation there on people who don't want an additional set of
> compatibility issues to deal with is not exactly a friendly move.

You have to see this in the global picture. Sure, now it adds one 
additional set of compatibility issues, but it allows for the removal 
or reduction of most of the compatibility issues we are actually hit by 
today; namely, those between the different driver specific bits.

Those driver specific bits are, by their very nature, a lot more 
volatile.

None of this work will stop interface changes, that's the last thing i 
or anyone else wants.

It will however incur a tiny bit more overhead when making interface 
changes between drivers stacks and the outside. But that in itself is 
already outdone by the ease of making driver stack internal changes 
(where more of the pain exists now).

The other advantages are all net gains.

> It may seem e.g. like the DRM interface is the worst because of rather
> large threads caused by certain kernel developer's problems, but that
> doesn't mean problems wouldn't be created by splitting other areas.

Check the timestamps on my unichrome code: most of that work was done in 
november. And it's based on ideas that have been brewing since when i 
still was at suse (as suse, a company trying to sell service around the 
linux desktop, suffers from the current layout).

So it had nothing to do with the nouveau spat at lkml recently. This 
little shouting match is just another symptom that shows that something 
is wrong with the current setup.

> In
> particular, the Mesa core <-> classic driver split only makes sense if
> there are enough people who are actually working on those drivers who
> would support the split. Otherwise, this is bound to lead straight
> into hell.
>
> In a way, the kernel people got it right: put all the drivers in one
> repository, and make building the whole package and having parallel

"put all the drivers in one repository"?

So, all of:
	* drm
	* firmware
	* libdrm
	* xorg
	* mesa/dri
	* mesa/gallium
	* libxvmc
	* libvdpau
	(add more here)
of the same driver stack, in one repository?

> installations trivial. The (only?) issues with that in X.org are that:
> 1) there is a cultural aversion due to the bad experience with the
> horrible pre-modularization setup, and

There was an SDK there, i never used it directly, i built my driver 
against the tree (which was easy too). But I became a _really_ happy 
camper when everyone shipped the xorg sdk per default, heck, i even have 
a full debian build system in unichrome, simply because the sdk allows 
for that.

Now, about building the whole package... This is called a tinderbox, 
this is a part that's easily automated.

The real question is: where is the most pain, and how can we reduce it.
And the most pain is between the driver specific parts.

> 2) it wouldn't actually solve the DRM problems, because we want to
> have the DRM in our codebase, and the kernel people want to have it in
> theirs.

The kernel people can have theirs. What stops anyone from getting the 
drm code of a released driver stack into the next kernel version?

But when anyone decides they need a new driver stack which requires a 
new drm module, it should be easy to replace the stock kernel module.

Luc Verhaegen.

Re: [Mesa3d-dev] Mesa (master): gallium: add soft screen helper

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

On Sun, Mar 21, 2010 at 5:57 PM, George Sapountzis
<gsa...@gm...> wrote:
> On Sun, Mar 21, 2010 at 7:43 PM, George Sapountzis
> <gsa...@gm...> wrote:
>> On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell
>> <kei...@go...> wrote:
>>> George,
>>>
>>> This is basically a reproduction of a facility I had in target-helpers
>>> previously (swrast_screen.c or similar), which I removed after
>>> feedback from Jose that supporting it with scons created more ugliness
>>> than we saved in the C code.
>>>
>
> Ah ok, i was not aware of this
>
>>> This change breaks layering in the build system by making code in the
>>> utility libraries conditionally built depending on which targets we're
>>> supporting.  Ideally the code in auxilliary wouldn't have any idea
>>> whether softpipe, llvmpipe or any other driver is out there.
>>>
>
> This commit did not build soft_screen.c with auxiliary but symlinked
> it at each target and build it there, I guess this is not pretty
> either. For the record, the scons build seemed to work (after getting
> broken) as reported by Xavier.

OK, that would overcome the issue I was thinking of, but agree it's
not pretty either...


>>> For the meantime, I'd say just duplicate the function in the few
>>> places which use it.  There aren't many currently.  Longer term, I
>>> think we probably want a little targets/common or similar, rather than
>>> trying to bundle this into auxilliary.
>>>
>
> Ah ok, so it will be build once and all places will use the same
> software renderer by default.

That's the hope...

>>
>> Ok, I just reverted the commit and the commits that fix it. It seems
>> that there will be three places using it (libgl-xlib, drm/sw and
>> drm/swrast). I'll give it a try some other day when I can read and
>> type.
>>
>

Thanks George.

Keith

[Mesa3d-dev] [PATCH] add r200-swtnl-material-fallback test case

[Pauli N. <su...@gm...>]

There is bug in r200 swtnl fallback that hwtnl state is emited in swtnl flush.
Bug causes emit size to be larger that excepted which might cause crash in some
corner cases.

Signed-off-by: Pauli Nieminen <su...@gm...>
---
 tests/all.tests                           |    1 +
 tests/bugs/CMakeLists.txt                 |    1 +
 tests/bugs/r200-swtnl-material-fallback.c |   79 +++++++++++++++++++++++++++++
 3 files changed, 81 insertions(+), 0 deletions(-)
 create mode 100644 tests/bugs/r200-swtnl-material-fallback.c

diff --git a/tests/all.tests b/tests/all.tests
index d42de3b..afb0cb6 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -241,6 +241,7 @@ add_plain_test(bugs, 'fdo10370')
 add_plain_test(bugs, 'fdo14575')
 add_plain_test(bugs, 'fdo20701')
 add_plain_test(bugs, 'r300-readcache')
+add_plain_test(bugs, 'r200-swtnl-material-fallback')
 add_plain_test(bugs, 'tex1d-2dborder')
 add_plain_test(bugs, 'point-sprite')
 add_plain_test(bugs, 'fdo22540')
diff --git a/tests/bugs/CMakeLists.txt b/tests/bugs/CMakeLists.txt
index 3a72a96..de5ac5d 100644
--- a/tests/bugs/CMakeLists.txt
+++ b/tests/bugs/CMakeLists.txt
@@ -35,3 +35,4 @@ add_executable (fdo23670-depth_test fdo23670-depth_test.c)
 add_executable (fdo23670-drawpix_stencil fdo23670-drawpix_stencil.c)
 add_executable (fdo24066 fdo24066.c)
 add_executable (fdo25614-genmipmap fdo25614-genmipmap.c)
+add_executable (r200-swtnl-material-fallback r200-swtnl-material-fallback.c)
diff --git a/tests/bugs/r200-swtnl-material-fallback.c b/tests/bugs/r200-swtnl-material-fallback.c
new file mode 100644
index 0000000..4cc22d8
--- /dev/null
+++ b/tests/bugs/r200-swtnl-material-fallback.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright © 2010 Pauli Nieminen
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * Check that r200 swtnl fallback return doesn't emit hwtnl state.
+ *
+ * \author Pauli Nieminen
+ */
+
+
+#include "piglit-util.h"
+
+int piglit_width = 100;
+int piglit_height = 100;
+int piglit_window_mode = GLUT_RGB | GLUT_DOUBLE;
+
+void
+piglit_init(int argc, char **argv)
+{
+	piglit_ortho_projection(piglit_width, piglit_height, GL_FALSE);
+	glClearColor(0.0, 0.0, 0.0, 0.0);
+}
+
+enum piglit_result
+piglit_display(void)
+{
+	static GLfloat excepted[][3] = {
+		{0.2,0.0,0.0},
+		{0.2,0.2,0.2},
+	};
+	static GLfloat mat[][4] = {
+		{1.0,0.0,0.0,0.0},
+		{1.0,1.0,1.0,0.0},
+	};
+
+	GLboolean pass = GL_TRUE;
+	glClear(GL_COLOR_BUFFER_BIT);
+	glEnable(GL_LIGHTING);
+
+	glBegin(GL_TRIANGLE_STRIP);
+
+	glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, mat[0]);
+	glVertex3f((GLfloat)piglit_height, 0.0, 0.0);
+	glVertex3f(0.0, 0.0, 0.0);
+	glVertex3f((GLfloat)piglit_height, (GLfloat)piglit_width, 0.0);
+	glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, mat[1]);
+	glVertex3f(0.0, (GLfloat) piglit_width, 0.0);
+
+	glEnd();
+
+	if (!piglit_probe_pixel_rgb(piglit_width - 1, 1, excepted[0]))
+		pass = GL_FALSE;
+	if (!piglit_probe_pixel_rgb(1, piglit_height - 1, excepted[1]))
+		pass = GL_FALSE;
+
+	glutSwapBuffers();
+
+	return pass ? PIGLIT_SUCCESS : PIGLIT_FAILURE;
+}
-- 
1.6.3.3

Re: [Mesa3d-dev] Mesa (master): gallium: add soft screen helper

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

On Sun, Mar 21, 2010 at 7:43 PM, George Sapountzis
<gsa...@gm...> wrote:
> On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell
> <kei...@go...> wrote:
>> George,
>>
>> This is basically a reproduction of a facility I had in target-helpers
>> previously (swrast_screen.c or similar), which I removed after
>> feedback from Jose that supporting it with scons created more ugliness
>> than we saved in the C code.
>>

Ah ok, i was not aware of this

>> This change breaks layering in the build system by making code in the
>> utility libraries conditionally built depending on which targets we're
>> supporting.  Ideally the code in auxilliary wouldn't have any idea
>> whether softpipe, llvmpipe or any other driver is out there.
>>

This commit did not build soft_screen.c with auxiliary but symlinked
it at each target and build it there, I guess this is not pretty
either. For the record, the scons build seemed to work (after getting
broken) as reported by Xavier.

>> For the meantime, I'd say just duplicate the function in the few
>> places which use it.  There aren't many currently.  Longer term, I
>> think we probably want a little targets/common or similar, rather than
>> trying to bundle this into auxilliary.
>>

Ah ok, so it will be build once and all places will use the same
software renderer by default.

>
> Ok, I just reverted the commit and the commits that fix it. It seems
> that there will be three places using it (libgl-xlib, drm/sw and
> drm/swrast). I'll give it a try some other day when I can read and
> type.
>

Re: [Mesa3d-dev] Mesa (master): gallium: add soft screen helper

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

On Sun, Mar 21, 2010 at 7:22 PM, Keith Whitwell
<kei...@go...> wrote:
> George,
>
> This is basically a reproduction of a facility I had in target-helpers
> previously (swrast_screen.c or similar), which I removed after
> feedback from Jose that supporting it with scons created more ugliness
> than we saved in the C code.
>
> This change breaks layering in the build system by making code in the
> utility libraries conditionally built depending on which targets we're
> supporting.  Ideally the code in auxilliary wouldn't have any idea
> whether softpipe, llvmpipe or any other driver is out there.
>
> For the meantime, I'd say just duplicate the function in the few
> places which use it.  There aren't many currently.  Longer term, I
> think we probably want a little targets/common or similar, rather than
> trying to bundle this into auxilliary.
>

Ok, I just reverted the commit and the commits that fix it. It seems
that there will be three places using it (libgl-xlib, drm/sw and
drm/swrast). I'll give it a try some other day when I can read and
type.

Re: [Mesa3d-dev] softpipe/llvmpipe build regression

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

On Sun, Mar 21, 2010 at 6:23 PM, George Sapountzis
<gsa...@gm...> wrote:
> On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis
> <gsa...@gm...> wrote:
>> Can you please try a clean build ?
>>
>> softpipe_create_screen is defined in the newly added file
>> soft_screen.c and maybe you did not rebuild drm/sw
>>
>> If I actually broke this as well, admittedly I should have stayed away
>> from the computer today
>>
>>
>> On Sun, Mar 21, 2010 at 6:42 PM, Xavier Chantry
>> <cha...@gm...> wrote:
>>> scons dri=no drivers=softpipe or llvmpipe
>>> glxgears: symbol lookup error:
>>> /home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined
>>> symbol: gallium_soft_create_screen
>>>
>
> ah, this is the scons build, should be fixed in master now.
>
> sorry for that, it seems that I cannot read in addition to type today ...
>

Thanks that did it.

it seems scons would also benefit from -Wl,-no-undefined , but it
might also break the dri builds
(see [PATCH] dri: test whether the built drivers have unresolved symbols)

I guess I could just define LDFLAGS locally or use that simple patch :

diff --git a/SConstruct b/SConstruct
index 6ed44dd..304d73e 100644
--- a/SConstruct
+++ b/SConstruct
@@ -74,6 +74,8 @@ if os.environ.has_key('CXXFLAGS'):
 if os.environ.has_key('LDFLAGS'):
        env['LINKFLAGS'] += SCons.Util.CLVar(os.environ['LDFLAGS'])

+env['LINKFLAGS'].append("-Wl,-no-undefined")
+
 Help(opts.GenerateHelpText(env))

 # replicate options values in local variables

Re: [Mesa3d-dev] softpipe/llvmpipe build regression

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

On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis
<gsa...@gm...> wrote:
> Can you please try a clean build ?
>
> softpipe_create_screen is defined in the newly added file
> soft_screen.c and maybe you did not rebuild drm/sw
>
> If I actually broke this as well, admittedly I should have stayed away
> from the computer today
>
>
> On Sun, Mar 21, 2010 at 6:42 PM, Xavier Chantry
> <cha...@gm...> wrote:
>> scons dri=no drivers=softpipe or llvmpipe
>> glxgears: symbol lookup error:
>> /home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined
>> symbol: gallium_soft_create_screen
>>

ah, this is the scons build, should be fixed in master now.

sorry for that, it seems that I cannot read in addition to type today ...

Re: [Mesa3d-dev] Mesa (master): gallium: add soft screen helper

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

George,

This is basically a reproduction of a facility I had in target-helpers
previously (swrast_screen.c or similar), which I removed after
feedback from Jose that supporting it with scons created more ugliness
than we saved in the C code.

This change breaks layering in the build system by making code in the
utility libraries conditionally built depending on which targets we're
supporting.  Ideally the code in auxilliary wouldn't have any idea
whether softpipe, llvmpipe or any other driver is out there.

For the meantime, I'd say just duplicate the function in the few
places which use it.  There aren't many currently.  Longer term, I
think we probably want a little targets/common or similar, rather than
trying to bundle this into auxilliary.

Keith

On Sun, Mar 21, 2010 at 11:24 AM, George Sapountzis
<gs...@ke...> wrote:
> Module: Mesa
> Branch: master
> Commit: f87a5f6499f51f651c2a9f2d4682875b22926905
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=f87a5f6499f51f651c2a9f2d4682875b22926905
>
> Author: George Sapountzis <gsa...@gm...>
> Date:   Fri Mar 19 02:38:11 2010 +0200
>
> gallium: add soft screen helper
>
> ---
>
>  src/gallium/auxiliary/target-helpers/soft_screen.c |   73 ++++++++++++++++++++
>  src/gallium/auxiliary/target-helpers/soft_screen.h |   12 +++
>  src/gallium/targets/libgl-xlib/Makefile            |    1 +
>  src/gallium/targets/libgl-xlib/soft_screen.c       |    1 +
>  src/gallium/targets/libgl-xlib/xlib.c              |   34 +---------
>  src/gallium/winsys/drm/sw/Makefile                 |    3 +-
>  src/gallium/winsys/drm/sw/soft_screen.c            |    1 +
>  src/gallium/winsys/drm/sw/sw_drm_api.c             |   32 ++++++++-
>  8 files changed, 120 insertions(+), 37 deletions(-)
>
> diff --git a/src/gallium/auxiliary/target-helpers/soft_screen.c b/src/gallium/auxiliary/target-helpers/soft_screen.c
> new file mode 100644
> index 0000000..00d386e
> --- /dev/null
> +++ b/src/gallium/auxiliary/target-helpers/soft_screen.c
> @@ -0,0 +1,73 @@
> +/**************************************************************************
> + *
> + * Copyright 2010 VMware, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the
> + * "Software"), to deal in the Software without restriction, including
> + * without limitation the rights to use, copy, modify, merge, publish,
> + * distribute, sub license, and/or sell copies of the Software, and to
> + * permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + *
> + **************************************************************************/
> +
> +#include "target-helpers/soft_screen.h"
> +#include "softpipe/sp_public.h"
> +#include "llvmpipe/lp_public.h"
> +#include "cell/ppu/cell_public.h"
> +#include "util/u_debug.h"
> +
> +/**
> + * Choose and create a software renderer screen.
> + */
> +struct pipe_screen *
> +gallium_soft_create_screen( struct sw_winsys *winsys )
> +{
> +   const char *default_driver = NULL;
> +   const char *driver = NULL;
> +   struct pipe_screen *screen = NULL;
> +
> +#if defined(GALLIUM_CELL)
> +   default_driver = "cell";
> +#elif defined(GALLIUM_LLVMPIPE)
> +   default_driver = "llvmpipe";
> +#elif defined(GALLIUM_SOFTPIPE)
> +   default_driver = "softpipe";
> +#else
> +   default_driver = "";
> +#endif
> +
> +   driver = debug_get_option("GALLIUM_DRIVER", default_driver);
> +
> +#if defined(GALLIUM_CELL)
> +   if (screen == NULL && strcmp(driver, "cell") == 0)
> +      screen = cell_create_screen( winsys );
> +#endif
> +
> +#if defined(GALLIUM_LLVMPIPE)
> +   if (screen == NULL && strcmp(driver, "llvmpipe") == 0)
> +      screen = llvmpipe_create_screen( winsys );
> +#endif
> +
> +#if defined(GALLIUM_SOFTPIPE)
> +   if (screen == NULL)
> +      screen = softpipe_create_screen( winsys );
> +#endif
> +
> +   return screen;
> +}
> diff --git a/src/gallium/auxiliary/target-helpers/soft_screen.h b/src/gallium/auxiliary/target-helpers/soft_screen.h
> new file mode 100644
> index 0000000..5c10126
> --- /dev/null
> +++ b/src/gallium/auxiliary/target-helpers/soft_screen.h
> @@ -0,0 +1,12 @@
> +#ifndef SOFT_SCREEN_HELPER_H
> +#define SOFT_SCREEN_HELPER_H
> +
> +#include "pipe/p_compiler.h"
> +
> +struct pipe_screen;
> +struct sw_winsys;
> +
> +struct pipe_screen *
> +gallium_soft_create_screen( struct sw_winsys *winsys );
> +
> +#endif
> diff --git a/src/gallium/targets/libgl-xlib/Makefile b/src/gallium/targets/libgl-xlib/Makefile
> index 5a4e035..2c44a62 100644
> --- a/src/gallium/targets/libgl-xlib/Makefile
> +++ b/src/gallium/targets/libgl-xlib/Makefile
> @@ -27,6 +27,7 @@ DEFINES += \
>  #-DGALLIUM_CELL will be defined by the config */
>
>  XLIB_TARGET_SOURCES = \
> +       soft_screen.c \
>        xlib.c
>
>
> diff --git a/src/gallium/targets/libgl-xlib/soft_screen.c b/src/gallium/targets/libgl-xlib/soft_screen.c
> new file mode 120000
> index 0000000..d6d878f
> --- /dev/null
> +++ b/src/gallium/targets/libgl-xlib/soft_screen.c
> @@ -0,0 +1 @@
> +../../auxiliary/target-helpers/soft_screen.c
> \ No newline at end of file
> diff --git a/src/gallium/targets/libgl-xlib/xlib.c b/src/gallium/targets/libgl-xlib/xlib.c
> index 48e79fe..e786221 100644
> --- a/src/gallium/targets/libgl-xlib/xlib.c
> +++ b/src/gallium/targets/libgl-xlib/xlib.c
> @@ -36,6 +36,7 @@
>  #include "softpipe/sp_public.h"
>  #include "llvmpipe/lp_public.h"
>  #include "cell/ppu/cell_public.h"
> +#include "target-helpers/soft_screen.h"
>  #include "target-helpers/wrap_screen.h"
>  #include "xm_public.h"
>
> @@ -63,8 +64,6 @@ PUBLIC const struct st_module st_module_OpenGL = {
>  static struct pipe_screen *
>  swrast_xlib_create_screen( Display *display )
>  {
> -   const char *default_driver;
> -   const char *driver;
>    struct sw_winsys *winsys;
>    struct pipe_screen *screen = NULL;
>
> @@ -75,36 +74,7 @@ swrast_xlib_create_screen( Display *display )
>    if (winsys == NULL)
>       return NULL;
>
> -#if defined(GALLIUM_CELL)
> -   default_driver = "cell";
> -#elif defined(GALLIUM_LLVMPIPE)
> -   default_driver = "llvmpipe";
> -#elif defined(GALLIUM_SOFTPIPE)
> -   default_driver = "softpipe";
> -#else
> -   default_driver = "";
> -#endif
> -
> -   driver = debug_get_option("GALLIUM_DRIVER", default_driver);
> -
> -   /* Create a software rasterizer on top of that winsys:
> -    */
> -#if defined(GALLIUM_CELL)
> -   if (screen == NULL &&
> -       strcmp(driver, "cell") == 0)
> -      screen = cell_create_screen( winsys );
> -#endif
> -
> -#if defined(GALLIUM_LLVMPIPE)
> -   if (screen == NULL &&
> -       strcmp(driver, "llvmpipe") == 0)
> -      screen = llvmpipe_create_screen( winsys );
> -#endif
> -
> -#if defined(GALLIUM_SOFTPIPE)
> -   if (screen == NULL)
> -      screen = softpipe_create_screen( winsys );
> -#endif
> +   screen = gallium_soft_create_screen( winsys );
>
>    if (screen == NULL)
>       goto fail;
> diff --git a/src/gallium/winsys/drm/sw/Makefile b/src/gallium/winsys/drm/sw/Makefile
> index 5f3c3ec..12b20cb 100644
> --- a/src/gallium/winsys/drm/sw/Makefile
> +++ b/src/gallium/winsys/drm/sw/Makefile
> @@ -4,11 +4,12 @@ include $(TOP)/configs/current
>  LIBNAME = swdrm
>
>  C_SOURCES = \
> +       soft_screen.c \
>        wrapper_sw_winsys.c \
>        sw_drm_api.c
>
>  LIBRARY_INCLUDES =
>
> -LIBRARY_DEFINES =
> +LIBRARY_DEFINES = -DGALLIUM_SOFTPIPE
>
>  include ../../../Makefile.template
> diff --git a/src/gallium/winsys/drm/sw/soft_screen.c b/src/gallium/winsys/drm/sw/soft_screen.c
> new file mode 120000
> index 0000000..423597b
> --- /dev/null
> +++ b/src/gallium/winsys/drm/sw/soft_screen.c
> @@ -0,0 +1 @@
> +../../../auxiliary/target-helpers/soft_screen.c
> \ No newline at end of file
> diff --git a/src/gallium/winsys/drm/sw/sw_drm_api.c b/src/gallium/winsys/drm/sw/sw_drm_api.c
> index 9c5933c..ed3ce14 100644
> --- a/src/gallium/winsys/drm/sw/sw_drm_api.c
> +++ b/src/gallium/winsys/drm/sw/sw_drm_api.c
> @@ -24,8 +24,11 @@
>  **********************************************************/
>
>
> +#include "pipe/p_screen.h"
>  #include "util/u_memory.h"
> -#include "softpipe/sp_public.h"
> +#include "target-helpers/soft_screen.h"
> +
> +#include "state_tracker/sw_winsys.h"
>  #include "state_tracker/drm_api.h"
>  #include "wrapper_sw_winsys.h"
>  #include "sw_drm_api.h"
> @@ -60,14 +63,35 @@ sw_drm_create_screen(struct drm_api *_api, int drmFD,
>  {
>    struct sw_drm_api *swapi = sw_drm_api(_api);
>    struct drm_api *api = swapi->api;
> -   struct sw_winsys *sww;
> -   struct pipe_screen *screen;
> +   struct sw_winsys *sww = NULL;
> +   struct pipe_screen *screen = NULL;
> +   struct pipe_screen *soft_screen = NULL;
>
>    screen = api->create_screen(api, drmFD, arg);
> +   if (screen == NULL)
> +      goto fail;
>
>    sww = wrapper_sw_winsys_warp_pipe_screen(screen);
> +   if (sww == NULL)
> +      goto fail;
> +
> +   soft_screen = gallium_soft_create_screen(sww);
> +   if (soft_screen == NULL)
> +      goto fail;
> +
> +   return soft_screen;
> +
> +fail:
> +   if (soft_screen)
> +      soft_screen->destroy(soft_screen);
> +
> +   if (sww)
> +      sww->destroy(sww);
> +
> +   if (screen)
> +      screen->destroy(screen);
>
> -   return softpipe_create_screen(sww);
> +   return NULL;
>  }
>
>  static void
>
> _______________________________________________
> mesa-commit mailing list
> mes...@li...
> http://lists.freedesktop.org/mailman/listinfo/mesa-commit
>

Re: [Mesa3d-dev] softpipe/llvmpipe build regression

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

On Sun, Mar 21, 2010 at 6:50 PM, George Sapountzis
<gsa...@gm...> wrote:
> Can you please try a clean build ?
>
> softpipe_create_screen is defined in the newly added file
> soft_screen.c and maybe you did not rebuild drm/sw
>

s/softpipe_create_screen/gallium_soft_create_screen/ in the above
sentence, only to confirm the statement below.

> If I actually broke this as well, admittedly I should have stayed away
> from the computer today
>
>

Re: [Mesa3d-dev] softpipe/llvmpipe build regression

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

Can you please try a clean build ?

softpipe_create_screen is defined in the newly added file
soft_screen.c and maybe you did not rebuild drm/sw

If I actually broke this as well, admittedly I should have stayed away
from the computer today


On Sun, Mar 21, 2010 at 6:42 PM, Xavier Chantry
<cha...@gm...> wrote:
> scons dri=no drivers=softpipe or llvmpipe
> glxgears: symbol lookup error:
> /home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined
> symbol: gallium_soft_create_screen
>
> Works after these two reverts :
>    Revert "gallium: add soft screen helper"
>
>    This reverts commit f87a5f6499f51f651c2a9f2d4682875b22926905.
>
>    Revert "drm/sw: just s/softpipe_create_screen/gallium_soft_create_screen/"
>
>    This reverts commit 5d524cce9c4fcc18ed977801d59ba7bb911020db.
>
> Am I doing something wrong or is it indeed still broken after f87a5f6 ?
>
> ------------------------------------------------------------------------------
> 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
>

[Mesa3d-dev] softpipe/llvmpipe build regression

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

scons dri=no drivers=softpipe or llvmpipe
glxgears: symbol lookup error:
/home/xavier/app/mesa/build/linux-x86_64/lib/libGL.so.1: undefined
symbol: gallium_soft_create_screen

Works after these two reverts :
    Revert "gallium: add soft screen helper"

    This reverts commit f87a5f6499f51f651c2a9f2d4682875b22926905.

    Revert "drm/sw: just s/softpipe_create_screen/gallium_soft_create_screen/"

    This reverts commit 5d524cce9c4fcc18ed977801d59ba7bb911020db.

Am I doing something wrong or is it indeed still broken after f87a5f6 ?

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

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

On Sun, Mar 21, 2010 at 4:46 AM, Chia-I Wu <ol...@gm...> wrote:
> On Fri, Mar 19, 2010 at 09:57:41PM +0200, George Sapountzis wrote:
>> The timing of the first attempt was unfortunate because it was in the
>> middle of a re-factoring I had not realized it was happening. The good
>> thing is that after the changes by Chia-I and Keith, implementing
>> swrastg_dri.so is much simpler. I update the patches at the above
>> branch, gallium swrast_dri.so works now with the following caveats:
>> * stride: the driver and the loader compute the stride independently.
>> They usually agree, but when you start resizing and they finally
>> don't, you get a regular oblique image. If you run with valgrind, you
>> also get a regular message the size of the mismatch, at each PutImage.
>> * fences: i did not use any, are they needed for cell/llvmpipe ?
> Nice work.
>
> I haven't tried this, but I think there should be DRM_CREATE_DRISW and
> drisw_api.h, similar to how DRI1 is supported, and let winsys/drm decide
> which version to support.  swrast will be the only one to support
> DRM_CREATE_DRISW.
>
> This will also give st/dri a chance to define whatever needed to swrast
> to implement displaytarget_display in drisw_api.h, both at
> drm_api::create_screen time and pipe_screen::flush_frontbuffer time.
> drisw_st_framebuffer_flush_front will then only prepare a pipe_surface
> for the given attachment and call pipe_screen::flush_frontbuffer.
> Similar to what st/glx is doing.  This may also solve the resize issue.
>

Ah ok, I see this is the right way to do it in gallium. The problem is
that DRISW, similar to DRI2, will need to call the loader from the
winsys, and from a quick look, this is not done for DRI2 either. So
this probably will have to wait for the infrastructure to grow for
DRI2 and DRISW will be adapted accordingly afterwards.

Wrt the resize issue, solving it properly requires adding the stride
as a parameter to the putImage hook of the DRISW loader extension. I
committed an ugly workaround at ~gsap7/gallium-drisw which works for
softpipe but I don't know when it will explode platform-, rendering-
or performance-wise.

> If it is feasible, I think it is better to have st/dri support all three
> of DRI1/DRI2/DRISW at the same time when drm.h is available;  And have
> st/dri support only DRISW when drm.h is not available.  This will
> eliminate the need for st/drisw.

Yes, it is feasible but it requires mingling with the mesa build
system, which I am not too enthusiastic about :-)

Thanks for your comments!
George.

[Mesa3d-dev] [Bug 25994] [i915][GLSL] 'return' statement in vertex shader may cause GPU hang

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

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





--- Comment #13 from Loose Vladimir <wol...@mi...>  2010-03-21 08:51:23 PST ---
Happy to say, someone with nickname pino had looked at this bug report and
tested shader.c and Mortal fragment shader on his hardware:

Chipset: GM45
System architecture: x86
xserver-xorg-video-intel 2.6.3
xserver 1.7.4
mesa 7.4
libdrm 2.4.5
kernel 2.6.28-11-generic 
Linux distribution: Ubuntu 9.04
Machine: Lenovo G550 model 20023
Display connector: LVDS

As he said, he haven't encountered any bugs during Mortal fragment shader test. 

shader.c with "#if 0" causes X server crash and GPU hang.


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

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

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

Hi George,
               Your revert commit fixed the probelm,thank you very much
indeed.
Regards,
            STEVE555

George Sapountzis wrote:
> 
> On Sun, Mar 21, 2010 at 4:31 PM, Marek Olšák <ma...@gm...> wrote:
>> Please do "git pull --rebase origin" instead of "git pull origin" to
>> avoid
>> "Merge branch 'master' of ..." commits.
>>
> 
> yes, i left them because the intervening commits happened between a
> local 'git clean -fdx' and a 'git push' ... to denote the point of the
> 'git clean -fdx', anyway ...
> 
> ------------------------------------------------------------------------------
> 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/New-branch-to-switch-st-dri-to-st_api.h-tp27940955p27976768.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

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

On Sun, Mar 21, 2010 at 4:31 PM, Marek Olšák <ma...@gm...> wrote:
> Please do "git pull --rebase origin" instead of "git pull origin" to avoid
> "Merge branch 'master' of ..." commits.
>

yes, i left them because the intervening commits happened between a
local 'git clean -fdx' and a 'git push' ... to denote the point of the
'git clean -fdx', anyway ...

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

[Marek O. <ma...@gm...>]

Please do "git pull --rebase origin" instead of "git pull origin" to avoid
"Merge branch 'master' of ..." commits.

-Marek

On Sun, Mar 21, 2010 at 2:40 PM, George Sapountzis <gsa...@gm...>wrote:

> That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a
> pristine build. I reverted it for now.
>
> On Sun, Mar 21, 2010 at 2:31 PM, STEVE555 <ste...@ho...>
> wrote:
> >
> > Hi Chia-I Wu,
> >                   I've just updated my copy of Mesa master today after
> your
> > merge and the latest commits(from about 11:30 am GMT).I build Mesa with
> > these configure options:
> > ./configure --prefix=/usr --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.
> >
> > I've used both gmake and make after ./configure,and Mesa keeps hitting
> this
> > error when it tries to build the svga state-tracker:
> >
> > gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/svga'
> > rm -f depend
> > touch depend
> > /usr/bin/makedepend -fdepend
> -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include
> > -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
> > -I../../../../src/gallium/drivers
> > -I../../../../src/gallium/drivers/svga/include -std=gnu99
> > -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H
> > svgadump/svga_shader_dump.c svgadump/svga_shader_op.c
> svgadump/svga_dump.c
> > svga_cmd.c svga_context.c svga_draw.c svga_draw_arrays.c
> > svga_draw_elements.c svga_pipe_blend.c svga_pipe_blit.c svga_pipe_clear.c
> > svga_pipe_constants.c svga_pipe_depthstencil.c svga_pipe_draw.c
> > svga_pipe_flush.c svga_pipe_fs.c svga_pipe_misc.c svga_pipe_query.c
> > svga_pipe_rasterizer.c svga_pipe_sampler.c svga_pipe_vertex.c
> svga_pipe_vs.c
> > svga_screen.c svga_screen_buffer.c svga_screen_texture.c
> svga_screen_cache.c
> > svga_state.c svga_state_need_swtnl.c svga_state_constants.c
> > svga_state_framebuffer.c svga_state_rss.c svga_state_tss.c
> > svga_state_vdecl.c svga_state_fs.c svga_state_vs.c svga_swtnl_backend.c
> > svga_swtnl_draw.c svga_swtnl_state.c svga_tgsi.c svga_tgsi_decl_sm20.c
> > svga_tgsi_decl_sm30.c svga_tgsi_insn.c    2> /dev/null
> > gmake[4]: *** No rule to make target `depend', needed by `default'.
>  Stop.
> > gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/svga'
> > gmake[3]: *** [default] Error 1
> > gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers'
> > gmake[2]: *** [default] Error 1
> > gmake[2]: Leaving directory `/opt/mesa/src/gallium'
> > make[1]: *** [subdirs] Error 1
> > make[1]: Leaving directory `/opt/mesa/src'
> > make: *** [default] Error 1
> > Regards,
> >            STEVE555
> >
> >
> > Sedat Dilek wrote:
> >>
> >> On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu <ol...@gm...> wrote:
> >>> On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek <
> sed...@go...>
> >>> wrote:
> >> [...]
> >>>> Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps
> >>>> (master GIT incl. gallium-st-api-dri merge)
> >>>> $ cat oa_benchmark.txt
> >>>> sd@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 |
> >>>> egrep -e '[0-9]+ frames'
> >>>> 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms
> >>>> Thanks for your work!
> >>> Unless I have some magic power that I am not aware of, the boost should
> >>> be
> >>> attributed to r300g developers.
> >>>
> >>
> >> I think, it is helpful to benchmark from time to time.
> >> I was comparing the both branches 7.8 and 7.9-devel in general and
> >> especiall r300g dri/st.
> >> Indeed, Chapeau to all contributors to r300g development.
> >>
> >> --
> >> Sedat
> >>
> >>
> ------------------------------------------------------------------------------
> >> Download Intel® 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/New-branch-to-switch-st-dri-to-st_api.h-tp27940955p27975796.html
> > Sent from the mesa3d-dev mailing list archive at Nabble.com.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel® 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
>

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

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

On Sun, Mar 21, 2010 at 8:31 PM, STEVE555 <ste...@ho...> wrote:
>                   I've just updated my copy of Mesa master today after your
> merge and the latest commits(from about 11:30 am GMT).I build Mesa with
> these configure options:
> ./configure --prefix=/usr --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.
>
> I've used both gmake and make after ./configure,and Mesa keeps hitting this
> error when it tries to build the svga state-tracker:
>
> gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/svga'
> rm -f depend
> touch depend
> /usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include
> -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
> -I../../../../src/gallium/drivers
> -I../../../../src/gallium/drivers/svga/include -std=gnu99

      ^^^^^^^^
If you remove the "2>/dev/nul/" in the end, you will notice that this option
causes an error.  It is not related to the merge, and it should be fixed in
59629b413a7e3e3ba4b4213eb3ba4b65bdf3f9fb.
> -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H
> svgadump/svga_shader_dump.c svgadump/svga_shader_op.c svgadump/svga_dump.c
> svga_cmd.c svga_context.c svga_draw.c svga_draw_arrays.c
> svga_draw_elements.c svga_pipe_blend.c svga_pipe_blit.c svga_pipe_clear.c
> svga_pipe_constants.c svga_pipe_depthstencil.c svga_pipe_draw.c
> svga_pipe_flush.c svga_pipe_fs.c svga_pipe_misc.c svga_pipe_query.c
> svga_pipe_rasterizer.c svga_pipe_sampler.c svga_pipe_vertex.c svga_pipe_vs.c
> svga_screen.c svga_screen_buffer.c svga_screen_texture.c svga_screen_cache.c
> svga_state.c svga_state_need_swtnl.c svga_state_constants.c
> svga_state_framebuffer.c svga_state_rss.c svga_state_tss.c
> svga_state_vdecl.c svga_state_fs.c svga_state_vs.c svga_swtnl_backend.c
> svga_swtnl_draw.c svga_swtnl_state.c svga_tgsi.c svga_tgsi_decl_sm20.c
> svga_tgsi_decl_sm30.c svga_tgsi_insn.c    2> /dev/null
> gmake[4]: *** No rule to make target `depend', needed by `default'.  Stop.
> gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/svga'
> gmake[3]: *** [default] Error 1
> gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/opt/mesa/src/gallium'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/opt/mesa/src'
> make: *** [default] Error 1

-- 
ol...@Lu...

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

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

That was commit 9ec29e31919e85f9230867f43841c0e74be930d3 when doing a
pristine build. I reverted it for now.

On Sun, Mar 21, 2010 at 2:31 PM, STEVE555 <ste...@ho...> wrote:
>
> Hi Chia-I Wu,
>                   I've just updated my copy of Mesa master today after your
> merge and the latest commits(from about 11:30 am GMT).I build Mesa with
> these configure options:
> ./configure --prefix=/usr --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.
>
> I've used both gmake and make after ./configure,and Mesa keeps hitting this
> error when it tries to build the svga state-tracker:
>
> gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/svga'
> rm -f depend
> touch depend
> /usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include
> -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
> -I../../../../src/gallium/drivers
> -I../../../../src/gallium/drivers/svga/include -std=gnu99
> -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H
> svgadump/svga_shader_dump.c svgadump/svga_shader_op.c svgadump/svga_dump.c
> svga_cmd.c svga_context.c svga_draw.c svga_draw_arrays.c
> svga_draw_elements.c svga_pipe_blend.c svga_pipe_blit.c svga_pipe_clear.c
> svga_pipe_constants.c svga_pipe_depthstencil.c svga_pipe_draw.c
> svga_pipe_flush.c svga_pipe_fs.c svga_pipe_misc.c svga_pipe_query.c
> svga_pipe_rasterizer.c svga_pipe_sampler.c svga_pipe_vertex.c svga_pipe_vs.c
> svga_screen.c svga_screen_buffer.c svga_screen_texture.c svga_screen_cache.c
> svga_state.c svga_state_need_swtnl.c svga_state_constants.c
> svga_state_framebuffer.c svga_state_rss.c svga_state_tss.c
> svga_state_vdecl.c svga_state_fs.c svga_state_vs.c svga_swtnl_backend.c
> svga_swtnl_draw.c svga_swtnl_state.c svga_tgsi.c svga_tgsi_decl_sm20.c
> svga_tgsi_decl_sm30.c svga_tgsi_insn.c    2> /dev/null
> gmake[4]: *** No rule to make target `depend', needed by `default'.  Stop.
> gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/svga'
> gmake[3]: *** [default] Error 1
> gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/opt/mesa/src/gallium'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/opt/mesa/src'
> make: *** [default] Error 1
> Regards,
>            STEVE555
>
>
> Sedat Dilek wrote:
>>
>> On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu <ol...@gm...> wrote:
>>> On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek <sed...@go...>
>>> wrote:
>> [...]
>>>> Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps
>>>> (master GIT incl. gallium-st-api-dri merge)
>>>> $ cat oa_benchmark.txt
>>>> sd@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 |
>>>> egrep -e '[0-9]+ frames'
>>>> 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms
>>>> Thanks for your work!
>>> Unless I have some magic power that I am not aware of, the boost should
>>> be
>>> attributed to r300g developers.
>>>
>>
>> I think, it is helpful to benchmark from time to time.
>> I was comparing the both branches 7.8 and 7.9-devel in general and
>> especiall r300g dri/st.
>> Indeed, Chapeau to all contributors to r300g development.
>>
>> --
>> Sedat
>>
>> ------------------------------------------------------------------------------
>> Download Intel® 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/New-branch-to-switch-st-dri-to-st_api.h-tp27940955p27975796.html
> Sent from the mesa3d-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Download Intel® 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
>

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

[Sedat D. <sed...@go...>]

Maybe you try a git-hard-reset to the commit-no of the merge and then
compile again.
(To see if it is related to gallium-st-api-dri merge)

$ git reset --hard 12deb9e6ca76d222badf71c8643e84640673e86d

--
Sedat

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

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

Hi Chia-I Wu,
                   I've just updated my copy of Mesa master today after your
merge and the latest commits(from about 11:30 am GMT).I build Mesa with
these configure options:
./configure --prefix=/usr --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.

I've used both gmake and make after ./configure,and Mesa keeps hitting this
error when it tries to build the svga state-tracker:

gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/svga'
rm -f depend
touch depend
/usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include
-I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
-I../../../../src/gallium/drivers
-I../../../../src/gallium/drivers/svga/include -std=gnu99
-fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H
svgadump/svga_shader_dump.c svgadump/svga_shader_op.c svgadump/svga_dump.c
svga_cmd.c svga_context.c svga_draw.c svga_draw_arrays.c
svga_draw_elements.c svga_pipe_blend.c svga_pipe_blit.c svga_pipe_clear.c
svga_pipe_constants.c svga_pipe_depthstencil.c svga_pipe_draw.c
svga_pipe_flush.c svga_pipe_fs.c svga_pipe_misc.c svga_pipe_query.c
svga_pipe_rasterizer.c svga_pipe_sampler.c svga_pipe_vertex.c svga_pipe_vs.c
svga_screen.c svga_screen_buffer.c svga_screen_texture.c svga_screen_cache.c
svga_state.c svga_state_need_swtnl.c svga_state_constants.c
svga_state_framebuffer.c svga_state_rss.c svga_state_tss.c
svga_state_vdecl.c svga_state_fs.c svga_state_vs.c svga_swtnl_backend.c
svga_swtnl_draw.c svga_swtnl_state.c svga_tgsi.c svga_tgsi_decl_sm20.c
svga_tgsi_decl_sm30.c svga_tgsi_insn.c    2> /dev/null
gmake[4]: *** No rule to make target `depend', needed by `default'.  Stop.
gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/svga'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/gallium'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/opt/mesa/src'
make: *** [default] Error 1
Regards,
            STEVE555


Sedat Dilek wrote:
> 
> On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu <ol...@gm...> wrote:
>> On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek <sed...@go...>
>> wrote:
> [...]
>>> Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps
>>> (master GIT incl. gallium-st-api-dri merge)
>>> $ cat oa_benchmark.txt
>>> sd@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 |
>>> egrep -e '[0-9]+ frames'
>>> 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms
>>> Thanks for your work!
>> Unless I have some magic power that I am not aware of, the boost should
>> be
>> attributed to r300g developers.
>>
> 
> I think, it is helpful to benchmark from time to time.
> I was comparing the both branches 7.8 and 7.9-devel in general and
> especiall r300g dri/st.
> Indeed, Chapeau to all contributors to r300g development.
> 
> --
> Sedat
> 
> ------------------------------------------------------------------------------
> 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/New-branch-to-switch-st-dri-to-st_api.h-tp27940955p27975796.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

[Sedat D. <sed...@go...>]

On Sun, Mar 21, 2010 at 10:33 AM, Chia-I Wu <ol...@gm...> wrote:
> On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek <sed...@go...> wrote:
[...]
>> Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps
>> (master GIT incl. gallium-st-api-dri merge)
>> $ cat oa_benchmark.txt
>> sd@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 |
>> egrep -e '[0-9]+ frames'
>> 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms
>> Thanks for your work!
> Unless I have some magic power that I am not aware of, the boost should be
> attributed to r300g developers.
>

I think, it is helpful to benchmark from time to time.
I was comparing the both branches 7.8 and 7.9-devel in general and
especiall r300g dri/st.
Indeed, Chapeau to all contributors to r300g development.

--
Sedat

Re: [Mesa3d-dev] New branch to switch st/dri to st_api.h

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

On Sun, Mar 21, 2010 at 5:19 PM, Sedat Dilek <sed...@go...> wrote:
> Hi Chia-I (hope this is the first name),
It is :)
>>I've merged the branch.  All Gallium DRI drivers now use st_api.h
>>instead of st_public.h.  If you notice any regression due the merge,
>>please let me know so that I can work on it.
> The last days I have tested your gallium-st-api-dri GIT branch by
> merging into mesa master GIT.
> I was testing here with r300g st/dri on an RV515 radeon gfxcard.
> So, here is my positive feedback: Works here, lovely.
Thanks for the inspiring feedback, and for testing out the branch.
> Even I see OpenArena got a boost from ~25fps (7.8 GIT) to ~32fps
> (master GIT incl. gallium-st-api-dri merge)
> $ cat oa_benchmark.txt
> sd@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 |
> egrep -e '[0-9]+ frames'
> 840 frames 26.3 seconds 31.9 fps 9.0/31.3/90.0/9.9 ms
> Thanks for your work!
Unless I have some magic power that I am not aware of, the boost should be
attributed to r300g developers.

-- 
ol...@Lu...