[Dri-devel] valgrinding DRI..

[Dave Airlie]

I'm trying to valgrind my application and in the process DRI :-),

However I can't get over the Mesa MMX checks, is there any env variable I
can set so Mesa doesn't do all the stuff that requires SIGFPE and I can
force it to use a certain type of instruction set?

I've been just setting ALWAYS_INDIRECT for now but that doesn't find any
issues in my DRI driver (not that I think there are any but it never hurts
to look)...

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: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 967] fix missing symbol xf86ReadMmio32 for alpha platforms

[bugzilla-daemon]

Please do not reply to this email: if you want to comment on the bug, go to   
the URL shown below and enter your comments there.  
 
http://bugs.xfree86.org/show_bug.cgi?id=967   
   




--- Additional Comments From [EMAIL PROTECTED]  2003-12-10 20:15 ---
Don't use the compiler.h patch. It's not right. Try the previous one though.   
   
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 967] fix missing symbol xf86ReadMmio32 for alpha platforms

[bugzilla-daemon]

Please do not reply to this email: if you want to comment on the bug, go to   
the URL shown below and enter your comments there.  
 
http://bugs.xfree86.org/show_bug.cgi?id=967   
   

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Attachment #896 is|0   |1
   obsolete||


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


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 967] fix missing symbol xf86ReadMmio32 for alpha platforms

[bugzilla-daemon]

Please do not reply to this email: if you want to comment on the bug, go to   
the URL shown below and enter your comments there.  
 
http://bugs.xfree86.org/show_bug.cgi?id=967   
   




--- Additional Comments From [EMAIL PROTECTED]  2003-12-10 20:07 ---
Created an attachment (id=896)
 --> (http://bugs.xfree86.org/attachment.cgi?id=896&action=view)
Redefine xf86ReadMmio32() on alpha platforms

Actually, this is the one I'm thinking of committing, so if you could try this
too, but you'll need to reverse the r200.patch I've just submitted.   
   
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 967] fix missing symbol xf86ReadMmio32 for alpha platforms

[bugzilla-daemon]

Please do not reply to this email: if you want to comment on the bug, go to   
the URL shown below and enter your comments there.  
 
http://bugs.xfree86.org/show_bug.cgi?id=967   
   




--- Additional Comments From [EMAIL PROTECTED]  2003-12-10 19:56 ---
Created an attachment (id=895)
 --> (http://bugs.xfree86.org/attachment.cgi?id=895&action=view)
Define xf86ReadMmio32 for __alpha__

Reverse your patch and try this instead. Let me know as soon as you can, and
then we'll be able to get this (in some form) into the 4.4 release.   
   
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI newmesa merge

[David D. Hagood]

Martin Spott wrote:

You would sync manually and not every time you call 'make',


Whether you sync'ed every time or not would depend upon the way the make 
rule was written - if the rule is tied to the existance of the 
directory, then the pull would happen the first time only.

---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] [Bug 967] fix missing symbol xf86ReadMmio32 for alpha platforms

[bugzilla-daemon]

Please do not reply to this email: if you want to comment on the bug, go to   
the URL shown below and enter your comments there.  
 
http://bugs.xfree86.org/show_bug.cgi?id=967   
   

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]  |dri-
   ||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2003-12-10 18:40 ---
This will break the Radeon drivers horribly with current 2D driver and DRM from
DRI CVS. You really need to get register reads working somehow in the 3D drivers.  
 
   
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email   
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Prosavage vblank

[steve]

Are there any plans for the Savage drivers to support the VBLANK IOCTLs 
in the near future?

Thanks.

-- 

 - Steve http://www.nexusuk.org/

*** Presented in DoubleVision (Where Drunk) - Futurama ***



---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] driver comparison

[Dieter Nützel]

Am Montag, 20. Oktober 2003 23:31 schrieb Keith Whitwell:
> Ian Romanick wrote:
> > Roland Scheidegger wrote:
> >> Slightly OT, but here's an article comparing XiG Summit, dri cvs and
> >> the ATI driver on a radeon 9000pro.
> >> http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oc
> >>t03.html
> >>
> >>
> >> And to get this fully on-topic, is there a specific reason why the dri
> >> driver is quite a bit slower (up to 50% in some subtests) in
> >> SpecViewPerf compared to the cvs version of july? Could this be
> >> related to the changes with GLX_NV_vertex_array_range,
> >> GLX_MESA_agp_offset, GLX_MESA_allocate_memory (the only extensions
> >> which changed in that timeframe) or must this be something else?
> >
> > It is probably because some code paths were disabled in the r200 driver
> > due to serious bugs.  This bugs prevented UT 2k3 from running at all.
>
> The problem is (probably) due to excessive flushing introduced by the
> changes Ian referenced.  I had time to put together a patch, but at that
> point was having real issues getting CVS to compile.  These are probably at
> my end, but before they were resolved I got sidetracked again.
>
> I've attached the patch if someone wants to run with it in the meantime. 
> It hasn't been tested at all.

GREAT work Keith!

This one brought "old" performance (VTK -> TimeRenderer|2) (nearly) back.
Haven't had time to test it before but found it in the trunk, now.

Greetings,
Dieter

BTW Couldn't test "ipers" etc. 'cause SuSE 9.0 do NOT let me compile MesaCVS 
with shared libs (libtool)...;-(

-- 
Dieter Nützel
@home: 


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] MGA font corruption revisited - now reproducible

[Ryan Underwood]

On Wed, Dec 10, 2003 at 12:25:36PM -0600, Ryan Underwood wrote:
>
> In an open software architecture like the DRI, we should do our best to
> support proprietary vendors when they give us the means to do so, but
> all the pissing and moaning about what they will and won't do should go
> either to /dev/null or, more productively, towards opencores.org and a
> fully open windowing accelerator and programmable 3D graphics pipeline
> core.

I forgot one other place the pissing and moaning can go to: the sales
department of all the vendors *except* the one you either are about to
buy a new graphics card from, or have just bought one from.  Hopefully
letting them know that their silliness is hitting them in the bankbook
might cause them to mention such things as Linux to managers and
shareholders, which might give those the crazy idea that allocating more
resources towards providing better support for open source developers
just might help them sell more video cards in the end.

Lots of 'might' in that paragraph.. well, it doesn't cost much to fire
off an email or make a phone call anyhow.  Perhaps consider it like
playing the lottery.  $1 here, $1 there doesn't hurt anybody.  The
difference in this lottery is that if anyone wins, we all win.

-- 
Ryan Underwood, <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: [Dri-devel] DRI newmesa merge

[Martin Spott]

"David D. Hagood" <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:

>> It would be annoying for people with dialup connections if make required
>> access to a remote CVS repository.

> And how would that be any different than syncing up with the main DRI 
> CVS repo? If you are building one from CVS, you may as well get the 
> other from CVS as well.

You would sync manually and not every time you call 'make',

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] patch: against some typos in radeon driver

[Dieter Nützel]

Am Mittwoch, 10. Dezember 2003 20:13 schrieb Alan Hourihane:
> On Wed, Dec 10, 2003 at 06:37:29PM +0100, Dieter Nützel wrote:
> > Am Mittwoch, 10. Dezember 2003 15:12 schrieb Alan Hourihane:
> > > On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
> > > > Am Sonntag, 10. August 2003 9:39 schrieb  Andreas Stenglein:
> > > > > trivial...
> > > > > fixes some typos in the radeon driver
> > > > > ["r100_sanity_typo_patch1.txt" (text/x-patch)]
> > > > >
> > > > > diff -ru
> > > > > HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c \
> > > > > HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c ---
> > > > > HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c Wed Apr
> > > > > 30
> > > >
> > > > 03:50:52 \
> > > >
> > > > > 2003
> > > > > +++ HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c  Sun
> > > > > Aug 10
> > > >
> > > > 11:10:27 2003
> > > >
> > > > > @@ -170,7 +170,7 @@
> > > > >  RADEON_CP_VC_FRMT_ST0| \
> > > > >  RADEON_CP_VC_FRMT_ST1| \
> > > > >  RADEON_CP_VC_FRMT_N0)
> > > > > -#define TAG(x) x##_rgpa_spec_st_st_n
> > > > > +#define TAG(x) x##_rgba_spec_st_st_n
> > > > >  #include "radeon_maos_vbtmp.h"
> > > >
> > > > [-]
> > > >
> > > > It "applies" on radeon _and_ r200.
> > > > Is this _needed_?
> > > > I have rediffed it against trunk (radeon and r200).
> > >
> > > It's not strictly a problem - more of a typo.
> > >
> > > I've just committed it.
> >
> > Did you cover all this?
>
> In your original email I didn't see any patches.

There aren't any before 'cause Andreas was the "man" before...;-)

> > Maybe "radeon_sanity.c.diff" is wrong?
>
> I don't think so, and just committed it.

Thanks,
Dieter

-- 
Dieter Nützel
@home: 


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] patch: against some typos in radeon driver

[Alan Hourihane]

On Wed, Dec 10, 2003 at 06:37:29PM +0100, Dieter Nützel wrote:
> Am Mittwoch, 10. Dezember 2003 15:12 schrieb Alan Hourihane:
> > On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
> > > Am Sonntag, 10. August 2003 9:39 schrieb  Andreas Stenglein:
> > > > trivial...
> > > > fixes some typos in the radeon driver
> > > > ["r100_sanity_typo_patch1.txt" (text/x-patch)]
> > > >
> > > > diff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c \
> > > > HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c
> > > > --- HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c Wed Apr
> > > > 30
> > >
> > > 03:50:52 \
> > >
> > > > 2003
> > > > +++ HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c  Sun Aug
> > > > 10
> > >
> > > 11:10:27 2003
> > >
> > > > @@ -170,7 +170,7 @@
> > > >  RADEON_CP_VC_FRMT_ST0| \
> > > >  RADEON_CP_VC_FRMT_ST1| \
> > > >  RADEON_CP_VC_FRMT_N0)
> > > > -#define TAG(x) x##_rgpa_spec_st_st_n
> > > > +#define TAG(x) x##_rgba_spec_st_st_n
> > > >  #include "radeon_maos_vbtmp.h"
> > >
> > > [-]
> > >
> > > It "applies" on radeon _and_ r200.
> > > Is this _needed_?
> > > I have rediffed it against trunk (radeon and r200).
> >
> > It's not strictly a problem - more of a typo.
> >
> > I've just committed it.
> 
> Did you cover all this?

In your original email I didn't see any patches.

> Maybe "radeon_sanity.c.diff" is wrong?

I don't think so, and just committed it.

Alan.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] MGA font corruption revisited - now reproducible

[Ryan Underwood]

On Wed, Dec 10, 2003 at 08:52:03AM -0800, Linus Torvalds wrote:
>
> > Must be some new management over there... *sigh*
> 
> Never attribute to malice what can be sufficiently explained by
> laziness or stupidity.
  ^
Why do you think I mentioned "management"? :)

> But when it comes to old hardware that doesn't bring the company any
> revenue any more, the only reason to maintain documentation (even if the
> "maintenance" is just having people be aware of it, and making it
> available on a web-site and having the proper indexing to find it) is to
> show that you're committed to your products, so that people who buy the
> new ones can trust you.

It's unfortunate that while they still have the sales information and
white papers for their old chips up on their website, it's next to
impossible to get a human being that will even *entertain* your request
for documentation, much less grant it.  One would think that for old
hardware, supporting it by posting documentation and code would be
a bigger priority than maintaining product info for something they don't
even sell anymore?

> And a lot of companies don't seem to think that it's worth the pain.
> They'd rather screw their old customers over and try to get them to
> upgrade to the new product. Which works well enough, I guess, since it
> clearly is fairly rare to try to support your old stuff any longer than
> absolutely necessary.

I really wish it were possible to negotiate term limits on NDAs.
Unfortunately, even providing docs under NDA seems like an immense favor
nowadays.

> Major documentation policies usually only exist at the big old-time
> companies. For example, I could buy the "Technical Reference: Personal
> Computer AT" reference from IBM in 1991 - even though the thing was
> written in 1985. Because a company like IBM tends to have all these
> customers that really pay for _support_ more than new hardware. Their
> paying customer base literally cares about the fact that they know that
> they can get support and docs for hardware that may be quite old.

Too bad, really; in all honesty I'd pay for a support subscription for
my hardware because it's the hardware that fits my needs perfectly, and
changing any of it would simply be less economical than buying all new
stuff, not necessarily in terms of raw expense, but in terms of time
spent re-hacking all scripts, changing configurations, etc.  And too
frequently the shiny new hardware focuses on the whiz-bang features and
neglects things that you took for granted with the older stuff.

I think support subscriptions would be too much of a trickle effect to
bother with for old stuff, but we will probably see this in the future.
One of the reasons support was given as "part of the package" in the
past was because you had to convince people to buy into your market *at
all*, much less choose your particular product. (Who needs a 3D game
card, there aren't any worthwhile games around? - Me, 1996)
Now that market segments like the video card market have a clearly
defined inelastic demand component (the fanboys who rush out for a new
video card every 6 months), the companies that produce the cards
have less incentive to throw in things like support at no additional
cost.

> In contrast, think about the best customer base of a graphics card vendor
> for a moment. The best customers there are the ones that upgrade once a
> year, and if they throw away their old card in disgust because it no
> longer plays the newest games titles, all the better.

I think that's the "conspiracy theory" aspect of it.  It's hard to
explain otherwise why the company with a 5 year old product with a huge
install base won't even do its existing customers the perfectly
reasonable favor of posting a few PDF files on their website, or making
printed copies available for a reasonable fee.   I think they really do
want to disassociate themselves from any past products in the hopes
you'll just give up and upgrade.  And many people give in to the
coercion -- that's the advantage of having a support monopoly on your
product, after all.  You get to decide when your customers upgrade.
You only hope they upgrade to *your* product though, so you don't want
to start screwing them *too* soon into the previous product's life
cycle.

> I hope that will change. I _think_ it will change. But it's likely to
> change only when we get rid of the "new gfx card every six months"
> mentality.

That's probably not the key issue.  After all, most hardware is on an
evolutionary cycle now.  NVIDIA's new products add the latest whiz-bang
features to a core that's going on six years old now.  ATI's base
hardware is younger, but still an evolutionary approach is taken there
too.  Matrox has numerous products based on the design of the G400,
which was a step up from the G200 -- only recently did they feel it was
time to make the leap to a new architecture.  VIA/S3 chips haven't
changed much since the Virge days.  These aren't revolutionary

Re: [Dri-devel] patch: against some typos in radeon driver

[Dieter Nützel]

Am Mittwoch, 10. Dezember 2003 15:12 schrieb Alan Hourihane:
> On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
> > Am Sonntag, 10. August 2003 9:39 schrieb  Andreas Stenglein:
> > > trivial...
> > > fixes some typos in the radeon driver
> > > ["r100_sanity_typo_patch1.txt" (text/x-patch)]
> > >
> > > diff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c \
> > > HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c
> > > --- HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c Wed Apr
> > > 30
> >
> > 03:50:52 \
> >
> > > 2003
> > > +++ HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c  Sun Aug
> > > 10
> >
> > 11:10:27 2003
> >
> > > @@ -170,7 +170,7 @@
> > >  RADEON_CP_VC_FRMT_ST0| \
> > >  RADEON_CP_VC_FRMT_ST1| \
> > >  RADEON_CP_VC_FRMT_N0)
> > > -#define TAG(x) x##_rgpa_spec_st_st_n
> > > +#define TAG(x) x##_rgba_spec_st_st_n
> > >  #include "radeon_maos_vbtmp.h"
> >
> > [-]
> >
> > It "applies" on radeon _and_ r200.
> > Is this _needed_?
> > I have rediffed it against trunk (radeon and r200).
>
> It's not strictly a problem - more of a typo.
>
> I've just committed it.

Did you cover all this?
Maybe "radeon_sanity.c.diff" is wrong?

Thanks,
Dieter

-- 
Dieter Nützel
@home: 
--- xc/lib/GL/mesa/src/drv/r200/r200_maos_verts.c	2003-12-10 18:25:50.0 +0100
+++ xc/lib/GL/mesa/src/drv/r200/r200_maos_verts.c.Dieter	2003-09-20 16:57:51.0 +0200
@@ -174,7 +174,7 @@
 	 R200_CP_VC_FRMT_ST0|		\
 	 R200_CP_VC_FRMT_ST1|		\
 	 R200_CP_VC_FRMT_N0)
-#define TAG(x) x##_rgpa_spec_st_st_n
+#define TAG(x) x##_rgba_spec_st_st_n
 #include "r200_maos_vbtmp.h"
 
 #define IDX 10
@@ -208,7 +208,7 @@
 	 R200_CP_VC_FRMT_ST1|		\
 	 R200_CP_VC_FRMT_Q1|		\
 	 R200_CP_VC_FRMT_N0)
-#define TAG(x) x##_w_rgpa_spec_stq_stq_n
+#define TAG(x) x##_w_rgba_spec_stq_stq_n
 #include "r200_maos_vbtmp.h"
 
 
@@ -231,10 +231,10 @@
init_rgba_st_n();
init_rgba_spec_st_st();
init_st_st_n();
-   init_rgpa_spec_st_st_n();
+   init_rgba_spec_st_st_n();
init_rgba_stq();
init_rgba_stq_stq();
-   init_w_rgpa_spec_stq_stq_n();
+   init_w_rgba_spec_stq_stq_n();
 }
 
 
--- xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c	2003-12-10 18:25:50.0 +0100
+++ xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c.Dieter	2003-09-20 16:57:51.0 +0200
@@ -170,7 +170,7 @@
 	 RADEON_CP_VC_FRMT_ST0|		\
 	 RADEON_CP_VC_FRMT_ST1|		\
 	 RADEON_CP_VC_FRMT_N0)
-#define TAG(x) x##_rgpa_spec_st_st_n
+#define TAG(x) x##_rgba_spec_st_st_n
 #include "radeon_maos_vbtmp.h"
 
 #define IDX 10
@@ -204,7 +204,7 @@
 	 RADEON_CP_VC_FRMT_ST1|		\
 	 RADEON_CP_VC_FRMT_Q1|		\
 	 RADEON_CP_VC_FRMT_N0)
-#define TAG(x) x##_w_rgpa_spec_stq_stq_n
+#define TAG(x) x##_w_rgba_spec_stq_stq_n
 #include "radeon_maos_vbtmp.h"
 
 
@@ -227,10 +227,10 @@
init_rgba_st_n();
init_rgba_spec_st_st();
init_st_st_n();
-   init_rgpa_spec_st_st_n();
+   init_rgba_spec_st_st_n();
init_rgba_stq();
init_rgba_stq_stq();
-   init_w_rgpa_spec_stq_stq_n();
+   init_w_rgba_spec_stq_stq_n();
 }
 
 
--- xc/lib/GL/mesa/src/drv/radeon/radeon_sanity.c	2003-12-10 18:25:50.0 +0100
+++ xc/lib/GL/mesa/src/drv/radeon/radeon_sanity.c.Dieter	2003-09-20 16:57:51.0 +0200
@@ -136,7 +136,7 @@
 	{ 0, 5, "R200_PP_CUBIC_OFFSET_F1_5" },
{ RADEON_PP_TEX_SIZE_0, 2, "RADEON_PP_TEX_SIZE_0" },
{ RADEON_PP_TEX_SIZE_1, 2, "RADEON_PP_TEX_SIZE_1" },
-   { RADEON_PP_TEX_SIZE_2, 2, "RADEON_PP_TEX_SIZE_1" },
+   { RADEON_PP_TEX_SIZE_2, 2, "RADEON_PP_TEX_SIZE_2" },
 };
 
 struct reg_names {
@@ -177,22 +177,22 @@
{ RADEON_PP_TXFILTER_2, "RADEON_PP_TXFILTER_2" },
{ RADEON_PP_TXFORMAT_0, "RADEON_PP_TXFORMAT_0" },
{ RADEON_PP_TXFORMAT_1, "RADEON_PP_TXFORMAT_1" },
-   { RADEON_PP_TXFORMAT_2, "RADEON_PP_TXFORMAT_3" },
+   { RADEON_PP_TXFORMAT_2, "RADEON_PP_TXFORMAT_2" },
{ RADEON_PP_TXOFFSET_0, "RADEON_PP_TXOFFSET_0" },
{ RADEON_PP_TXOFFSET_1, "RADEON_PP_TXOFFSET_1" },
-   { RADEON_PP_TXOFFSET_2, "RADEON_PP_TXOFFSET_3" },
+   { RADEON_PP_TXOFFSET_2, "RADEON_PP_TXOFFSET_2" },
{ RADEON_PP_TXCBLEND_0, "RADEON_PP_TXCBLEND_0" },
{ RADEON_PP_TXCBLEND_1, "RADEON_PP_TXCBLEND_1" },
-   { RADEON_PP_TXCBLEND_2, "RADEON_PP_TXCBLEND_3" },
+   { RADEON_PP_TXCBLEND_2, "RADEON_PP_TXCBLEND_2" },
{ RADEON_PP_TXABLEND_0, "RADEON_PP_TXABLEND_0" },
{ RADEON_PP_TXABLEND_1, "RADEON_PP_TXABLEND_1" },
-   { RADEON_PP_TXABLEND_2, "RADEON_PP_TXABLEND_3" },
+   { RADEON_PP_TXABLEND_2, "RADEON_PP_TXABLEND_2" },
{ RADEON_PP_TFACTOR_0, "RADEON_PP_TFACTOR_0" },
{ RADEON_PP_TFACTOR_1, "RADEON_PP_TFACTOR_1" },
-   { RADEON_PP_TFACTOR_2, "RADEON_PP_TFACTOR_3" },
+   { RADEON_PP_TFACTOR_2, "RADEON_PP_TFACTOR_2" },
{ RADEON_PP_BORDER_COLOR_0, "RADEON_PP_BORDER_COLOR_0" },
{ RADEON_PP_BORDER_COLOR_1, "RADEON_PP_BORDER_COLOR_1" },
-   { RADEON_PP_BORDER_COLOR_2, "RADEON_P

Re: [Dri-devel] MGA font corruption revisited - now reproducible

[Linus Torvalds]

On Wed, 10 Dec 2003, Ryan Underwood wrote:
> >
> > They're not available anymore :( It's a real shame since they seemed to be
> > quite friendly towards open source developers at one point. I can almost
> > understand that they don't want to release any parhelia docs but I don't
> > understand why they stopped giving out the older docs...
>
> Must be some new management over there... *sigh*

Never attribute to malice what can be sufficiently explained by laziness
or stupidity.

Maintaining documentation is not something companies tend to get paid for,
and they do it because it indirectly helps sell hardware: the better
supported the hardware is, the more likely it will work well, and the more
likely you'll get a good name and sales.

But when it comes to old hardware that doesn't bring the company any
revenue any more, the only reason to maintain documentation (even if the
"maintenance" is just having people be aware of it, and making it
available on a web-site and having the proper indexing to find it) is to
show that you're committed to your products, so that people who buy the
new ones can trust you.

And a lot of companies don't seem to think that it's worth the pain.
They'd rather screw their old customers over and try to get them to
upgrade to the new product. Which works well enough, I guess, since it
clearly is fairly rare to try to support your old stuff any longer than
absolutely necessary.

Sometimes consumer protection laws (especially in Europe) tend to have
_requirements_ that you have things like replacement parts and
documentation available for up to five years after you stopped selling the
product. At other times, contractual obligations with other companies
require the same.

But on the whole, technical documentation doesn't fall under that heading
(while pure "maintenance manuals" often do - if they existed in the first
place).

Major documentation policies usually only exist at the big old-time
companies. For example, I could buy the "Technical Reference: Personal
Computer AT" reference from IBM in 1991 - even though the thing was
written in 1985. Because a company like IBM tends to have all these
customers that really pay for _support_ more than new hardware. Their
paying customer base literally cares about the fact that they know that
they can get support and docs for hardware that may be quite old.

In contrast, think about the best customer base of a graphics card vendor
for a moment. The best customers there are the ones that upgrade once a
year, and if they throw away their old card in disgust because it no
longer plays the newest games titles, all the better.

I hope that will change. I _think_ it will change. But it's likely to
change only when we get rid of the "new gfx card every six months"
mentality.

Linus


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] patch: against some typos in radeon driver

[Alan Hourihane]

On Wed, Dec 10, 2003 at 02:46:27PM +0100, Dieter Nützel wrote:
> Am Sonntag, 10. August 2003 9:39 schrieb  Andreas Stenglein:
> > trivial...
> > fixes some typos in the radeon driver
> > ["r100_sanity_typo_patch1.txt" (text/x-patch)]
> > 
> > diff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c \
> > HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c
> > --- HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c Wed Apr 30 
> 03:50:52 \
> > 2003
> > +++ HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c  Sun Aug 10 
> 11:10:27 2003
> > @@ -170,7 +170,7 @@
> >  RADEON_CP_VC_FRMT_ST0| \
> >  RADEON_CP_VC_FRMT_ST1| \
> >  RADEON_CP_VC_FRMT_N0)
> > -#define TAG(x) x##_rgpa_spec_st_st_n
> > +#define TAG(x) x##_rgba_spec_st_st_n
> >  #include "radeon_maos_vbtmp.h"
> [-]
> 
> It "applies" on radeon _and_ r200.
> Is this _needed_?
> I have rediffed it against trunk (radeon and r200).

It's not strictly a problem - more of a typo.

I've just committed it.

Alan.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: pbuffers, extensions to DRM

[Dieter Nützel]

Am Dienstag, 09. Dezember 2003 11:15 schrieb Keith Whitwell:
> Jon Smirl wrote:
>
> > My current thinking on this is to do it the DRM driver but store the
> > allocation
 data in normal system RAM. This would allow the allocation
> > routines to function without touching the framebuffer.
> > 
> > I would really like to make sure that DRM drivers can function without
> > having to
 map the framebuffer into kernel address space. We only have
> > 1GB of kernel address space to work with and the kernel has to live in
> > that 1GB too. 3dlabs is shipping a 512MB card now:
> > http://www.3dlabs.com/product/wildcatvp/vppro/index.htm and a 1GB model
> > is in
 the works. It is just going to be impossible to map these future
> > cards into the kernel.
>
> 
> ...
> 
>
> > I've also been poking around a little in the radeon DRM driver. It seems
> > to be
 mapping the framebuffer into kernel space but I never see any
> > place that the driver code touches it.
>
> 
> Correct.  There's nowhere the kernel needs to touch the framebuffer.

You _can have_ 4 GB for ages from Mitsubishi/TeraRecon.
http://www.terarecon.com/products/vp_1000_1_prod.html

BTW Very cool board together with VTK.

Greetings,
Dieter
-- 
Dieter Nützel
@home: 
áŠÄ…ë^™¨¥ŠË)¢{(­ç[ȀL.)îÅ;­¢¸š–À^r‰žjw±¥êíŠrÈ5Eè®;¬¶ÈZ®—§Ê‹«²H¥–Ä¢‚{©~ŠÈË­ç‹Š{±Nëh®&¥°·š®w¯z¼­†)à~º&¶›jÈl…ée¶‹2±§fŠp¥‰É'£m¶ŸÿiÛ(±ÙÜ¢oÚv'uÛ¿–Z‰Ý÷ïZ)rXœ:âuëޖf¢–)à–+-¸z÷¥–+-²Ê.­ÇŸ¢¸ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?–+-ŠwèýÚâuëÞ

Re: [Dri-devel] patch: against some typos in radeon driver

[Dieter Nützel]

Am Sonntag, 10. August 2003 9:39 schrieb  Andreas Stenglein:
> trivial...
> fixes some typos in the radeon driver
> ["r100_sanity_typo_patch1.txt" (text/x-patch)]
> 
> diff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c \
> HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c
> --- HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c Wed Apr 30 
03:50:52 \
> 2003
> +++ HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c  Sun Aug 10 
11:10:27 2003
> @@ -170,7 +170,7 @@
>  RADEON_CP_VC_FRMT_ST0| \
>  RADEON_CP_VC_FRMT_ST1| \
>  RADEON_CP_VC_FRMT_N0)
> -#define TAG(x) x##_rgpa_spec_st_st_n
> +#define TAG(x) x##_rgba_spec_st_st_n
>  #include "radeon_maos_vbtmp.h"
[-]

It "applies" on radeon _and_ r200.
Is this _needed_?
I have rediffed it against trunk (radeon and r200).

radeon_maos_verts.c
radeon_sanity.c
r200_sanity.c

-- 
Dieter Nützel
@home: 


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)

[Dieter Nützel]

Am Mittwoch, 10. Dezember 2003 02:04 schrieb Alan Hourihane:
> On Tue, Dec 09, 2003 at 04:54:24PM -0800, Eric Anholt wrote:
> > On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote:
> > > On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote:
> > > > On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote:
> > > > > On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote:
> > > > > > On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote:
> > > > > > > CVSROOT:  /cvs/dri
> > > > > > > Module name:  xc
> > > > > > > Repository:   xc/xc/config/cf/
> > > > > > > Changes by:   [EMAIL PROTECTED]   03/12/09 14:21:04
> > > > > > >
> > > > > > > Log message:
> > > > > > >   move NormalLibExpat definition into OS specific config files
> > > > > > > that'll help the merge from/to XFree86 at a later stage.
> > > > > >
> > > > > > The build is still broken on FreeBSD.  Would it be objected to if
> > > > > > I make the static expatness optional depending on platform?  I'd
> > > > > > rather not be linking statically for our ports version of the
> > > > > > DRI, anyway.
> > > > >
> > > > > Can you explain what's broken in the FreeBSD build ?
> > > > >
> > > > > Also - Is expat available on all FreeBSD versions ?
> > > >
> > > > First it dies with not finding expat.h.  Adding EXPATINCLUDES to
> > > > common/Makefile.in fixed that.  Then it dies on -lexpat because expat
> > > > wasn't built (even with HasExpat YES not being defined in
> > > > FreeBSD.cf).
> > >
> > > O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat
> > > which should default to YES because BuildXF86DRI is set. UseExpat
> > > should override it.
> >
> > But BuildExpat is (UseExpat && !HasExpat), right?
>
> Yes. Missed that essential piece. I'd moved straight down to see the
> #if UseExpat furthur down X11.tmpl.
>
> > > > expat is available in ports, and I feel pretty safe saying everyone
> > > > ever using the DRI on FreeBSD will already have it installed (having
> > > > already installed XFree86-4-libraries which depends on it).  I've
> > > > never heard a single complaint in my memory about HasExpat already
> > > > being set unconditionally in FreeBSD.cf.
> > >
> > > I've got a FreeBSD 4.3 box, I'll check if expat is installed by
> > > default.
> >
> > If you mean in the base install, no, it isn't (well, except as
> > libbsdxml, but it's renamed for a reason).  But you can't build the DRI
> > from a base FreeBSD install, last I knew of; you first need to install
> > XFree86.  If you are doing it properly on FreeBSD that means using
> > ports, which means XFree86-4-libraries which depends on libexpat.  If
> > people install XFree86 from source, I hope XFree86 is installing its
> > libexpat in the right place, but I don't care about that too much.
> > Their system is probably going to end up broken in odd ways when they
> > try to use ports after that anyway.
>
> O.k. I'll defer to your decision on that.
>
> > > > > > What I'm trying right now is making an ExpatLibrary definition in
> > > > > > Imake.tmpl that is used in the drivers build.  It's overridden
> > > > > > for non-FreeBSD in host.def.
> > > > >
> > > > > Can you send a patch first ?
> > > > >
> > > > > Alan.
> > > >
> > > > http://www.freedesktop.org/~anholt/dri-expatfix.diff
> > > >
> > > > Apoligies for the mess in it; there are some other changes in there.
> > > > It's what I've just tested on FreeBSD and Linux, with the linking
> > > > looking like it ended up right (ldd shows no libexpat on linux)
> > > >
> > > > Unless there's some compelling reason to have expat linked
> > > > statically, I'll have to end up patching to fix linking in ports,
> > > > which will be annoying.
> > >
> > > The problem of putting the StaticLibrary() bits back in host.def
> > > results in the build linking against the dynamic version when merged
> > > back into XFree86 at a later date. I'm trying to modify the OS cf files
> > > now so that we don't lose that functionality.
> > >
> > > So if you want to do
> > >
> > > #ifndef ExpatLibrary
> > > #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat)
> > > #endif
> > >
> > > in the linux.cf instead of the host.def that's fine with me. That'll
> > > leave the FreeBSD and OpenBSD architectures linking dynamically.
> >
> > So Linux has to have it linked statically in XFree86, too?  Not seeing
> > the reason for that, but OK.
>
> Actually, I've had a rethink about this. Leave it in host.def for now
> as you've got it. We may need to revisit it later.

Didn't we have "expat" on all _new_ distros?
SuSE 9.0 for example.

SunWave1 /opt/Mesa# rpm -qa | grep expat
expat-1.95.6-80

SunWave1 /opt/Mesa# rpm -ql expat-1.95.6-80
/usr/bin/xmlwf
/usr/include/expat.h
/usr/lib/libexpat.a
/usr/lib/libexpat.la
/usr/lib/libexpat.so
/usr/lib/libexpat.so.0
/usr/lib/libexpat.so.0.4.0
/usr/share/doc/packages/expat
/usr/share/doc/packages/expat/COPYING
/usr/share/doc/packages/expat/Changes
/usr/share/doc/packages/expat/MANIFEST
/usr/share/doc/packages/e

Re: [Dri-devel] DRI newmesa merge

[David D. Hagood]

Felix Kühling wrote:

It would be annoying for people with dialup connections if make required
access to a remote CVS repository.
And how would that be any different than syncing up with the main DRI 
CVS repo? If you are building one from CVS, you may as well get the 
other from CVS as well.

---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] MGA font corruption revisited - now reproducible

[Ville Syrjälä]

On Wed, Dec 10, 2003 at 04:26:25AM -0600, Ryan Underwood wrote:
> 
> On Wed, Dec 10, 2003 at 09:03:34AM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
> > > 
> > > Thanks for the insight.  Is this already something that has been
> > > extensively looked at without success, or would it be worth my time to
> > > dig into the code and try to find the cause?  I've thought about it, but
> > > afraid that I will just hit a brick wall someone else already ran into
> > > with it. ;)
> > 
> > I've attached a patch that should hopefully fix this problem. The render
> > code just forgot to reset the multi texturing registers. I've not
> > actually tested the patch but I don't see anything else wrong with the
> > code...
> 
> Cool!  Is it possible to build the driver modules separately from the
> XFree86 "world", and if so, can you point me at some instructions on how
> to accomplish that?

If you remove/comment out the following line
$(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World
in the top Makefile "make World" shouldn't actually build anything.
After that you should be able to build only the driver.

I uploaded my patched mga_drv.o to my website
http://www.sci.fi/~syrjala/dri/ so you might want to try that before
building yourself...

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] MGA font corruption revisited - now reproducible

[Ryan Underwood]

On Wed, Dec 10, 2003 at 09:03:34AM +0200, Ville Syrjälä wrote:
> On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
> > 
> > Thanks for the insight.  Is this already something that has been
> > extensively looked at without success, or would it be worth my time to
> > dig into the code and try to find the cause?  I've thought about it, but
> > afraid that I will just hit a brick wall someone else already ran into
> > with it. ;)
> 
> I've attached a patch that should hopefully fix this problem. The render
> code just forgot to reset the multi texturing registers. I've not
> actually tested the patch but I don't see anything else wrong with the
> code...

Cool!  Is it possible to build the driver modules separately from the
XFree86 "world", and if so, can you point me at some instructions on how
to accomplish that?

> > Is there anywhere I can get a G400 databook for reference, or is that
> > not publicly available?
> 
> They're not available anymore :( It's a real shame since they seemed to be
> quite friendly towards open source developers at one point. I can almost
> understand that they don't want to release any parhelia docs but I don't
> understand why they stopped giving out the older docs...

Must be some new management over there... *sigh*

-- 
Ryan Underwood, <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: [Dri-devel] Flightgear TCL lighting problem back

[Keith Whitwell]

Felix Kühling wrote:
Hi,

I briefly tried the DRI trunk after the newmesa merge last night. In
flightgear with TCL enabled the old lighting problem seems to be back.
Everything is too dark, but banking to one side makes things brighter.
Can you remember what changed to fix that problem last time?

Keith





---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI newmesa merge

[Keith Whitwell]

Felix Kühling wrote:
On Tue, 09 Dec 2003 17:53:14 -0600
"David D. Hagood" <[EMAIL PROTECTED]> wrote:

Alan Hourihane wrote:

I'm going to merge the newmesa branch to the trunk in a few moments.

I've giving people a heads up that I'm going to delete the xc/extras/Mesa
directory and insist on people checking out a copy of Mesa's newtree and
people setting that in their xc/config/cf/host.def file to point to their
checked out copy.
What about having the Make process check out the appropriate version to 
a directory within the DRI build?

That way, you can also force the Make to check out a specific tag of the 
Mesa tree, to control when changes are applied, or let it check out the 
HEAD of the branch.


It would be annoying for people with dialup connections if make required
access to a remote CVS repository.
The idea behind tracking Mesa in this way is to allow updates to come across 
quickly without merges during this stabilization period.  Eventually there 
will be a copy of Mesa pulled into the DRI tree - presumably the latest stable 
release.

At this point, I would expect that people working on the DRI drivers will be 
building them out of the Mesa tree - the DRI tree will remain for work on the 
infrastructure and 2D drivers.  I don't think it's possible to build a DRI 
driver in the mesa tree right now, but the work to do so is trivial (I've done 
it previously on the old embedded branch).

As I think about it, I'd like to see the DRM come out of the DRI tree and have 
its own CVS repository, probably seperate to mesa, but there's no rush on this.

Keith



---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRI newmesa merge

[Felix Kühling]

On Tue, 09 Dec 2003 17:53:14 -0600
"David D. Hagood" <[EMAIL PROTECTED]> wrote:

> Alan Hourihane wrote:
> > I'm going to merge the newmesa branch to the trunk in a few moments.
> > 
> > I've giving people a heads up that I'm going to delete the xc/extras/Mesa
> > directory and insist on people checking out a copy of Mesa's newtree and
> > people setting that in their xc/config/cf/host.def file to point to their
> > checked out copy.
> 
> What about having the Make process check out the appropriate version to 
> a directory within the DRI build?
> 
> That way, you can also force the Make to check out a specific tag of the 
> Mesa tree, to control when changes are applied, or let it check out the 
> HEAD of the branch.

It would be annoying for people with dialup connections if make required
access to a remote CVS repository.

Regards,
  Felix

__\|/_____ ___   -
 Felix   ___\_e -_/___/ __\___/ __\_   You can do anything,
   Kühling  (_\Ä// /_/ /)  just not everything
 [EMAIL PROTECTED]   \___/   \___/   Uat the same time.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] tests of post-newmesa dri

[Felix Kühling]

On Tue, 09 Dec 2003 22:50:54 -0800
Eric Anholt <[EMAIL PROTECTED]> wrote:

[snip]
> P.S. Felix, I still have testing that r128 diff on my TODO, sorry for
> not trying it yet.

No problem. It's not really a priority and nothing else depends on it. I
was just starting to forget about it myself, so I brought it up in the
meeting. ;-)

> 
> -- 
> Eric Anholt[EMAIL PROTECTED]  
> http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
> 

__\|/_____ ___   -
 Felix   ___\_e -_/___/ __\___/ __\_   You can do anything,
   Kühling  (_\Ä// /_/ /)  just not everything
 [EMAIL PROTECTED]   \___/   \___/   Uat the same time.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Flightgear TCL lighting problem back

[Felix Kühling]

Hi,

I briefly tried the DRI trunk after the newmesa merge last night. In
flightgear with TCL enabled the old lighting problem seems to be back.
Everything is too dark, but banking to one side makes things brighter.

There is another problem with Torcs that looks like texture coordinates
are affected by the viewing transformation. But I also get an error
message from plib that I didn't get before the newmesa merge. So the
cause may be something different. I'm going to investigate.

Regards,
  Felix

P.S.: I successfully built DRI HEAD on freedesktop now, but I still have
to fix the packaging script for the new directory structure.

__\|/_____ ___   -
 Felix   ___\_e -_/___/ __\___/ __\_   You can do anything,
   Kühling  (_\Ä// /_/ /)  just not everything
 [EMAIL PROTECTED]   \___/   \___/   Uat the same time.


---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] tests of post-newmesa dri

[Eric Anholt]

I just went through the hardware I have on FreeBSD trying the newmesa
DRI, testing with glxgears and tuxracer, and the mesa demos reflect,
gloss, and tunnel.

The r200 system had 4.3.99.15 server, 4.3.0 libGL, and newmesa GL
drivers.  1600x1200x16 screen.  The other tests were done on another
system with a 4.3.99.15 server (except for MGA, which was done with
4.3.0 server) newmesa libGL (after seeing the issues listed using 4.3.0
libGL and wanting to be sure), and newmesa GL drivers.  640x480x16
screen.  I have doubts about the glide I was using for the v5, but I
hope to get a new glide soon (just need to package it up, which has
defeated me many times in the past).

Results:
r200: minor flickering of tree textures
r100: tuxracer's ground broken
r128, SiS, MGA: tuxracer's ice patches are very ugly (more than before)
SiS: gloss looks very different -- not glossy?
SiS: reflect broken
v5: texturing broken in tuxracer, tunnel, gloss

reflect's visual wasn't available on r128 and MGA, perhaps due to using
depth 16.

Hardware:
r200: Radeon QL 8500
r100: Radeon QW 7500
SiS: SiS 305 PCI
r128: Rage 128 Pro PF (iirc)
MGA: MGA G400
v5: Voodoo5 5500

P.S. Felix, I still have testing that r128 diff on my TODO, sorry for
not trying it yet.

-- 
Eric Anholt[EMAIL PROTECTED]  
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]




---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] MGA font corruption revisited - now reproducible

[Ville Syrjälä]

On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
> 
> Thanks for the insight.  Is this already something that has been
> extensively looked at without success, or would it be worth my time to
> dig into the code and try to find the cause?  I've thought about it, but
> afraid that I will just hit a brick wall someone else already ran into
> with it. ;)

I've attached a patch that should hopefully fix this problem. The render
code just forgot to reset the multi texturing registers. I've not
actually tested the patch but I don't see anything else wrong with the
code...

> Is there anywhere I can get a G400 databook for reference, or is that
> not publicly available?

They're not available anymore :( It's a real shame since they seemed to be
quite friendly towards open source developers at one point. I can almost
understand that they don't want to release any parhelia docs but I don't
understand why they stopped giving out the older docs...

-- 
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
Index: mga_reg.h
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_reg.h,v
retrieving revision 1.8
diff -u -r1.8 mga_reg.h
--- mga_reg.h   27 Jan 2002 20:05:35 -  1.8
+++ mga_reg.h   10 Dec 2003 06:27:05 -
@@ -475,6 +475,9 @@
 #define MGAREG_ALPHACTRL   0x2c7c
 #define MGAREG_DWGSYNC 0x2c4c
 
+#define MGAREG_TDUALSTAGE0 0x2cf8
+#define MGAREG_TDUALSTAGE1 0x2cfc
+
 #define MGAREG_AGP_PLL 0x1e4c
 #define MGA_AGP2XPLL_ENABLE0x1
 #define MGA_AGP2XPLL_DISABLE   0x0
Index: mga_storm.c
===
RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_storm.c,v
retrieving revision 1.20
diff -u -r1.20 mga_storm.c
--- mga_storm.c 25 Mar 2003 11:21:06 -  1.20
+++ mga_storm.c 10 Dec 2003 06:27:07 -
@@ -341,6 +341,10 @@
 tex_padw = 1 << log2w;
 tex_padh = 1 << log2h;
 
+WAITFIFO(2);
+OUTREG(MGAREG_TDUALSTAGE0, 0);
+OUTREG(MGAREG_TDUALSTAGE1, 0);
+
 WAITFIFO(15);
 OUTREG(MGAREG_TMR0, (1 << 20) / tex_padw);  /* sx inc */
 OUTREG(MGAREG_TMR1, 0);  /* sy inc */
@@ -425,6 +429,9 @@
 tex_padw = 1 << log2w;
 tex_padh = 1 << log2h;
 
+WAITFIFO(2);
+OUTREG(MGAREG_TDUALSTAGE0, 0);
+OUTREG(MGAREG_TDUALSTAGE1, 0);
 
 WAITFIFO(12);
 OUTREG(MGAREG_DR4, red << 7);  /* red start */
@@ -522,6 +529,10 @@
 tex_padw = 1 << log2w;
 tex_padh = 1 << log2h;
 
+WAITFIFO(2);
+OUTREG(MGAREG_TDUALSTAGE0, 0);
+OUTREG(MGAREG_TDUALSTAGE1, 0);
+
 WAITFIFO(15);
 OUTREG(MGAREG_TMR0, (1 << 20) / tex_padw);  /* sx inc */
 OUTREG(MGAREG_TMR1, 0);  /* sy inc */