[gentoo-amd64] More ATi driver madness

[gentoo-amd64] More ATi driver madness

[Mark Haney]

Good news:  After two months of screwing with modular X and the ATI drivers, I 
FINALLY got an X session on my Compaq R4000.

Bad news: For some incredibly stupid reason, the session graphics are 
horrible.  When I log in, the desktop looks fine, but all my console sessions 
are transparent and impossible to read and every window I close hangs out on 
the desktop like a ghost.  I've used eselect to configure openGL for the ati 
interface, the module (latest driver) loads and i even get the correct info 
in 'fglrxinfo'.  Not to mention I get 1280x800 resolution.  But if this 
graphics problem can't be fixed, it's impossible to use that way.

Does anyone have any possible clue what I can do to fix that?


-- 
Fere libenter homines id quod volunt credunt.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Antoine Martin]

I had the same issue with xorg 6.8

fixed by using xorg 7.0 or 7.1 and latest ati drivers.

There is also an option in xorg.conf you can use to disable the 
acceleration for that particular problem - can't remember which one (or 
just disable acceleration globally)

I can't wait for ATI to open-source their crappy slaveryware drivers.

Antoine
(2560x1920 LCD with accelerated 3D :)

Mark Haney wrote:
> Good news:  After two months of screwing with modular X and the ATI drivers, I 
> FINALLY got an X session on my Compaq R4000.
> 
> Bad news: For some incredibly stupid reason, the session graphics are 
> horrible.  When I log in, the desktop looks fine, but all my console sessions 
> are transparent and impossible to read and every window I close hangs out on 
> the desktop like a ghost.  I've used eselect to configure openGL for the ati 
> interface, the module (latest driver) loads and i even get the correct info 
> in 'fglrxinfo'.  Not to mention I get 1280x800 resolution.  But if this 
> graphics problem can't be fixed, it's impossible to use that way.
> 
> Does anyone have any possible clue what I can do to fix that?

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Hemmann, Volker Armin]

On Sunday 13 August 2006 00:34, Antoine Martin wrote:
> I had the same issue with xorg 6.8
>
> fixed by using xorg 7.0 or 7.1 and latest ati drivers.
>
> There is also an option in xorg.conf you can use to disable the
> acceleration for that particular problem - can't remember which one (or
> just disable acceleration globally)
>
> I can't wait for ATI to open-source their crappy slaveryware drivers.
>

you can wait for a long, long time. heise.de reported today, that ATI will NOT 
opensource any drivers. They asked them and got a big fat NO as an answer.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: More ATi driver madness

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200608130038.56469.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Sun, 13 Aug 2006 00:38:56 +0200:

> On Sunday 13 August 2006 00:34, Antoine Martin wrote:
>>
>> I can't wait for ATI to open-source their crappy slaveryware drivers.
>>
> you can wait for a long, long time. heise.de reported today, that ATI
> will NOT opensource any drivers. They asked them and got a big fat NO as
> an answer.

Of course, it's all speculation at this point, but while they got no for
an answer, some of the discussion I've seen has pointed out that's exactly
what you'd expect folks from the ATI camp to say at this time -- before
the deal is closed and in fact before the shareholders have even voted on
it.  Not saying it will happen, not saying it won't, but simply that in
such a situation, spokespeople tend to keep saying the same thing until
they are told to say something different, because that's exactly what they
are getting paid to do.  At this point, it's not unreasonable that the
spokespeople simply don't know, in part because it's their job /not/ to
know some things at this point.

So I still have hope...

Meanwhile, if AMD's intent is to be able to sell the whole solution, cpu
and mobo chipset in some cases with integrated video, in ordered to better
compete with Intel, they'll pretty much /have/ to open-spec it at least to
a point, because Intel has.  To /not/ do so will leave them in a
competitive hole, with at least one segment of their market, and an often
early adopter one at that (Linux rolled out AMD64 support well before MS
did, and for some time, Linux was the primary market for it, something AMD
is well aware of, I'm sure).

Fortunately for me, I'm not planning on a hardware platform upgrade for at
least a couple more years (I'm dual Opteron 242 w/ 8 gig memory currently,
in a $400 Tyan dual-dual-core capable board I bought a couple years ago,
and will be upgrading to dual-core Opteron 270 or 272s later this year
after the upgrades drop the prices on socket 940s), and my Radeon 9200 AGP
driving dual 21" monitors with xorg's native drivers seems to work
relatively well, all things considered.

By the time I'm looking for a platform upgrade in 2-4 years (I figure back
to a single CPU again by then, but quad-core, maybe even octi-core),
AMD/ATI should have open sourced if they are going to. If they haven't, I
could well be buying Intel for the first time since my 486SX-25 w/ an
incredible 4 MB of RAM!  However, given all I've read about AMD's goals
and reasons for doing this merger, I still consider this the best chance
we've yet seen for AMD/ATI to release at least enough specs to allow
reasonable 3D, even if it they do reserve some of the best stuff as
closed, so I really do expect I'll still have a choice, and it won't be
Baked Intel or Fried Intel or Intel on bread or ... (xref Monty Python,
SPAM).

Of course, by then, we should have a bit better data on whether the OGP
(Open Graphics Project, google or wikipedia it if necessary) FPGA board
got enough buyers to allow them to launch the regular chip version, and
have at least some fix on how far off that might be if it did.  Depending
on how the timing all works out, it's just possible I'll be buying the
mobo/cpu platform with an OGP card in mind.  OTOH, if AMD opens their
video specs/drivers as Intel has, it's just possible it could roll NVidia
as well, and the OGP may end up not having a market, as everything else is
open speced at least to /some/ degree anyway.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: More ATi driver madness

[Hemmann, Volker Armin]

On Sunday 13 August 2006 11:49, Duncan wrote:
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
> 200608130038.56469.volker.armin.hemmann@tu-clausthal.de, excerpted below,
>
> on  Sun, 13 Aug 2006 00:38:56 +0200:
> > On Sunday 13 August 2006 00:34, Antoine Martin wrote:
> >> I can't wait for ATI to open-source their crappy slaveryware drivers.
> >
> > you can wait for a long, long time. heise.de reported today, that ATI
> > will NOT opensource any drivers. They asked them and got a big fat NO as
> > an answer.
>
> Of course, it's all speculation at this point, but while they got no for
> an answer, some of the discussion I've seen has pointed out that's exactly
> what you'd expect folks from the ATI camp to say at this time -- before
> the deal is closed and in fact before the shareholders have even voted on
> it.  Not saying it will happen, not saying it won't, but simply that in
> such a situation, spokespeople tend to keep saying the same thing until
> they are told to say something different, because that's exactly what they
> are getting paid to do.  At this point, it's not unreasonable that the
> spokespeople simply don't know, in part because it's their job /not/ to
> know some things at this point.
>
> So I still have hope...
>
> Meanwhile, if AMD's intent is to be able to sell the whole solution, cpu
> and mobo chipset in some cases with integrated video, in ordered to better
> compete with Intel, they'll pretty much /have/ to open-spec it at least to
> a point, because Intel has.  To /not/ do so will leave them in a
> competitive hole, with at least one segment of their market, and an often
> early adopter one at that (Linux rolled out AMD64 support well before MS
> did, and for some time, Linux was the primary market for it, something AMD
> is well aware of, I'm sure).
>

AMD has no experience with the tangled mess, graphics IP is. So they might 
have some dreams, ATI knows that are not possible. The last time ATI openend 
up, they did not really opened the drivers, they paid a 3rd party, a 
corporation, to write open drivers, so ATI did not have to release the specs.


> Fortunately for me, I'm not planning on a hardware platform upgrade for at
> least a couple more years (I'm dual Opteron 242 w/ 8 gig memory currently,
> in a $400 Tyan dual-dual-core capable board I bought a couple years ago,
> and will be upgrading to dual-core Opteron 270 or 272s later this year
> after the upgrades drop the prices on socket 940s), and my Radeon 9200 AGP
> driving dual 21" monitors with xorg's native drivers seems to work
> relatively well, all things considered.

And the last ATI's don't even have 2d drivers, while David Airlie still waits 
for the 'ok' from ATI to release the ones he has written.

>
> By the time I'm looking for a platform upgrade in 2-4 years (I figure back
> to a single CPU again by then, but quad-core, maybe even octi-core),
> AMD/ATI should have open sourced if they are going to. If they haven't, I
> could well be buying Intel for the first time since my 486SX-25 w/ an
> incredible 4 MB of RAM!  

in 2-4 years, nouveau should have good working open drivers. Remember, they 
have the old open source 3d enabled driver source from nvidia from the 
Xfree86 3.X days. Before Nvidia was forced by unknon forces (some say MS and 
Intel) to close the drivers.

> However, given all I've read about AMD's goals 
> and reasons for doing this merger, I still consider this the best chance
> we've yet seen for AMD/ATI to release at least enough specs to allow
> reasonable 3D, even if it they do reserve some of the best stuff as
> closed, so I really do expect I'll still have a choice, and it won't be
> Baked Intel or Fried Intel or Intel on bread or ... (xref Monty Python,
> SPAM).

ATI does not even release 2d drivers at the moment ....
>
> Of course, by then, we should have a bit better data on whether the OGP
> (Open Graphics Project, google or wikipedia it if necessary) FPGA board
> got enough buyers to allow them to launch the regular chip version, and
> have at least some fix on how far off that might be if it did.  Depending
> on how the timing all works out, it's just possible I'll be buying the
> mobo/cpu platform with an OGP card in mind.  OTOH, if AMD opens their
> video specs/drivers as Intel has, it's just possible it could roll NVidia
> as well, and the OGP may end up not having a market, as everything else is
> open speced at least to /some/ degree anyway.

2d is open - from nvidia... and you don't need more, if you just have some 
servers running or only need basic desktop. ATI does not even has that. And 
Intel.. I just don't trust them. It would be typical for them to open their 
drivers and forbid the others to do the same, just to get some advantage in 
the market place. About the ogp - as long as there is no hardware, I don't 
even consider them. Even in very future plannings.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: More ATi driver madness

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200608131915.18375.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Sun, 13 Aug 2006 19:15:18 +0200:

> 2d is open - from nvidia... and you don't need more, if you just have some
> servers running or only need basic desktop. ATI does not even has that.
> And Intel.. I just don't trust them. It would be typical for them to open
> their drivers and forbid the others to do the same, just to get some
> advantage in the market place. About the ogp - as long as there is no
> hardware, I don't even consider them. Even in very future plannings.

The thing is... the 2D hardware is deprecated and on the way out.  It's
just a corner of most video chips now, and with all major platforms (incl.
Linux/X) going 3D on the desktop, 2D is on the way out.  With the
generation of hardware matching Panorama-of-MSWormOS, 3D is fully
integrated, to the point where even 2D is drawn using the 3D algorithms. 
It won't be long until there's no 2D hardware to have drivers FOR!

As for AMD, here's what I skipped over in the previous post.  They've
already teamed up with various third parties to develop and sell physics
and floating point processors slotted into additional CPU sockets, linked
directly to the multi-core CPUs via Cohesive HyperTransport.  The next
step is doing the same thing with full video processors, a decent portion
of which are physics processors anyway.  There are however a couple issues
with the idea, including the fact that getting video folks to  commit to an
AMD specific platform when they already have PCI-E would have been rather
difficult.  This is supposedly one of the big reasons they bought ATI --
to give AMD the where-with-all to follow up on that idea.  Now, in ordered
to fully populate the ecosystem, they'll /have/ to open things up.  Keep
in mind that Intel is designing similar stuff with it's integrated
solutions, and if AMD didn't get in the game, it wouldn't be long until
they were no more relevant than Via in the x86 CPU market.  AMD can do it,
and can continue to define the rules and the market place much as they did
with amd64 aka x86_64 and HyperTransport, but in ordered to do it, they
have to define open standards much as they did with x86_64.  Should they
fail, Intel won't be far behind and will end up ahead, and AMD could very
soon be an also-ran.

The flip side, as you mentioned, is the possibility of stomping on the
patents of someone else and getting nicked for it.  However, AMD has
enough trade secrets and patents of its own that taking them down will be
far more complex than trying to take down ATI alone.  Even someone like
Rambus can't afford to play the game exclusively, because any practical
application, thus everyone they would be attempting to license to, is
going to be using an AMD technique as well, so they can't directly attack
AMD without nuking the market for their own product in the process.  AMD,
like Intel and IBM, is big enough one has to cross-license, because
anything else ends up being MAD (Mutually Assured Destruction, a reference
to the cold war, but you likely know that already).

So... I think AMD/ATI /could/ open their video specs.  However, it's still
an open question of whether they /will/, tho I think the chances are
pretty good, as Intel will have them between a rock and a hard place if
they don't.

(My sources for much of this were articles at ArsTechnica and the
Register, in turn quoting trade mags and industry analysts, plus AMD's own
PR.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: More ATi driver madness

[Bob Sanders]

Duncan, mused, then expounded:
> 
> As for AMD, here's what I skipped over in the previous post.  They've
> already teamed up with various third parties to develop and sell physics
> and floating point processors slotted into additional CPU sockets, linked
> directly to the multi-core CPUs via Cohesive HyperTransport.  The next
> step is doing the same thing with full video processors, a decent portion
> of which are physics processors anyway.  There are however a couple issues
> with the idea, including the fact that getting video folks to  commit to an
> AMD specific platform when they already have PCI-E would have been rather
> difficult.  This is supposedly one of the big reasons they bought ATI --
> to give AMD the where-with-all to follow up on that idea.  

Sorry, the conclusion is very likely wrong.  True AMD wants several things
that ATI brings to the table.  But, there is little chance of Gfx being
integrated fully into the cpu or even into a socket via a HyperTransport
link.  It's just too costly and the performance, for all but UMA (Unified
Memory Archittecture) memory interface would suffer greatly.  It's also
one of the reasons AMD is adding a PCIe interface onto their cpus - the
1207 pin Socket F (is that the correct socket?) models, later next year.

Gfx, especially 3D, is about memory bandwidth.  Move the memory out
of direct contact with the gpu chip - say via a socket, and it's
necessary to drop the frequency that the memory interface runs at.
It's basic electronics - add more capacitaince and inductance, and
the speed of the interface goes down. 

True, it's possible to put low-end, UMA based, graphics into a socket,
but that's not really a long-term goal.  Rather, just an interesting
Engineering exercise.  Plus, in laptops, where it would be best, the
socket cost - both dollars and size, negates any benefit of moving
away from it existing on the southbridge where it is today.


> Now, in ordered
> to fully populate the ecosystem, they'll /have/ to open things up.  Keep
> in mind that Intel is designing similar stuff with it's integrated
> solutions, and if AMD didn't get in the game, it wouldn't be long until
> they were no more relevant than Via in the x86 CPU market. 

Both AMD and Intel are moving, but not in the direction of more complexity.
They are moving to simpler parallel execution units - like the parallel
Gfx pipes found on GPU chips today, only for generic computing.  All this
time, cpus have had a very diffcult time moving from serial processing
and the efforts for massivly parallel units have not faired well - Sun's
last UltrsSparc.  At the same time Gfx systems have become more and more
parallel, and with the push from the late 3DLabs, have become more 
like generic, programable, compute blocks, though still diffcult to
access from main menory.


> 
> So... I think AMD/ATI /could/ open their video specs.  However, it's still
> an open question of whether they /will/, tho I think the chances are
> pretty good, as Intel will have them between a rock and a hard place if
> they don't.
>

Uh, no.  Remember, Intel doesn't make real 3D Gfx chips.  Unlike, Nvidia and
Ati, Intel does most of it's 3D processing in software.  Thus opening up
the chips specs and driver has little impact on any IP outside of Intel as
it doesn't expose any IP that might belong to Micrsoft or SGI.

Both ATI and Nvidia have IP in their hardware that came from outside
of those companies.  Opening up their drivers exposes this IP and it's
not theirs to give away.  And given that some IP was sold outright
to Microsoft, even if SGI were to open up the Gfx IP that is licensed, some
would still be held up in Redmond, as would any implementation in hardware
that insures decent performance with DirectX 9 and 10.  So outside of the
binary blobs that hide the IP, like Nvidia implements today, there will
be little change in drivers from Nvidia.  With luck AMD will get ATI
to at least get their Linux drivers into a mroe suitable form on par
with Nvidia.
 
> (My sources for much of this were articles at ArsTechnica and the
> Register, in turn quoting trade mags and industry analysts, plus AMD's own
> PR.)
>

While ArsTechnica tends to be fairly reliable, I've found stories from the
Register to be very, very, wrong - the assumptions were way off base or the
reporter got the entire story wrong because they ignored documented history.
I'd be very wary of believing a story in the Register without cross checking
it with independent sources.  Sometimes the Register will get one sentence
in the story correct.  Sometimes, the entire story is made up from that one
sentence.

Bob
-  
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: More ATi driver madness

[Duncan]

Bob Sanders <rsanders@sgi.com> posted 20060814151338.GA102938@sgi.com,
excerpted below, on  Mon, 14 Aug 2006 08:13:38 -0700:

> Gfx, especially 3D, is about memory bandwidth.  Move the memory out
> of direct contact with the gpu chip - say via a socket, and it's
> necessary to drop the frequency that the memory interface runs at.
> It's basic electronics - add more capacitaince and inductance, and
> the speed of the interface goes down.

Two factors in counter-point.  We're talking FB-DIMM tech time this comes
out, and this will be using upgrades to the same memory controller on the
CPU (only in this case GPU) AMD is already using to maintain its lead in
multi-socket performance against Intel (even while Intel's Core-Duo has
caught up at the low single-socket end).

> Remember, Intel doesn't make real 3D Gfx chips.  Unlike, Nvidia and
> Ati, Intel does most of it's 3D processing in software.  Thus opening up
> the chips specs and driver has little impact on any IP outside of Intel as
> it doesn't expose any IP that might belong to Micrsoft or SGI.

Does <> will do.  With aeroglass driving dx10 requirements, the low end of
the gfx market is about to get very legacy, very fast.  Their new chips
do more in hardware because they must, due to the performance
requirements.  That's the reason Intel's latest free driver release made
the headlines in the FLOSS world -- it's the first time we've had full
sources to something that capable.

> While ArsTechnica tends to be fairly reliable, I've found stories from the
> Register to be very, very, wrong - the assumptions were way off base or the
> reporter got the entire story wrong because they ignored documented history.
> I'd be very wary of believing a story in the Register without cross checking
> it with independent sources.  Sometimes the Register will get one sentence
> in the story correct.  Sometimes, the entire story is made up from that one
> sentence.

True to a point.  However, they /do/ get credit for being one of the first
to report the AMD/ATI merger discussion, way back when it was low-cred and
most were saying it was crazy because AMD had always said it did better
NOT doing the chipsets -- it did them early on in a cycle when third party
chipsets weren't yet widely available, but didn't upgrade them and
eventually phased them out as third party chipset solutions came online. 
(This was the case for both the K7 and K8 product cycles.)

Anyway, I'm not saying it'll happen, only that this is the best
opportunity for it to happen we have, and if for whatever reason AMD/ATI
fail to open their drivers, there will be a lot of folks for whom AMD is
no longer a viable option (unless other solutions appear).  AMD certainly
realizes this, and I expect they'll try to open them -- at least a
functional subset (possibly retaining some stuff closed, but as I said, a
functional 3D subset, enough to keep them in the game, anyway).

Meanwhile, I'm adjusting to the fact that it's quite possible my next
platform will be Intel.  However, as I mentioned earlier, that's a ways
out yet, and in the computer technology sector, a lot can happen in 2-4
years...   Hey, in that time, it's actually possible Vista will prove
seriously problematic and the MS market share will have actually budged a
bit (comparable to the IE/Firefox situation today, MS still has a big
lead, but for the first time in history, their share has actually budged
in the downward direction in real measurable terms).  The signs are
already there that it's ready for it, at least elsewhere than the US.  How
far behind the US will be, who knows, but it's obviously not front of the
pack.  The thing is... if those numbers actually start to budge, it'll
change the dynamics substantially, and I'm not sure any of us grok just
how different things might be in that case or where the tipping point is.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: More ATi driver madness

[Hemmann, Volker Armin]

On Monday 14 August 2006 18:11, Duncan wrote:
> > While ArsTechnica tends to be fairly reliable, I've found stories from
> > the Register to be very, very, wrong - the assumptions were way off base
> > or the reporter got the entire story wrong because they ignored
> > documented history. I'd be very wary of believing a story in the Register
> > without cross checking it with independent sources.  Sometimes the
> > Register will get one sentence in the story correct.  Sometimes, the
> > entire story is made up from that one sentence.
>
> True to a point.  However, they /do/ get credit for being one of the first
> to report the AMD/ATI merger discussion, way back when it was low-cred and
> most were saying it was crazy because AMD had always said it did better
> NOT doing the chipsets -- it did them early on in a cycle when third party
> chipsets weren't yet widely available, but didn't upgrade them and
> eventually phased them out as third party chipset solutions came online.
> (This was the case for both the K7 and K8 product cycles.)

one of the first was theinquirer, which is even more prone to very wrong 
stories (of course, sometimes they are totally right..), so don't check 
theregister with theinquirer. Both are very speculative.

>
> Anyway, I'm not saying it'll happen, only that this is the best
> opportunity for it to happen we have, and if for whatever reason AMD/ATI
> fail to open their drivers, there will be a lot of folks for whom AMD is
> no longer a viable option (unless other solutions appear).  AMD certainly
> realizes this, and I expect they'll try to open them -- at least a
> functional subset (possibly retaining some stuff closed, but as I said, a
> functional 3D subset, enough to keep them in the game, anyway).

And I bet, the 'functional subset' won't be more than 2D, which ATI refuses at 
the moment too.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: More ATi driver madness

[Bob Sanders]

Duncan, mused, then expounded:
> Bob Sanders <rsanders@sgi.com> posted 20060814151338.GA102938@sgi.com,
> excerpted below, on  Mon, 14 Aug 2006 08:13:38 -0700:
> 
> > Gfx, especially 3D, is about memory bandwidth.  Move the memory out
> > of direct contact with the gpu chip - say via a socket, and it's
> > necessary to drop the frequency that the memory interface runs at.
> > It's basic electronics - add more capacitaince and inductance, and
> > the speed of the interface goes down.
> 
> Two factors in counter-point.  We're talking FB-DIMM tech time this comes
> out, and this will be using upgrades to the same memory controller on the
> CPU (only in this case GPU) AMD is already using to maintain its lead in
> multi-socket performance against Intel (even while Intel's Core-Duo has
> caught up at the low single-socket end).
>

Problems with this approach - it takes 4 FB-DIMMs to a special northbridge
for Intel to acieve 21.5 GB/s bandwidth to the cpu in a Woodcrest based server.
And that's a fair chunk of change for the northbridge and dimms.  Plus the
increased latency.  Btw - the current DDR-2 controller in the AMD Socket AM-2s
can talk to FB-DIMMs.  It's not allowed to yet, probably not tweaked up right
and AMD like to take things slowly so that risk is minimized - one or two
things at a time.   But the current memory controller should work 
with FB-DIMMs.

While 21.5 GB/s may seem fast, that's the peak speed, not the sustained
bandwidth.  Effective bandwidth is going to be less.  And it's a lot
cheaper to build a dedicated PCIe card with memory than to even purchase
one stick of FB-DIMM memory.  Even with just 2 DIMMS, DDR-2 or FB-DIMMS,
the memory bandwidth peaks around 10.5 GB/s with a sustained bandwidth
of around 8 GB/s.  Still less than the 12.8 GB/s an Nvidia 600GS card
attains while retailing for $109.
 
> > Remember, Intel doesn't make real 3D Gfx chips.  Unlike, Nvidia and
> > Ati, Intel does most of it's 3D processing in software.  Thus opening up
> > the chips specs and driver has little impact on any IP outside of Intel as
> > it doesn't expose any IP that might belong to Micrsoft or SGI.
> 
> Does <> will do.  With aeroglass driving dx10 requirements, the low end of
> the gfx market is about to get very legacy, very fast.  Their new chips
> do more in hardware because they must, due to the performance
> requirements.  That's the reason Intel's latest free driver release made
> the headlines in the FLOSS world -- it's the first time we've had full
> sources to something that capable.
>


Based on all I've read, what I'm putting forth is strictly my take on the
situation.  No source to go to, just speculation.  What Intel is doing
is stopping Gfx development any laying off most of it's Gfx Engineering
staff.  They are outsourcing most of the IP development by licensing
cores from Imagination Technologies - the PowerVR SGX, that has been widely
reported, but not explicitly confirmed (unless I missed it).  As the SDK
for the PowerVR is already publically available, all Intel did was go
and say - all this old crap we made and are abandoning, well - here are
the specs for it.  And since the new cores already have an open api and
sdk, we'll just "say" we're opening the development to the Open Source
Community, because, well, it already is.  Great Marketing move.

Of course I could be wrong on this, but time will tell.

Bob
-  
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: More ATi driver madness

[Bob Sanders]

Bob Sanders, mused, then expounded:
> 
> of around 8 GB/s.  Still less than the 12.8 GB/s an Nvidia 600GS card
                                                             ^--7600GS

Apologies,

Bob
-  
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: More ATi driver madness

[Richard Fish]

On 8/13/06, Duncan <1i5t5.duncan@cox.net> wrote:
> By the time I'm looking for a platform upgrade in 2-4 years (I figure back
> to a single CPU again by then, but quad-core, maybe even octi-core),

I'm betting 8-core, with 2-4 as GPUs. :-)

-Richard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Mark Haney]

Antoine Martin wrote:
> I had the same issue with xorg 6.8
>
> fixed by using xorg 7.0 or 7.1 and latest ati drivers.
>
> There is also an option in xorg.conf you can use to disable the 
> acceleration for that particular problem - can't remember which one 
> (or just disable acceleration globally)
>
> I can't wait for ATI to open-source their crappy slaveryware drivers.
>
> Antoine
> (2560x1920 LCD with accelerated 3D :)
>
Sorry, but that didn't fix the problem, it's exactly the same with 
no_accel set to yes as it is with it set to no.



-- 
Mark Haney
Sr. Systems Administrator	
ERC Broadband


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Roman Zilka]

I ran into that too. Solved it by meddling with the AGP Aperture
size parameter in xorg.conf (aticonfig will give you the exact syntax).
My HW is an HP nx6125 laptop with a PCIE Radeon X300, shared mem.

Regards
-Roman


> Good news:  After two months of screwing with modular X and the ATI drivers, I 
> FINALLY got an X session on my Compaq R4000.
> 
> Bad news: For some incredibly stupid reason, the session graphics are 
> horrible.  When I log in, the desktop looks fine, but all my console sessions 
> are transparent and impossible to read and every window I close hangs out on 
> the desktop like a ghost.  I've used eselect to configure openGL for the ati 
> interface, the module (latest driver) loads and i even get the correct info 
> in 'fglrxinfo'.  Not to mention I get 1280x800 resolution.  But if this 
> graphics problem can't be fixed, it's impossible to use that way.
> 
> Does anyone have any possible clue what I can do to fix that?
> 
> 
> -- 
> Fere libenter homines id quod volunt credunt.
> 
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Mark Haney]

On Monday 14 August 2006 06:56, Roman Zilka wrote:
> I ran into that too. Solved it by meddling with the AGP Aperture
> size parameter in xorg.conf (aticonfig will give you the exact syntax).
> My HW is an HP nx6125 laptop with a PCIE Radeon X300, shared mem.
>
> Regards
> -Roman
>

Okay, I"m not seeing it in aticonfig.  And everything I googled about it 
mentions setting that up in BIOS, not in xorg.conf.  Can you give me the 
line(s) from your xorg.conf for me to look at?


-- 
Fere libenter homines id quod volunt credunt.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Roman Zilka]

> > I ran into that too. Solved it by meddling with the AGP Aperture
> > size parameter in xorg.conf (aticonfig will give you the exact syntax).
> > My HW is an HP nx6125 laptop with a PCIE Radeon X300, shared mem.
> >
> > Regards
> > -Roman
> >
> 
> Okay, I"m not seeing it in aticonfig.  And everything I googled about it 
> mentions setting that up in BIOS, not in xorg.conf.  Can you give me the 
> line(s) from your xorg.conf for me to look at?

I don't have that xorg.conf within reach now, but aticonfig's
--max-gart-size=NUMBER parameter governs over the respective
xorg.conf option. Try 32, 64, 128, 256 or nothing at all. Experimenting with
	Option	"UseInternalAGPGART" "yes"  # or "no"
in combination with various GART sizes might also be worth the time spent.
My X works with GART size 128 and the UseInternalAGPGART option omitted.

-Roman
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Mark Haney]

On Monday 14 August 2006 08:49, Roman Zilka wrote:

> I don't have that xorg.conf within reach now, but aticonfig's
> --max-gart-size=NUMBER parameter governs over the respective
> xorg.conf option. Try 32, 64, 128, 256 or nothing at all. Experimenting
> with Option	"UseInternalAGPGART" "yes"  # or "no"
> in combination with various GART sizes might also be worth the time spent.
> My X works with GART size 128 and the UseInternalAGPGART option omitted.
>
> -Roman

Here's what I get when I run aticonfig with that command:

aticonfig: unrecognized option `--max-gart-size=128'
aticonfig: parsing the command-line failed.

AFAIK, I have the latest drivers, I just updated them last week.  Any ideas?


-- 
Fere libenter homines id quod volunt credunt.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Roman Zilka]

> > I don't have that xorg.conf within reach now, but aticonfig's
> > --max-gart-size=NUMBER parameter governs over the respective
> > xorg.conf option. Try 32, 64, 128, 256 or nothing at all. Experimenting
> > with Option	"UseInternalAGPGART" "yes"  # or "no"
> > in combination with various GART sizes might also be worth the time spent.
> > My X works with GART size 128 and the UseInternalAGPGART option omitted.
> >
> > -Roman
> 
> Here's what I get when I run aticonfig with that command:
> 
> aticonfig: unrecognized option `--max-gart-size=128'
> aticonfig: parsing the command-line failed.
> 
> AFAIK, I have the latest drivers, I just updated them last week.  Any ideas?


I use ati-drivers-8.27.10-r1. It's the lastest masked version - maybe only
such recent aticonfig knows the option.
Anyway, the appropriate xorg.conf line is:

Option	"MaxGARTSize"	"128"

(in the "Device" section).

That reminds me - I use stable gentoo-sources and when trying to
emerge the latest stable ati-drivers, the fglrx.ko
module doesn't get correctly compiled.
I.e. the emerge process won't fail and stop to emphasize a fatal error.
Check if you can 'modprobe fglrx'. I only succeed with the latest masked
ati-drivers.

-Roman
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Mark Haney]

On Tuesday 15 August 2006 14:33, Roman Zilka wrote:
>
> I use ati-drivers-8.27.10-r1. It's the lastest masked version - maybe only
> such recent aticonfig knows the option.
> Anyway, the appropriate xorg.conf line is:
>
> Option	"MaxGARTSize"	"128"
>
> (in the "Device" section).
>
> That reminds me - I use stable gentoo-sources and when trying to
> emerge the latest stable ati-drivers, the fglrx.ko
> module doesn't get correctly compiled.
> I.e. the emerge process won't fail and stop to emphasize a fatal error.
> Check if you can 'modprobe fglrx'. I only succeed with the latest masked
> ati-drivers.
>
> -Roman

Thanks for that, I appreciate it.  As for the drivers loading, fglrx gets 
loaded just fine, so I can't account for why you are having trouble.  Without 
the 'USEInternalAGPGart' set to no, X hangs about half way into loading KDE.  
I hope adding the above option will fix that and make the screen work like it 
should.

-- 
Fere libenter homines id quod volunt credunt.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] More ATi driver madness

[Mark Haney]

On Tuesday 15 August 2006 14:33, Roman Zilka wrote:

>
> I use ati-drivers-8.27.10-r1. It's the lastest masked version - maybe only
> such recent aticonfig knows the option.
> Anyway, the appropriate xorg.conf line is:
>
> Option	"MaxGARTSize"	"128"
>
> (in the "Device" section).
>
> That reminds me - I use stable gentoo-sources and when trying to
> emerge the latest stable ati-drivers, the fglrx.ko
> module doesn't get correctly compiled.
> I.e. the emerge process won't fail and stop to emphasize a fatal error.
> Check if you can 'modprobe fglrx'. I only succeed with the latest masked
> ati-drivers.
>
> -Roman

I tried the config option, it didn't work.  I'm really frustrated at the 
moment, so I think I'll leave it alone for a while.  What I don't get is why 
the same set of configuration options works just fine in Kubuntu and not in 
Gentoo.  Go figure.


-- 
Fere libenter homines id quod volunt credunt.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
-- 
gentoo-amd64@gentoo.org mailing list