headers
Roland Scheidegger | 1 Oct 2004 01:25
Picon

Re: Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

Eric Anholt wrote:
>> Log message: OK, one more time.  Simplify the state-backup system
>> by just storing the full state in a ready-to-emit cmdbuf, which
>> avoids the issue Nicolai Haehnle reported where the check() could
>> return differently during backup-and-emit than it should have if it
>> were called at the right time.  Move the lit emission before most
>> of the TCL state emission on r200, which fixes neverball issues.
>> 
>> Tested with:	r100/r200 with neverball, tuxracer, chromium, quake3,
>> ipers
> 
> 
> There may still be some race for neverball.  I say "may" because I
> doing my normal dance on the intro screen (a round of wiggling the
> mouse over the menus, a round of pounding on the keyboard in a
> separate window) and I might have seen a flicker.  I'm just not sure.
> 
> 
> I did test ut2k4demo on the r200.  It worked fine for quite some time
>  and then hung.  I didn't have a baseline for its stability, since
> it's so unusably slow, so I'm not sure what to do about that one.
If you have a "real" r200, then you probably got hit by the shock rifle
lockup - https://freedesktop.org/bugzilla/show_bug.cgi?id=814 and 
https://freedesktop.org/bugzilla/show_bug.cgi?id=729.

 > Mesa just complained loudly with r100 and ut2k4demo.
That's interesting, I thought that worked? Not too sure about it though.

> If you've had new issues with r200 in the last week, please retest
> with current CVS and poke me (hard) if there are still problems.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 Oct 2004 06:40
Picon
Favicon

Mesa solo should work again..


Okay I've just checked a fix in for miniglx.c that makes solo work for me
again, the __glXGetDrawableInfo wasn't setting up the index and stamp
correctly at all, I think the fix is correct I sneakily look into the
sarea and grab the latest stamp and use it....

Dave.

btw Fix was payed for by Stargames Australia - we actually use Solo in one
of our projects....

--

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Permalink | Reply | 4 comments |
headers
Jon Smirl | 1 Oct 2004 07:29
Picon
Gravatar

Re: Mesa solo should work again..

Wow, that might be the first paid piece of work on solo. I think
Tungsten was trying to sell it when it was first created as an
embedded platform but I'm not sure they got any customers.

I'll go back to working on solo as soon as DRM is straightened out.
Meanwhile I'm hoping Ian will get his new memory manager finished.

On Fri, 1 Oct 2004 05:40:11 +0100 (IST), Dave Airlie <airlied <at> linux.ie> wrote:
> 
> Okay I've just checked a fix in for miniglx.c that makes solo work for me
> again, the __glXGetDrawableInfo wasn't setting up the index and stamp
> correctly at all, I think the fix is correct I sneakily look into the
> sarea and grab the latest stamp and use it....
> 
> Dave.
> 
> btw Fix was payed for by Stargames Australia - we actually use Solo in one
> of our projects....
> 
> --
> David Airlie, Software Engineer
> http://www.skynet.ie/~airlied / airlied at skynet.ie
> pam_smb / Linux DECstation / Linux VAX / ILUG person
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
(Continue reading)

Permalink | Reply | 3 comments |
headers
Keith Whitwell | 1 Oct 2004 10:58
Picon
Favicon

Re: Mesa solo should work again..

Jon Smirl wrote:
> Wow, that might be the first paid piece of work on solo.

Like much of our work, mesa-solo was a paid engineering project for a client 
with a specific requirement.  So, the development was fully funded, though 
performed & presented in open source.  Since then the code appears to have 
been taken up by a number of additional commercial projects - which is nice to 
see.

The project was inspired by an earlier work (fbdri) which was also developed 
as a commercial project, though didn't have anything to to with TG.

> I think
> Tungsten was trying to sell it when it was first created as an
> embedded platform.

Not really - once Khronos finalized GLES, there wasn't any need for the 
subsetted-GL aspects of the Mesa-embedded branches.  The combination of kdrive 
(or maybe QT/embedded???) and GLES is pretty much the sweet spot for embedded 
platforms at the moment & the foreseeable future, and anyone serious about 
constrained environments like phones or pdas with 3d capabilities is going 
this route.  Khronos took absolutely ages finalizing GLES, but they seem to 
have hit a winner.

The DRI-without-X platform with the toy servers appears to have captured some 
mind share as well.  Running an X server isn't nearly as resource-consuming as 
people have convinced themselves it is, but there are occasions where there 
are good reasons not to want X hanging around in the background (X-on-GL would 
be one).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Whitwell | 1 Oct 2004 11:44
Picon
Favicon

Re: Mesa solo should work again..

Keith Whitwell wrote:
> Jon Smirl wrote:
> 
>> Wow, that might be the first paid piece of work on solo.
> 
> 
> Like much of our work, mesa-solo was a paid engineering project for a 
> client with a specific requirement.  So, the development was fully 
> funded, though performed & presented in open source.  Since then the 
> code appears to have been taken up by a number of additional commercial 
> projects - which is nice to see.
> 
> The project was inspired by an earlier work (fbdri) which was also 
> developed as a commercial project, though didn't have anything to to 
> with TG.
> 
>> I think
>> Tungsten was trying to sell it when it was first created as an
>> embedded platform.
> 
> 
> Not really - once Khronos finalized GLES, there wasn't any need for the 
> subsetted-GL aspects of the Mesa-embedded branches.  The combination of 
> kdrive (or maybe QT/embedded???) and GLES is pretty much the sweet spot 
> for embedded platforms at the moment & the foreseeable future, and 
> anyone serious about constrained environments like phones or pdas with 
> 3d capabilities is going this route.  Khronos took absolutely ages 
> finalizing GLES, but they seem to have hit a winner.

Oh, I should point out that TG does do both GLES consultancy and will continue
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Airlie | 1 Oct 2004 14:27
Picon
Favicon

Re: Mesa solo should work again..


>
> The DRI-without-X platform with the toy servers appears to have captured some
> mind share as well.  Running an X server isn't nearly as resource-consuming as
> people have convinced themselves it is, but there are occasions where there
> are good reasons not to want X hanging around in the background (X-on-GL would
> be one).

Well that's why I went with solo for my project, I have a single
fullscreen 3d app, just removing the X build from my build process saved
me a lot of time :-) and a lot of time slimming X down..... my "embedded"
system is a PIII 500 with Radeon M7 and > 256MB of RAM.. so resources
aren't my major issue :-)

I'll probably get some paid time to fix up solo on the i810 and maybe i8x0
chips at some stage depending on my workload...

Dave.

--

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Scheidegger | 1 Oct 2004 15:57
Picon

Re: Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

Eric Anholt wrote:
> On Wed, 2004-09-29 at 17:08, Eric Anholt wrote:
> 
>>CVSROOT:	/cvs/mesa
>>Module name:	Mesa
>>Repository:	Mesa/src/mesa/drivers/dri/r200/
>>Changes by:	anholt <at> gabe.	04/09/29 17:08:06
>>
>>Log message:
>>  OK, one more time.  Simplify the state-backup system by just storing the full
>>  state in a ready-to-emit cmdbuf, which avoids the issue Nicolai Haehnle reported
>>  where the check() could return differently during backup-and-emit than it should
>>  have if it were called at the right time.  Move the lit emission before most of
>>  the TCL state emission on r200, which fixes neverball issues.
>>  
>>  Tested with:	r100/r200 with neverball, tuxracer, chromium, quake3, ipers
> If you've had new issues with r200 in the last week, please retest with
> current CVS and poke me (hard) if there are still problems.

Actually, that new code doesn't work for me at all (at least I think 
that those changes are causing that behaviour, and not other cvs 
commits). I get an instant lockup if _any_ 3d app is started (even 
gears). I did not notice this previously because I did not restart X, 
simply copied r200_dri.so over the old one (with --remove-destination so 
X/KDE continued using the old one), in this case this does not happen.

Roland

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Anholt | 2 Oct 2004 01:03

Re: Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)

On Fri, 2004-10-01 at 06:57, Roland Scheidegger wrote:
> Eric Anholt wrote:
> > On Wed, 2004-09-29 at 17:08, Eric Anholt wrote:
> > 
> >>CVSROOT:	/cvs/mesa
> >>Module name:	Mesa
> >>Repository:	Mesa/src/mesa/drivers/dri/r200/
> >>Changes by:	anholt <at> gabe.	04/09/29 17:08:06
> >>
> >>Log message:
> >>  OK, one more time.  Simplify the state-backup system by just storing the full
> >>  state in a ready-to-emit cmdbuf, which avoids the issue Nicolai Haehnle reported
> >>  where the check() could return differently during backup-and-emit than it should
> >>  have if it were called at the right time.  Move the lit emission before most of
> >>  the TCL state emission on r200, which fixes neverball issues.
> >>  
> >>  Tested with:	r100/r200 with neverball, tuxracer, chromium, quake3, ipers
> > If you've had new issues with r200 in the last week, please retest with
> > current CVS and poke me (hard) if there are still problems.
> 
> Actually, that new code doesn't work for me at all (at least I think 
> that those changes are causing that behaviour, and not other cvs 
> commits). I get an instant lockup if _any_ 3d app is started (even 
> gears). I did not notice this previously because I did not restart X, 
> simply copied r200_dri.so over the old one (with --remove-destination so 
> X/KDE continued using the old one), in this case this does not happen.

What card did you have again?  And does moving the lit emit back where
it was change things?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Paul | 2 Oct 2004 17:39

Mesa branches


I've released 6.2 and created a new branch (mesa_6_2_branch) for bug 
fixes.  This might eventually lead to a 6.2.1 release.

The trunk is now open for new development.  I'll be checking in some 
new stuff soon.

-Brian

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Permalink | Reply | 0 comments |
headers
Brian Paul | 2 Oct 2004 18:42

GL_ARB_draw_buffers and fragment program grammar


I've checked in most of the code for the GL_ARB_draw_buffers 
extension.  One part that's incomplete is the GL_ARB_fragment_program 
updates.  Basically, the 'result.color' syntax is supposed to be 
extended to support 'result.color[n]' where n is 0, 1, 2, etc.

Michał, could you make this update, or could you explain how it's 
supposed to be done?  I took a quick look at the grammar/parser code 
but wasn't sure what to do.

For now, GL_MAX_DRAW_BUFFERS_ARB is 1.  I'll have to update the 
software rasterizer to support more.

-Brian

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Permalink | Reply | 0 comments |

Gmane