mesa3d-dev

Re: [Mesa3d-dev] [PATCH] dri: test whether the built drivers have unresolved symbols

[Luca B. <lu...@lu...>]

> For developers that makes a lot of sense, but I've never seen any
> other projects impose this type of thing on regular users.

Why do you see it as an onerous imposition?
It just tries to compile a program linked with a couple of libraries
(the DRI driver, plus libGL) and makes the build fail if that fails.
It doesn't even execute the built program (and could not always do so
even if it were desired, since you could be cross-compiling).

Re: [Mesa3d-dev] [PATCH] dri: test whether the built drivers have unresolved symbols

[Dan N. <dbn...@gm...>]

On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri <lu...@lu...> wrote:
>> Can we just put this program in the demos? Or at least just make it a
>> separate target (make test-link)? It seems excessive to make this part
>> of the default build path.
>
> The whole purpose is to run this as part of the standard build, so
> that the build fails if any driver is unloadable, (i.e. a modification
> to it was botched) and the tree hopefully doesn't get pushed to
> master.
>
> You can test it separately by just running glxinfo/glxgears, obviously.

For developers that makes a lot of sense, but I've never seen any
other projects impose this type of thing on regular users.

--
Dan

Re: [Mesa3d-dev] [PATCH] dri: test whether the built drivers have unresolved symbols

[Luca B. <lu...@lu...>]

> Can we just put this program in the demos? Or at least just make it a
> separate target (make test-link)? It seems excessive to make this part
> of the default build path.

The whole purpose is to run this as part of the standard build, so
that the build fails if any driver is unloadable, (i.e. a modification
to it was botched) and the tree hopefully doesn't get pushed to
master.

You can test it separately by just running glxinfo/glxgears, obviously.

Re: [Mesa3d-dev] makedepend in Mesa

[Dan N. <dbn...@gm...>]

On Fri, Mar 19, 2010 at 12:23 PM, Xavier Chantry
<cha...@gm...> wrote:
> On Thu, Feb 25, 2010 at 9:41 PM, Dan Nicholson <dbn...@gm...> wrote:
>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 485836a..a582337 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -28,8 +28,11 @@ AC_PROG_CPP
>>>  AC_PROG_CC
>>>  AC_PROG_CXX
>>>  AC_CHECK_PROGS([MAKE], [gmake make])
>>> -AC_PATH_PROG([MKDEP], [makedepend])
>>>  AC_PATH_PROG([SED], [sed])
>>> +AC_PATH_PROG([MKDEP], [makedepend], no)
>>> +if test "x$MKDEP" = xno; then
>>> +    AC_MSG_ERROR([makedepend not found])
>>> +fi
>>
>> Yep, that would do it. In fact, when I wrote configure.ac originally,
>> I wanted it to be a hard requirement and assumed that AC_PATH_PROG
>> would error by default if it didn't find the program.
>>
>
> Should I resubmit a proper git patch ?

Sure.

> I have been running with makedepend installed on my 3 systems for 1
> month, it has worked very well. I don't think I got ONE weird failure
> in the past month, while I used to get more than once per week.
> The only thing I need is to sometimes run autogen.sh and/or configure,
> when there are some structure changes (e.g. nv30-nv40 merge to nvfx).
> AFAIK this is also handled automatically in other projects. But this
> is much less annoying, because it fails at build time, instead of
> segfaulting at runtime.

Yeah, automatic autotools updates could maybe be handled in the
top-level Makefile, but really that's more of a job that automake
takes care of.

> Everyone complains about mesa crappy build system so I thought all the
> failures I got were expected. Now I see they weren't, just that
> makedepend is badly required :)
>
> I am just worried some people might run into the same troubles as me.
> But I wonder if there are any since only Dan answered in that thread.

The only drawback I know of is adding a hard requirement on makedepend
where there wasn't one before, but distros usually have it.

--
Dan

Re: [Mesa3d-dev] [PATCH] dri: test whether the built drivers have unresolved symbols

[Dan N. <dbn...@gm...>]

On Fri, Mar 19, 2010 at 12:56 PM, Luca Barbieri <lu...@lu...> wrote:
> How about applying this?
>
> It should prevent introducing regressions similar to ones that
> happened in the past, with very little downside.

Can we just put this program in the demos? Or at least just make it a
separate target (make test-link)? It seems excessive to make this part
of the default build path.

--
Dan

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

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

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

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 ?

There are some patches (mostly one-liners) at the start of the branch
on other code, please take a look and object.

regards,
George.

Re: [Mesa3d-dev] [PATCH] dri: test whether the built drivers have unresolved symbols

[Luca B. <lu...@lu...>]

How about applying this?

It should prevent introducing regressions similar to ones that
happened in the past, with very little downside.

Re: [Mesa3d-dev] makedepend in Mesa

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

On Thu, Feb 25, 2010 at 9:41 PM, Dan Nicholson <dbn...@gm...> wrote:
>
>> diff --git a/configure.ac b/configure.ac
>> index 485836a..a582337 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -28,8 +28,11 @@ AC_PROG_CPP
>>  AC_PROG_CC
>>  AC_PROG_CXX
>>  AC_CHECK_PROGS([MAKE], [gmake make])
>> -AC_PATH_PROG([MKDEP], [makedepend])
>>  AC_PATH_PROG([SED], [sed])
>> +AC_PATH_PROG([MKDEP], [makedepend], no)
>> +if test "x$MKDEP" = xno; then
>> +    AC_MSG_ERROR([makedepend not found])
>> +fi
>
> Yep, that would do it. In fact, when I wrote configure.ac originally,
> I wanted it to be a hard requirement and assumed that AC_PATH_PROG
> would error by default if it didn't find the program.
>

Should I resubmit a proper git patch ?

I have been running with makedepend installed on my 3 systems for 1
month, it has worked very well. I don't think I got ONE weird failure
in the past month, while I used to get more than once per week.
The only thing I need is to sometimes run autogen.sh and/or configure,
when there are some structure changes (e.g. nv30-nv40 merge to nvfx).
AFAIK this is also handled automatically in other projects. But this
is much less annoying, because it fails at build time, instead of
segfaulting at runtime.

Everyone complains about mesa crappy build system so I thought all the
failures I got were expected. Now I see they weren't, just that
makedepend is badly required :)

I am just worried some people might run into the same troubles as me.
But I wonder if there are any since only Dan answered in that thread.

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

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

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

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.

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.

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.

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

iEYEARECAAYFAkujw1sACgkQX1gOwKyEAw/iSgCaA37aTDav/amZkxuxq89d+hJm
P1MAn0dy99VSRTivgUURnCR3klnH/PSt
=DrqD
-----END PGP SIGNATURE-----

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

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

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

This would probably be best solved by merging libdrm into the Linux kernel tree.
Ingo Molnar's rationale for having tools/perf in the kernel tree
applies even more in this case.

Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT

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

Hi Marek - "you are nominated for the next DRIgeller (Uri Geller)" :-)

concerning my problems r300g dri/st with mesa master GIT:

THE BAD:
commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19
Author: Dave Airlie <ai...@re...>
r300g: rebuild screen/winsys interface

THE GOOD:
commit a899c5a76ee056e237b19d97afaadd84bca9649f
Author: Ben Skeggs <bs...@re...>
nv50: reset vbo_fifo before each validate

THE UGLY:
???

Kind Regards,
- Sedat -


On Fri, Mar 19, 2010 at 2:21 PM, Marek Olšák <ma...@gm...> wrote:
> On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek <sed...@go...>
> wrote:
>>
>> Hi,
>>
>> the last days I was testing Alex Deucher's power-management-2 patches
>> for radeon OSS driver.
>>
>> While testing I saw that especially r300g dri/statetracker with
>> OpenArena have problems with mesa 7.8/master GIT branch.
>> Mesa r300 "classic" (KMS/DRI2) is working fine here on RV515.
>>
>> 7.8 GIT:
>> Scenes have a "red-ish" background.
>> There should be a fix in master.
>> But I can't remember when and which patch fixed it, but Dave Airlied
>> noticed the same color corruptions.
>
> Apply this one from master:
> 821c830f11fc1c3529a186ace1d1ba3ddeab4957
> If it helps, someone could cherry-pick the commit to the 7.8 branch.
>
>>
>> master GIT (merged gallium-st-api-dri into it):
>> Some objects in the scene are not displayed with correct colors -
>> objects look/have like turquoise and black triangles.
>
> What levels have this issue? How can I reproduce it?
> There is a breakage with Dave's screen/winsys rework
> (68e58a96e80865878e6881dc4d34fcc3ec24eb19), especially in these piglit
> tests: cubemap, gen-teximage, levelclamp, lodclamp, texredefine.
> Could you please check if the incorrect rendering in openarena has anything
> to do with the rework?
>
> -Marek
>
>>
>> commit 8e1768cfd32a4fa47dd5d4e8f5434fafc3b3120
>> "gallium/docs: Fix a couple ReST errors."
>>
>> I played a bit with glxinfo (output see file-attachment):
>>
>> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa glxinfo > glxinfo.txt
>>
>> The log of OA got big (dunno if you are interested in):
>>
>> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa openarena
>> 2>openarena.log
>>
>> Any hints for digging deeper into this?
>>
>> Kind Regards,
>> - 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
>>
>
>

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

[Bridgman, J. <Joh...@am...>]

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 ?

-----Original Message-----
From: xor...@li... [mailto:xor...@li...] On Behalf Of Nicolai Haehnle
Sent: Friday, March 19, 2010 1:26 PM
To: Luc Verhaegen
Cc: dri...@li...; mes...@li...; xo...@li...
Subject: Re: [Mesa3d-dev] DRI SDK and modularized drivers.

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.

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

cu,
Nicolai
_______________________________________________
xo...@li...: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT

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

Hi Marek,

indeed the patch you recommended is fixing the red-ish effect with
mesa 7.8 GIT branch!

r300g: remove hacks from translate_vertex_data_swizzle
"commit	821c830f11fc1c3529a186ace1d1ba3ddeab4957"

Feel free to apply to 7.8 GIT.

IIRC with Dave's screen/winsys rework I had no problems, but will test
later (maybe at weekend).

Kind Regards,
- Sedat -

sd@seduxbox:~/src/anholt_oa-benchmark$ openarena +exec anholt 2>&1 |
egrep -e '[0-9]+ frames'
840 frames 33.0 seconds 25.5 fps 12.0/39.3/82.0/11.7 ms

[build.log]
...
+ git checkout -b 7.8 origin/7.8
Switched to a new branch '7.8'
Branch 7.8 set up to track remote branch 7.8 from origin.
+ git log --pretty=short -1
+ cat
commit 73060ec7ebaa6a304402caa60610f94dac2cf24b
Author: Brian Paul <br...@vm...>

    drivers/x11: add PUBLIC qualifier to more API functions
+ PATCH=r300g-remove-hacks-from-translate_vertex_data_swizzle.patch
+ patch -Np1 -i
../patches/r300g-remove-hacks-from-translate_vertex_data_swizzle.patch
patching file src/gallium/drivers/r300/r300_state_inlines.h
+ ./autogen.sh --prefix=/usr --with-driver=dri
--with-dri-driverdir=/usr/lib/dri --with-dri-drivers=r300,swrast
--enable-gallium-radeon --with-state-trackers=dri,glx --enable-debug
--enable-glx-tls
...

On Fri, Mar 19, 2010 at 2:21 PM, Marek Olšák <ma...@gm...> wrote:
> On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek <sed...@go...>
> wrote:
>>
>> Hi,
>>
>> the last days I was testing Alex Deucher's power-management-2 patches
>> for radeon OSS driver.
>>
>> While testing I saw that especially r300g dri/statetracker with
>> OpenArena have problems with mesa 7.8/master GIT branch.
>> Mesa r300 "classic" (KMS/DRI2) is working fine here on RV515.
>>
>> 7.8 GIT:
>> Scenes have a "red-ish" background.
>> There should be a fix in master.
>> But I can't remember when and which patch fixed it, but Dave Airlied
>> noticed the same color corruptions.
>
> Apply this one from master:
> 821c830f11fc1c3529a186ace1d1ba3ddeab4957
> If it helps, someone could cherry-pick the commit to the 7.8 branch.
>
>>
>> master GIT (merged gallium-st-api-dri into it):
>> Some objects in the scene are not displayed with correct colors -
>> objects look/have like turquoise and black triangles.
>
> What levels have this issue? How can I reproduce it?
> There is a breakage with Dave's screen/winsys rework
> (68e58a96e80865878e6881dc4d34fcc3ec24eb19), especially in these piglit
> tests: cubemap, gen-teximage, levelclamp, lodclamp, texredefine.
> Could you please check if the incorrect rendering in openarena has anything
> to do with the rework?
>
> -Marek
>
>>
>> commit 8e1768cfd32a4fa47dd5d4e8f5434fafc3b3120
>> "gallium/docs: Fix a couple ReST errors."
>>
>> I played a bit with glxinfo (output see file-attachment):
>>
>> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa glxinfo > glxinfo.txt
>>
>> The log of OA got big (dunno if you are interested in):
>>
>> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa openarena
>> 2>openarena.log
>>
>> Any hints for digging deeper into this?
>>
>> Kind Regards,
>> - 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
>>
>
>

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

[Nicolai H. <nha...@gm...>]

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.

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

cu,
Nicolai

Re: [Mesa3d-dev] [PATCH] Export glXGPA symbols

[Brian P. <br...@vm...>]

tom fogal wrote:
> They seem to have become hidden with the visibility changes, at least
> --with-driver=xlib.

Your patch doesn't apply cleanly for me but I'll do it by hand.

It looks like there's some other functions also lacking "PUBLIC". 
I'll fix those too.

-Brian

[Mesa3d-dev] [Bug 27189] mesa 7.7 fails to compile xorg_crtc.c:238 : error

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

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


Jakob Bornecrantz <wal...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Jakob Bornecrantz <wal...@gm...>  2010-03-19 08:07:01 PST ---
This has been fixed the 7.7 branch and the fix will be included in the 7.7.1
release about to go out soon. It should also be in 7.7.1-rc1.


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

Re: [Mesa3d-dev] [PATCH] Fix compile error caused by missing include dir

[Brian P. <br...@vm...>]

Johannes Obermayr wrote:
>> Please apply this patch.
>>
>> Otherwise st:es has a compile error in st_es2.c!
>>
>> Thanks.
>> Johannes
> Ping
> 
> If you do not believe try compiling it on a fresh machine like OBS.
> 
> Include flow:
> src/gallium/state_trackers/es/st_es2.c -> src/mesa/state_tracker/st_manager.h -> src/mesa/state_tracker/st_context.h -> src/mesa/main/mtypes.h -> src/mesa/main/glheader.h
> 
> src/mesa/main/glheader.h cannot find:
> 
> #include "GL/gl.h"
> #include "GL/glext.h"
> #include "GL/internal/glcore.h"
> 
> With the patch it can ...
> 
> And Mesa/Gallium should always be in a compilable state, shouldn't it?

I'm committing the fix now.  Sorry for the slow reply.

-Brian

Re: [Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT

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

On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek <sed...@go...>wrote:

> Hi,
>
> the last days I was testing Alex Deucher's power-management-2 patches
> for radeon OSS driver.
>
> While testing I saw that especially r300g dri/statetracker with
> OpenArena have problems with mesa 7.8/master GIT branch.
> Mesa r300 "classic" (KMS/DRI2) is working fine here on RV515.
>
> 7.8 GIT:
> Scenes have a "red-ish" background.
> There should be a fix in master.
> But I can't remember when and which patch fixed it, but Dave Airlied
> noticed the same color corruptions.
>

Apply this one from master:
821c830f11fc1c3529a186ace1d1ba3ddeab4957<http://cgit.freedesktop.org/mesa/mesa/commit/?id=821c830f11fc1c3529a186ace1d1ba3ddeab4957>
If it helps, someone could cherry-pick the commit to the 7.8 branch.


> master GIT (merged gallium-st-api-dri into it):
> Some objects in the scene are not displayed with correct colors -
> objects look/have like turquoise and black triangles.
>

What levels have this issue? How can I reproduce it?
There is a breakage with Dave's screen/winsys rework (
68e58a96e80865878e6881dc4d34fcc3ec24eb19<http://cgit.freedesktop.org/mesa/mesa/commit/?id=68e58a96e80865878e6881dc4d34fcc3ec24eb19>),
especially in these piglit tests: cubemap, gen-teximage, levelclamp,
lodclamp, texredefine.
Could you please check if the incorrect rendering in openarena has anything
to do with the rework?

-Marek


> commit 8e1768cfd32a4fa47dd5d4e8f5434fafc3b3120
> "gallium/docs: Fix a couple ReST errors."
>
> I played a bit with glxinfo (output see file-attachment):
>
> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa glxinfo > glxinfo.txt
>
> The log of OA got big (dunno if you are interested in):
>
> $ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa openarena
> 2>openarena.log
>
> Any hints for digging deeper into this?
>
> Kind Regards,
> - 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
>
>

Re: [Mesa3d-dev] [PATCH] Fix compile error caused by missing include dir

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

>Please apply this patch.
>
>Otherwise st:es has a compile error in st_es2.c!
>
>Thanks.
>Johannes
Ping

If you do not believe try compiling it on a fresh machine like OBS.

Include flow:
src/gallium/state_trackers/es/st_es2.c -> src/mesa/state_tracker/st_manager.h -> src/mesa/state_tracker/st_context.h -> src/mesa/main/mtypes.h -> src/mesa/main/glheader.h

src/mesa/main/glheader.h cannot find:

#include "GL/gl.h"
#include "GL/glext.h"
#include "GL/internal/glcore.h"

With the patch it can ...

And Mesa/Gallium should always be in a compilable state, shouldn't it?

Thanks.
Johannes

[Mesa3d-dev] [mesa] r300g dri/st: OpenArena corruptions with mesa-7.8 and master GIT

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

Hi,

the last days I was testing Alex Deucher's power-management-2 patches
for radeon OSS driver.

While testing I saw that especially r300g dri/statetracker with
OpenArena have problems with mesa 7.8/master GIT branch.
Mesa r300 "classic" (KMS/DRI2) is working fine here on RV515.

7.8 GIT:
Scenes have a "red-ish" background.
There should be a fix in master.
But I can't remember when and which patch fixed it, but Dave Airlied
noticed the same color corruptions.

master GIT (merged gallium-st-api-dri into it):
Some objects in the scene are not displayed with correct colors -
objects look/have like turquoise and black triangles.

commit 8e1768cfd32a4fa47dd5d4e8f5434fafc3b3120
"gallium/docs: Fix a couple ReST errors."

I played a bit with glxinfo (output see file-attachment):

$ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa glxinfo > glxinfo.txt

The log of OA got big (dunno if you are interested in):

$ LIBGL_DEBUG=verbose RADEON_DEBUG=all ST_DEBUG=mesa openarena 2>openarena.log

Any hints for digging deeper into this?

Kind Regards,
- Sedat -

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Tom S. <tst...@gm...>]

On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
> 
> If you're not sure how the actual video card works,
> http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a
> great starting point. Of particular interest is the 3D engine; r300g
> only talks to the 3D part of the video card.
> 
> The reference Gallium driver is probably identity, although softpipe
> is a good reference as well. We also have documentation for the
> Gallium API and associated bits; if you don't want to build it
> yourself from the Mesa tree, there should be an up-to-date copy at
> http://people.freedesktop.org/~csimpson/gallium-docs/. (If there's a
> problem with the documentation, lemme know!)
>

Thanks for the info.  I'll start taking a look at that.

What is the correct way to install the Gallium driver?  Up until now,
after running make install, I have been symlinking radeong_dri.so
to r300_dri.so.  Is this still the way to do it?

I am currently blocked from using KMS and thus testing the Gallium driver
by this bug: https://bugs.freedesktop.org/show_bug.cgi?id=25662 I think it
is a problem with the kernel, because my entire system locks up and I am
forced to hard reboot.  Debugging this problem is probably a good way for
me to get familiar with the code.  Any tips to help me debug this problem?

-Tom Stellard

[Mesa3d-dev] [Bug 27189] mesa 7.7 fails to compile xorg_crtc.c:238 : error

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

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





--- Comment #2 from oneforall <one...@gm...>  2010-03-18 22:35:48 PST ---
err that 2nd one doesn't do what you think again :(


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

[Mesa3d-dev] [Bug 27189] mesa 7.7 fails to compile xorg_crtc.c:238 : error

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

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





--- Comment #1 from oneforall <one...@gm...>  2010-03-18 22:33:33 PST ---
ah I finally found the patch 
http://cgit.freedesktop.org/mesa/mesa/commit/?id=8db8adfd01a1ff1e2a160ae3b0199bd3daa4191a

althou I have a hard time of figuring out how to download them with out
renaming them :) 

here too
http://hg.geexbox.org/geexbox/file/ca217311db09/packages/mesa/patches/110_fix-libkms-api.diff


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

[Mesa3d-dev] [Bug 27189] New: mesa 7.7 fails to compile xorg_crtc.c:238 : error

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

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

           Summary: mesa 7.7 fails to compile xorg_crtc.c:238 : error
           Product: Mesa
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: one...@gm...


Hi 
mesa 7.7. fails to compile
xorg_crtc.c: In function 'crtc_load_cursor_argb_kms':
xorg_crtc.c:238: err...@gi...: 'KMS_BO_TYPE_CURSOR' undeclared
(first use in this function)
xorg_crtc.c:238: error: (Each undeclared identifier is reported only once
xorg_crtc.c:238: error: for each function it appears in.)
gmake[4]: *** [xorg_crtc.o] Error 1
gmake[4]: *** Waiting for unfinished jobs....
xorg_driver.c: In function 'drv_destroy_front_buffer_kms':
xorg_driver.c:916: warning: unused variable 'rootPixmap'
xorg_driver.c: In function 'drv_create_front_buffer_kms':
xorg_driver.c:936: error: 'KMS_BO_TYPE_SCANOUT' undeclared (first use in this
function)
xorg_driver.c:936: error: (Each undeclared identifier is reported only once
xorg_driver.c:936: error: for each function it appears in.)


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

[Mesa3d-dev] [Bug 23884] Unigine Tropics demo requires GL_ARB_half_float_vertex

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

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


Gordon Jin <gor...@in...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t....@ma...




--- Comment #8 from Gordon Jin <gor...@in...>  2010-03-18 19:19:36 PST ---
*** Bug 27161 has been marked as a duplicate of this bug. ***


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