HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

I've brought this up the following subject before on LKML, but it wasn't 
really resolved, and also, management at my company (Tech Source) has 
only now started to warm up to my idea.

To begin with, I'm an ASIC/FPGA designer, as well as software developer. 
  My own projects here include X11 drivers (DDX modules) for OpenWindows 
and XFree86, as well as the bulk of a graphics ASIC which we use in our 
air traffic control systems.  The point:  we have a lot of experience 
with graphics hardware and system software.

In short, what I have been proposing to my superiors is the development 
of a graphics card specifically for open source systems.  This means 
full disclosure on all register interfaces so that no one has to deal 
with anything closed source (BIOS included).  The goal here is to 
produce a graphics card which is a Free Software geek's dream in terms 
of openness.  If Tech Source (me being its avatar) can develop a 
relationship with the Linux (and BSD) community, users and developers 
can get a product that they want without being locked out by hardware 
vendors that feel they have to protect every last little bit of IP 
relating to their products.  The EXPRESS PURPOSE of this product is to 
be free-software-friendly.

I can produce more detail later, but first, some characteristics and 
advantages of what I'm proposing:

- x86 BIOS/OpenBoot/OpenFirmware code under BSD and GPL license
- kernel drivers under BSD and GPL license
- X11 module under MIT license
- flashable PROM so that boot code can be added for more platforms
- usable as the console on any platform that can take a PCI, AGP, or 
PCI-Express card
- downloadable schematic for the circuit board
- FPGA-based graphics engine so it's reprogrammable
- instructions on how to reprogram the FPGA, so it's hackable
- if we discontinue a product, we may release the Verilog code for the FPGA
- Since this is designed to be open-source-friendly, we want to play by 
the rules of the open-source community.
- Tech Source would actively participate in the development and 
maintenance of our own drivers.
- We will actually pay attention to problems and concerns raised by 
users and developers.
- We won't be control-freaks.

The desired effects, for developers, of these characteristics would include:

- The card "just works" with Linux because, maybe, the drivers would go 
into main-line
- The drivers are not a debugging/tainting nightmare, since they are 
open source
- The drivers are easy to work on, since you don't ever have to guess 
about anything.
- The drivers are easy to debug because
     (a) we document everything, and
     (b) we'll talk to you.
- People will think it's cool and want to hack it.

The desired effect for end users:

- It just works.
- It's not a liability for system stability.


The reason this idea came up is because I, as a user of Linux, am often 
frustrated by the lack of open-source support for graphics cards which 
are not "pre-owned".  Sure, SOME companies release specs so that we can 
develop open source drivers, but those cards tend to be prohibitively 
expensive, slower than their cheaper counterparts from ATI or nVidia, 
and they STILL don't document the internals of the BIOS so that the card 
can be ported to a non-x86 system.  Furthermore, since all these vendors 
focus exclusively on Windows, they don't give much help to open source 
developers who may produce drivers which work but which are sub-optimal 
in performance or stability.  (Here, I have to make the obligatory CYA 
statement that there is nothing wrong with their business models -- it's 
just unfortunate for Linux users.)

By contrast, what _I_ want to produce would be supportable by both Tech 
Source (mostly me), and also by anyone else who wants to hack it.  I 
would be one of the primary designers of the chip, so I would know it 
inside and out.  I would also be the primary driver developer, with the 
help of others on LKML.  So, I would be here to help, but hopefully, the 
documentation would be clear enough (and the drivers I write, complete 
enough) so that no one gets stuck having to guess or reverse-engineer 
anything.

There are, however, some caveats.  Tech Source is not willing to foot a 
lot of development capital for this project.  That means we can't spend 
an excessive amount of time on developing a fully virtex shading 
programmable 3D engine, and my superiors are not willing, as yet, to 
give me sufficient funding to produce an ASIC.  What this means is that 
the design has to be small and simple and focus primarily on 2D 
performance so that it can fit into an FPGA.

A 2D rendering engine is easy to parallelize, so although we can't clock 
the FPGA design as fast as an ASIC design, we can easily saturate a 
128-bit DDR memory bus at, say, 200Mhz.  A 3D rendering engine, on the 
other hand, is a beast, and our performance will be less than stellar 
(although certainly better than doing it all with the host CPU).  (If 
there IS sufficient demand, we would LOVE to produce a 
performance-competitive 3D chip, but keep in mind that that would be a 
huge and expensive development effort, and would result in an expensive 
product.)

The advantage of having this in an FPGA is that we can add features and 
fix bugs as necessary, and provide a flash utility for everyone to use 
to upgrade.  You run the utility, cycle power, and you're set.  This 
way, if some kernel developer who is concerned about latency decides 
that having an interrupt signal occur on some event that we don't 
already cover, we can add the feature and supply a new bitfile in 
relatively short order.  You wouldn't have to buy a new card to upgrade.

All of this, however, is a pipe-dream if it's not cost effective for 
Tech Source.  I have to make a very strong case to the CEO.  I think 
everyone at this company is excited about the IDEA of developing this 
product.  But we have no clue what the market is like.  It's not worth 
it to us to develop this if only a handful of kernel hackers are going 
to buy it.  We're guessing that some workstation and server vendors who 
deal in Linux would like to resell this sort of product, because if our 
drivers are in the mainline Linux kernel, it'll "just work".  On the 
other hand, maybe they're all perfectly happy with the graphics 
controllers that come built into many Intel motherboards and have "good 
enough" support.

The very fact that no other company has openly considered going to the 
level of openness that I'm proposing might suggest that what I'm 
proposing is completely out of touch with reality, because it just can't 
be profitable.

So, here are some questions to answer:

(1) Would the sales volumes of this product be enough to make it worth 
producing (ie. profitable)?
(2) How much would you be willing to pay for it?
(3) How do you feel about the choice of neglecting 3D performance as a 
priority?  How important is 3D performance?  In what cases is it not?
(4) How much extra would you be willing to pay for excellent 3D performance?
(5) What's most important to you, performance, price, or stability?

Feel free to insert your own questions and answers here.  Remember, I'm 
an engineer.  My understanding of business is dilettantish at best.

I haven't worked out a complete design spec for this product.  The 
reason is that what we think people want and what people REALLY want may 
not be congruent.  If you have a good idea for a piece of graphics 
hardware which you think would be beneficial to the free software 
community (and worth it for a company to produce), then Tech Source, as 
a graphics company, might be willing to sell it.


Oh, and before you flame me, YES, I AM doing market research for Tech 
Source here, but NO, I am not doing it at THEIR request.  They told me 
that if I wanted to do this, I would have to make a case for it, and 
that's what I'm trying to do.  This is MY idea, and I would personally 
love to have a product like what I'm describing.  I would also 
personally very much enjoy WORKING on such a project, because then I 
wouldn't have to do more boring stuff.  There's a lot of selfishness 
here on my part.  But it's selfishess that I hope everyone else will 
benefit from.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Andre Eisenbach]

On Wed, 20 Oct 2004 18:02:51 -0400, Timothy Miller
<miller@techsource.com> wrote:
> In short, what I have been proposing to my superiors is the development
> of a graphics card specifically for open source systems. 

That sounds truly great! However...

If the graphics card mostly supports 2D initially, it's really not
much better then just about any off the shelf graphics card with VESA
drivers. As in, the hardware doesn't need to be open for just that.
Most (all?) the frustration in Linux graphics card land comes from
unsupported/closed 3D drivers.

I obviously understand that it would be very costly to try to catch up
with ATI/NVidia in 3D land, but if you manage to get an open platform
out there which has great 3D potential (hardware wise) and is easily
programmable, I am sure the open source community would _love_ to try
to jointly develop fast 3D firmware (and drivers). That way Techsource
won't have to front the cost (other than for hardware).

So a open, programmable 3D hardware platform would open the door for
open source 3D engine innovation.

If you get this off the road, that would be very impressive and most
exciting to watch.

However, if you're only going to focus on 2D, I don't see the
excitement. 2D works pretty much for everyone, no?

Cheers,
    Andre

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jon Valvatne]

Andre Eisenbach <int2str <at> gmail.com> writes:

> 
> However, if you're only going to focus on 2D, I don't see the
> excitement. 2D works pretty much for everyone, no?
> 

Except for those of us who want to suspend to RAM and have the
video card wake up when we resume...

Jon

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Jon Valvatne wrote:
> Andre Eisenbach <int2str <at> gmail.com> writes:
> 
> 
>>However, if you're only going to focus on 2D, I don't see the
>>excitement. 2D works pretty much for everyone, no?
>>
> 
> 
> Except for those of us who want to suspend to RAM and have the
> video card wake up when we resume...


And with the open approach, it could be done with my full support.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Pavel Machek]

Hi!

> > However, if you're only going to focus on 2D, I don't see the
> > excitement. 2D works pretty much for everyone, no?
> > 
> 
> Except for those of us who want to suspend to RAM and have the
> video card wake up when we resume...

...hmm, but you probably want to run it on your notebook, right?

Otherwise toshiba 4030cdt, toshiba sattelite p10-554 are "known
working" systems.
							Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? [u]

[Martin Schlemmer [c]]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

On Wed, 2004-10-20 at 18:02 -0400, Timothy Miller wrote:

Hi,

> So, here are some questions to answer:
> 
> (1) Would the sales volumes of this product be enough to make it worth 
> producing (ie. profitable)?

No idea - I for one would think that most gamer Linux users will buy
it if its got the performance 3D wise - many others that only want 2D,
or at least accelerated render support in X, as well as XV, etc.

> (2) How much would you be willing to pay for it?

I am not that a big a gamer, so my Geforce 5700 ultra is fine for my
needs.  If the card have relative performance to that, and drivers is
the same quality as nvidia's (but hopefully better, and really not ati's
crappy standard), then I would fork the same amount as you would for an
5700, or slightly more if not that much.  Not sure what that amounts to.

> (3) How do you feel about the choice of neglecting 3D performance as a 
> priority?  How important is 3D performance?  In what cases is it not?

Yeah, I think it is important - just for decent performance in
gnome/kde, you need a card with accel RENDER support, as well as XV/GL
for video.  Not to talk about those of us that are heavy gamers, or like
me who like my ut2004/quake3/nvn once or twice a week.

> (4) How much extra would you be willing to pay for excellent 3D performance?

Well, above price was for performance on par or just below a 5700.  I
know it will be more expensive to develop, so if it was a bit more
expensive than the same class nvidia/ati, but with better drivers, I
would be sold.  The reality of the issue is just while I love my linux,
I rather taint my kernel than crappy X performance or no gaming now and
then.

> (5) What's most important to you, performance, price, or stability?
> 

Performance and stability, but it being 3 times more expensive than
on par nvidia/ati cards wont cut it.


Hope that is not too vague to help a bit.


Regards,

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? [u]

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

Salut,

On Thu, Oct 21, 2004 at 12:19:07AM +0200, Martin Schlemmer [c] wrote:
> > (3) How do you feel about the choice of neglecting 3D performance as a 
> > priority?  How important is 3D performance?  In what cases is it not?
> 
> Yeah, I think it is important - just for decent performance in
> gnome/kde, you need a card with accel RENDER support, as well as XV/GL
> for video.  Not to talk about those of us that are heavy gamers, or like
> me who like my ut2004/quake3/nvn once or twice a week.

OpenGL should be  enough to get RENDER working. The  rest may be based
on.

> The reality  of the issue  is just while  I love my linux,  I rather
> taint my kernel than crappy X performance or no gaming now and then.

The NVidia  driver hangs my system  after around 10 minutes,  and if I
write additional media drivers and other things, I sometimes end up with

if (ptr)
	ptr->blah(ptr);

failing with ptr being dereferenced as a NULL pointer, which shouldn't
happen as I just checked it.

To  people developing  the  kernels, NVidia  and  other closed  source
drivers are desasterous,  as you can't seem to find  out what the hell
they're doing, apart from graphics.

			    Tonnerre

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable? [u]

[Martin Schlemmer [c]]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

On Sun, 2004-10-24 at 10:24 +0200, Tonnerre wrote:
> Salut,
> 
> On Thu, Oct 21, 2004 at 12:19:07AM +0200, Martin Schlemmer [c] wrote:
> > > (3) How do you feel about the choice of neglecting 3D performance as a 
> > > priority?  How important is 3D performance?  In what cases is it not?
> > 
> > Yeah, I think it is important - just for decent performance in
> > gnome/kde, you need a card with accel RENDER support, as well as XV/GL
> > for video.  Not to talk about those of us that are heavy gamers, or like
> > me who like my ut2004/quake3/nvn once or twice a week.
> 
> OpenGL should be  enough to get RENDER working. The  rest may be based
> on.
> 
> > The reality  of the issue  is just while  I love my linux,  I rather
> > taint my kernel than crappy X performance or no gaming now and then.
> 
> The NVidia  driver hangs my system  after around 10 minutes,  and if I
> write additional media drivers and other things, I sometimes end up with
> 
> if (ptr)
> 	ptr->blah(ptr);
> 
> failing with ptr being dereferenced as a NULL pointer, which shouldn't
> happen as I just checked it.
> 
> To  people developing  the  kernels, NVidia  and  other closed  source
> drivers are desasterous,  as you can't seem to find  out what the hell
> they're doing, apart from graphics.
> 

I did not say I like it, but its better than nothing.  My system here at
home had an uptime of near 20 days before I rebooted for 2.6.9-mm1 with
nvidia driver (intel i875), but at work (nforce1) it freezes if I scroll
in gnumeric with same driver.  I guess it depends what setup.


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[David Lang]

On Wed, 20 Oct 2004, Timothy Miller wrote:

> Sure, SOME companies release specs so that we can develop 
> open source drivers, but those cards tend to be prohibitively expensive, 
> slower than their cheaper counterparts from ATI or nVidia...

Tim, I think this is the key problem. with the current ATI/nVidia cards 
beign in the $50 range (with other cards on the market for as low as 
$30) are you really going to be able to come up with a card that's price 
competitive? (completely ignoring the performance question)

as for your other question of if an open approach could be viable (after 
all nobody does it today so doesn't that proove it isn't)

this is where there is a significant disagreement. the Linux folks think 
that such openess would be very viable and the companies are just pursuing 
a legacy approach, but the companies are scared to open things up becouse 
they don't believe that they would remain viable.

since nobody has done this yet (for video cards anyeay) there is no proof 
one way or the other.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

David Lang wrote:
> On Wed, 20 Oct 2004, Timothy Miller wrote:
> 
>> Sure, SOME companies release specs so that we can develop open source 
>> drivers, but those cards tend to be prohibitively expensive, slower 
>> than their cheaper counterparts from ATI or nVidia...
> 
> 
> Tim, I think this is the key problem. with the current ATI/nVidia cards 
> beign in the $50 range (with other cards on the market for as low as 
> $30) are you really going to be able to come up with a card that's price 
> competitive? (completely ignoring the performance question)

I've just had a discussion with our senior ASIC designer, and we came up 
with ball-park numbers for the cost of a first run of boards in a 
quantity of 1000.

FPGA              Anywhere from $50 to $500, depending on logic area
Power regulators  $10 - $40
RAM               $24 (for 128 megs)
DAC               $2
DVI xmit          $8
PCB               $7
Connectors, etc.  $4
PROM chips        $5

Given the sum of that, whatever it turns out to be, for it to be worth 
while in quantities that small, we'd have to make roughly that much 
again in profit (assuming development cost and development time are 
something like proportional).

If the quantities were a lot higher, then prices go down for everything. 
  For instance, we can take the FPGA design and have the vendor turn it 
directly into an ASIC.  What you get is something that requires 20% the 
chip area and runs twice as fast, and the per-chip cost is a lot lower, 
but there's an NRE of $100K, and then you can't reprogram the chip. 
(Maybe there should be 'fixed' and 'reprogrammable' versions of the 
product.)

> 
> as for your other question of if an open approach could be viable (after 
> all nobody does it today so doesn't that proove it isn't)
> 
> this is where there is a significant disagreement. the Linux folks think 
> that such openess would be very viable and the companies are just 
> pursuing a legacy approach, but the companies are scared to open things 
> up becouse they don't believe that they would remain viable.

Right.  There are two problems that arise here.  One is that another 
company might try to pirate our design (it's an FPGA bitfile on a PROM, 
after-all), and although that is illegal, litigation is something to be 
avoided.  The second problem is that another, much larger, company would 
look at all of our published materials, produce something compatible, 
and then undercut us out of this particular market.  While I can 
certainly appreciate the capitalist value of that sort of competition, I 
am in the situation where that competition would simply kill my project 
instantly.

I like to pick on Stallman and his excessive idealism, but in this case, 
I want his utopian ideal to work.  I want to have a piece of hardware 
which is totally compatible with the ideal.  The problem is that, in 
some markets, the ideal may be completely unrealistic.

> since nobody has done this yet (for video cards anyeay) there is no 
> proof one way or the other.

Well, if Tech Source management decides that this project isn't worth 
the effort, you'll have a small piece of circumstantial evidence that 
leans toward "it's not viable".  I personally want to find a way to make 
it work.

To the open source community, this is a golden opportunity to directly 
influence the design of a piece of hardware which fits their ideals. 
For me personally, this is a golden opportunity to work on a project 
from which I'll derive an immense amount of enjoyment.  For both 
accounts, I'm desperate to find a way to make it work.  :)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[David Lang]

On Thu, 21 Oct 2004, Timothy Miller wrote:

> David Lang wrote:
>> On Wed, 20 Oct 2004, Timothy Miller wrote:
>> 
>> since nobody has done this yet (for video cards anyeay) there is no proof 
>> one way or the other.
>
> Well, if Tech Source management decides that this project isn't worth the 
> effort, you'll have a small piece of circumstantial evidence that leans 
> toward "it's not viable".  I personally want to find a way to make it work.
>
> To the open source community, this is a golden opportunity to directly 
> influence the design of a piece of hardware which fits their ideals. For me 
> personally, this is a golden opportunity to work on a project from which I'll 
> derive an immense amount of enjoyment.  For both accounts, I'm desperate to 
> find a way to make it work.  :)
>

Tim, in this case you are not just testing the openess idea, you are also 
testing the low-volume, high-cost, but flexible idea. and that idea has 
never had a large market

you are in something of a catch-22 here. due to the risk you can only do 
things with a relativly small initial investment, but with a larger 
initial investment you could make much cheaper (and therefor much more 
popular) cards. where's a billionare looking to Do Good Things (TM) when 
you need one ;-)

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

David Lang wrote:
> On Thu, 21 Oct 2004, Timothy Miller wrote:
> 
>> David Lang wrote:
>>
>>> On Wed, 20 Oct 2004, Timothy Miller wrote:
>>>
>>> since nobody has done this yet (for video cards anyeay) there is no 
>>> proof one way or the other.
>>
>>
>> Well, if Tech Source management decides that this project isn't worth 
>> the effort, you'll have a small piece of circumstantial evidence that 
>> leans toward "it's not viable".  I personally want to find a way to 
>> make it work.
>>
>> To the open source community, this is a golden opportunity to directly 
>> influence the design of a piece of hardware which fits their ideals. 
>> For me personally, this is a golden opportunity to work on a project 
>> from which I'll derive an immense amount of enjoyment.  For both 
>> accounts, I'm desperate to find a way to make it work.  :)
>>
> 
> Tim, in this case you are not just testing the openess idea, you are 
> also testing the low-volume, high-cost, but flexible idea. and that idea 
> has never had a large market
> 
> you are in something of a catch-22 here. due to the risk you can only do 
> things with a relativly small initial investment, but with a larger 
> initial investment you could make much cheaper (and therefor much more 
> popular) cards. where's a billionare looking to Do Good Things (TM) when 
> you need one ;-)


Yeah!  I wonder if there are any rich investors reading this right now 
who would like to invest in this project.  :)

I'm sure the CEO would be elated to have that happen!  :)

Based on past experience, I think a few million dollars would do it.  :)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Antonio Vargas]

On Thu, 21 Oct 2004 14:15:06 -0400, Timothy Miller
<miller@techsource.com> wrote:
> 
> 
> David Lang wrote:
> > On Thu, 21 Oct 2004, Timothy Miller wrote:
> >
> >> David Lang wrote:
> >>
> >>> On Wed, 20 Oct 2004, Timothy Miller wrote:
> >>>
> >>> since nobody has done this yet (for video cards anyeay) there is no
> >>> proof one way or the other.
> >>
> >>
> >> Well, if Tech Source management decides that this project isn't worth
> >> the effort, you'll have a small piece of circumstantial evidence that
> >> leans toward "it's not viable".  I personally want to find a way to
> >> make it work.
> >>
> >> To the open source community, this is a golden opportunity to directly
> >> influence the design of a piece of hardware which fits their ideals.
> >> For me personally, this is a golden opportunity to work on a project
> >> from which I'll derive an immense amount of enjoyment.  For both
> >> accounts, I'm desperate to find a way to make it work.  :)
> >>
> >
> > Tim, in this case you are not just testing the openess idea, you are
> > also testing the low-volume, high-cost, but flexible idea. and that idea
> > has never had a large market
> >
> > you are in something of a catch-22 here. due to the risk you can only do
> > things with a relativly small initial investment, but with a larger
> > initial investment you could make much cheaper (and therefor much more
> > popular) cards. where's a billionare looking to Do Good Things (TM) when
> > you need one ;-)
> 
> 
> Yeah!  I wonder if there are any rich investors reading this right now
> who would like to invest in this project.  :)
> 
> I'm sure the CEO would be elated to have that happen!  :)
> 
> Based on past experience, I think a few million dollars would do it.  :)

I'd gladly pay $200 to have a hackable display device which I could plug into
x86, amd64, ppc and m68k boxes :)

[ goes back to remeber the "golden days" of having video hardware info ]


-- 
Greetz, Antonio Vargas (aka winden of network)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Raphael Jacquot]

On Thu, 2004-10-21 at 10:25 -0700, David Lang wrote:

> 
> Tim, in this case you are not just testing the openess idea, you are also 
> testing the low-volume, high-cost, but flexible idea. and that idea has 
> never had a large market
> 
> you are in something of a catch-22 here. due to the risk you can only do 
> things with a relativly small initial investment, but with a larger 
> initial investment you could make much cheaper (and therefor much more 
> popular) cards. where's a billionare looking to Do Good Things (TM) when 
> you need one ;-)
> 
> David Lang
> 

countering your argument, www.digium.com is doing just that, low volume
telephony cards.
granted, the economics is different, as their price-point is 10% of the
big player's price points, but the concept is similar.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

Salut,

On Thu, Oct 21, 2004 at 10:25:35AM -0700, David Lang wrote:
> where's a  billionare looking to Do  Good Things (TM)  when you need
> one ;-)

Wasn't  Steve Jobs  willing to  be a  such? Shall  we CC  him  on that
discussion?

			    Tonnerre

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Stephen Wille Padnos]

Tonnerre wrote:

>Salut,
>
>On Thu, Oct 21, 2004 at 10:25:35AM -0700, David Lang wrote:
>  
>
>>where's a  billionare looking to Do  Good Things (TM)  when you need
>>one ;-)
>>    
>>
>
>Wasn't  Steve Jobs  willing to  be a  such? Shall  we CC  him  on that
>discussion?
>
>			    Tonnerre
>  
>
I think you mean Steve Wzniak.  Except the billionaire part :)

- Steve

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Stephen Wille Padnos]

Stephen Wille Padnos wrote:

> Tonnerre wrote:
>
>> Salut,
>>
>> On Thu, Oct 21, 2004 at 10:25:35AM -0700, David Lang wrote: 
>>
>>> where's a  billionare looking to Do  Good Things (TM)  when you need
>>> one ;-)   
>>
>> Wasn't  Steve Jobs  willing to  be a  such? Shall  we CC  him  on that
>> discussion?
>>
>>                 Tonnerre 
>
> I think you mean Steve Wzniak.  Except the billionaire part :)

Of course, that's supposed to be Wozniak.  /me can't type.

- Steve

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Gene Heskett]

On Sunday 24 October 2004 21:33, Stephen Wille Padnos wrote:
>Tonnerre wrote:
>>Salut,
>>
>>On Thu, Oct 21, 2004 at 10:25:35AM -0700, David Lang wrote:
>>>where's a  billionare looking to Do  Good Things (TM)  when you
>>> need one ;-)
>>
>>Wasn't  Steve Jobs  willing to  be a  such? Shall  we CC  him  on
>> that discussion?
>>
>>       Tonnerre
>
>I think you mean Steve Wzniak.  Except the billionaire part :)
                       ^Wozniak
>- Steve
-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Christian Leber]

On Thu, Oct 21, 2004 at 10:46:45AM -0400, Timothy Miller wrote:

> I've just had a discussion with our senior ASIC designer, and we came up 
> with ball-park numbers for the cost of a first run of boards in a 
> quantity of 1000.
> 
> FPGA              Anywhere from $50 to $500, depending on logic area

About what FPGA are you thinking?
And you have to add the cost for PCI express support... will PCI express
even work on such a small FPGA?

Regards
Christian Leber

-- 
http://www.nosoftwarepatents.com

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Christian Leber wrote:
> On Thu, Oct 21, 2004 at 10:46:45AM -0400, Timothy Miller wrote:
> 
> 
>>I've just had a discussion with our senior ASIC designer, and we came up 
>>with ball-park numbers for the cost of a first run of boards in a 
>>quantity of 1000.
>>
>>FPGA              Anywhere from $50 to $500, depending on logic area
> 
> 
> About what FPGA are you thinking?

At the time, I do not have an estimate for the logic area required for a 
3D design.

I don't even know what size FPGA would be required to hold the logic 
that is in the graphics ASIC I (mostly I) designed for our ATC products. 
  It's a high-performance 2D engine designed more for driving high-res 
displays (2048x2048, 2560x2048, 3840x2400, etc.) than for fast 
rendering, although it is very fast, and it's designed to be efficient 
at all of the things that an ATC system needs to render.  Anyhow, as a 
benchmark, I asked our senior ASIC guy what size FPGA would be required 
to hold it.  He's going to get back with me on that.

In any event, whatever that is, we'll need several times that for a fast 
3D core.

> And you have to add the cost for PCI express support... will PCI express
> even work on such a small FPGA?

There are already Xilinx chips that have PCI express support in them. 
For AGP and PCI, I would just take the PCI core for our existing design 
and modify it for the new purpose.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Kendall Bennett]

David Lang <david.lang@digitalinsight.com> wrote:

> On Wed, 20 Oct 2004, Timothy Miller wrote:
> 
> > Sure, SOME companies release specs so that we can develop 
> > open source drivers, but those cards tend to be prohibitively expensive, 
> > slower than their cheaper counterparts from ATI or nVidia...
> 
> Tim, I think this is the key problem. with the current ATI/nVidia
> cards beign in the $50 range (with other cards on the market for
> as low as $30) are you really going to be able to come up with a
> card that's price competitive? (completely ignoring the
> performance question) 
> 
> as for your other question of if an open approach could be viable
> (after all nobody does it today so doesn't that proove it isn't) 
> 
> this is where there is a significant disagreement. the Linux folks
> think that such openess would be very viable and the companies are
> just pursuing a legacy approach, but the companies are scared to
> open things up becouse they don't believe that they would remain
> viable. 
> 
> since nobody has done this yet (for video cards anyeay) there is
> no proof one way or the other. 

Wrong. Companies *have* tried to go down the Open Source route and it did 
not work out for them. ATI in particular. At one point ATI released all 
the register level information and in fact released sample 3D driver 
source code to the community for the early Radeon chipsets. Unfortunately 
the Linux and Open Source community never stepped up to the plate to 
support ATI in this effort. There are solid business reasons that ATI has 
explained to me for why ATI decided to give up on the Open Source 
approach and go back to proprietary 3D drivers for Linux. 

For 2D they continue to maintain XFree86/X.org drivers with full source 
code for the community, just not 3D.

If someone wishes to go down this route, more power to them. But I don't 
think it is a viable way to make money for a business. The biggest 
problem is that even if every active Linux or Open Source kernel 
developer decided to buy one of these cards, that is a pretty small 
market. The unfortunate fact I have come to realise is that there is a 
very large contingent of Linux end users out there who just want free 
stuff. Free as in free beer. They could care less whether the source code 
is available as long as they don't pay for it. Those same users are also 
more than happy to install ATI or NVIDIA proprietary kernel modules and 
taint their kernel so they can get 3D support when running Linux and 
still run their favorite games at full speed under Windows. Those same 
users probably won't pay a premium to get a 3D card that is slower than 
an ATI or NVIDIA just because it has source code for the drivers.

Sad but true IMHO.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Tobias Diedrich]

Kendall Bennett wrote:

> Wrong. Companies *have* tried to go down the Open Source route and it did 
> not work out for them. ATI in particular. At one point ATI released all 
> the register level information and in fact released sample 3D driver 
> source code to the community for the early Radeon chipsets. Unfortunately 
> the Linux and Open Source community never stepped up to the plate to 
> support ATI in this effort. There are solid business reasons that ATI has 
> explained to me for why ATI decided to give up on the Open Source 
> approach and go back to proprietary 3D drivers for Linux. 

Really?
AFAICS you have to register as a developer with ATI and "The acceptance
of Developer by ATI [...] is subject to approval by ATI in its sole
discretion".  At least I don't see any downloadable hardware level
documentation at http://www.ati.com/developer/.
Maybe I just didn't look hard enough?  BTW, I'd be mainly interested in
how to access 2D Accelerator functions, video overlay and DMA, so if you
could give me some pointer on how to obtain documentation on that for
radeon 8500 or rage128 pro class cards, it would be very nice.
I have to admit I did not try registering yet, because it seemed to much
of a hassle for "I just like to have the documentation for my hardware"
and to me it seems doubtfull I would be accepted just for that reason.

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de
Any sufficiently advanced bug is indistinguishable from a feature.
  -- Rich Kulawiec
np: Tales of Symphonia Original Soundtrack: Memories of Sylvarant

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Kendall Bennett wrote:
> David Lang <david.lang@digitalinsight.com> wrote:
> 
> 
>>On Wed, 20 Oct 2004, Timothy Miller wrote:
>>
>>
>>>Sure, SOME companies release specs so that we can develop 
>>>open source drivers, but those cards tend to be prohibitively expensive, 
>>>slower than their cheaper counterparts from ATI or nVidia...
>>
>>Tim, I think this is the key problem. with the current ATI/nVidia
>>cards beign in the $50 range (with other cards on the market for
>>as low as $30) are you really going to be able to come up with a
>>card that's price competitive? (completely ignoring the
>>performance question) 
>>
>>as for your other question of if an open approach could be viable
>>(after all nobody does it today so doesn't that proove it isn't) 
>>
>>this is where there is a significant disagreement. the Linux folks
>>think that such openess would be very viable and the companies are
>>just pursuing a legacy approach, but the companies are scared to
>>open things up becouse they don't believe that they would remain
>>viable. 
>>
>>since nobody has done this yet (for video cards anyeay) there is
>>no proof one way or the other. 
> 
> 
> Wrong. Companies *have* tried to go down the Open Source route and it did 
> not work out for them. ATI in particular. At one point ATI released all 
> the register level information and in fact released sample 3D driver 
> source code to the community for the early Radeon chipsets. Unfortunately 
> the Linux and Open Source community never stepped up to the plate to 
> support ATI in this effort. There are solid business reasons that ATI has 
> explained to me for why ATI decided to give up on the Open Source 
> approach and go back to proprietary 3D drivers for Linux. 
> 
> For 2D they continue to maintain XFree86/X.org drivers with full source 
> code for the community, just not 3D.
> 
> If someone wishes to go down this route, more power to them. But I don't 
> think it is a viable way to make money for a business. The biggest 
> problem is that even if every active Linux or Open Source kernel 
> developer decided to buy one of these cards, that is a pretty small 
> market. The unfortunate fact I have come to realise is that there is a 
> very large contingent of Linux end users out there who just want free 
> stuff. Free as in free beer. They could care less whether the source code 
> is available as long as they don't pay for it. Those same users are also 
> more than happy to install ATI or NVIDIA proprietary kernel modules and 
> taint their kernel so they can get 3D support when running Linux and 
> still run their favorite games at full speed under Windows. Those same 
> users probably won't pay a premium to get a 3D card that is slower than 
> an ATI or NVIDIA just because it has source code for the drivers.
> 
> Sad but true IMHO.


What you are speaking is something I often hear described as "cold, hard 
reality".

I'm just hoping the fact that Tech Source has always been a niche player 
will allow this product to be viable.  There are all sorts of things 
that we can do which would be a waste of time for bigger companies that 
already sell to bigger markets.

I'm hoping that some of this famous "free software loyalty" is really 
true.  One fact is that we really cannot sell this product without 
everyone knowing the cost of every part that went into it.  Even if we 
don't publish all the economic details, fans are likely to figure it 
out.  We really CAN'T screw anyone either on price or on support.  Maybe 
that will count for something.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Dave Airlie]

> Wrong. Companies *have* tried to go down the Open Source route and it did
> not work out for them. ATI in particular. At one point ATI released all
> the register level information and in fact released sample 3D driver
> source code to the community for the early Radeon chipsets. Unfortunately
> the Linux and Open Source community never stepped up to the plate to
> support ATI in this effort. There are solid business reasons that ATI has
> explained to me for why ATI decided to give up on the Open Source
> approach and go back to proprietary 3D drivers for Linux.

That's crap, the community did step up, the Weather Channel paid for
the r200 drivers we have now, ATI's register information was far short
of complete, I have the full stack of it here and it doesn't allow a
proper implementation of any of the "cool" features, i.e. hyper-z,
programmable hardware, so how could open source driver be as good if
they info they give is substandard.....  to be honest if a company
wants to do open source drivers for their cards they should support
it, with people, they didn't try at all,

they can try and hide behind it was the communitys fault all they
want, but it's crap I'd rather you didn't spread around here....

> For 2D they continue to maintain XFree86/X.org drivers with full source
> code for the community, just not 3D.

and the difference is?? their current 3D closed source drivers are
crap they know it, the community knows it, if they had open sourced a
completed driver 6-8mths ago, it would now work with X 6.8.1, Linux
2.6.9, powerpc, x86-64 and may even support doom3, and they wouldn't
have to had done anything for that, these big companies have to meet
the community half way, give us a complete working x86 driver for an
up-to-date X and someone will probably be interested in keeping it
running until the end of time... look at the (r300.sf.net to see how
much effort some people are willing to put into reverse engineering
the r300 3d parts...)

ATI and Nvidia not open-sourcing 3D stuff for one simple reason, IP
issues. It is also why Intel are not even giving out their later
chipsets docs to anyone by Tungsten, if anyone tells you differently
send them to me :-)

Dave.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jon Smirl]

On Tue, 26 Oct 2004 12:36:52 +1000, Dave Airlie <airlied@gmail.com> wrote:
> ATI and Nvidia not open-sourcing 3D stuff for one simple reason, IP
> issues. It is also why Intel are not even giving out their later
> chipsets docs to anyone by Tungsten, if anyone tells you differently
> send them to me :-)

After talking to representatives of both companies, it seems that the
patent system has completely perverted the IP situation between them.
But are staying secret because of fear of being sued by the other for
infringement. This is exactly the opposite of what full disclosure of
patents was supposed to achieve.

I wish they could just get together and agree not to sue each other
over stupid things like register designs and programming models. The
designs are horrible on both cards due to accumulation of historical
cruft. Save the lawsuits for the core of the engines if you really
have to sue each other.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jim Nelson]

Timothy Miller wrote:

> I can produce more detail later, but first, some characteristics and 
> advantages of what I'm proposing:
> 
> - x86 BIOS/OpenBoot/OpenFirmware code under BSD and GPL license
> - kernel drivers under BSD and GPL license
> - X11 module under MIT license
> - flashable PROM so that boot code can be added for more platforms
> - usable as the console on any platform that can take a PCI, AGP, or 
> PCI-Express card
> - downloadable schematic for the circuit board
> - FPGA-based graphics engine so it's reprogrammable
> - instructions on how to reprogram the FPGA, so it's hackable
> - if we discontinue a product, we may release the Verilog code for the FPGA
> - Since this is designed to be open-source-friendly, we want to play by 
> the rules of the open-source community.
> - Tech Source would actively participate in the development and 
> maintenance of our own drivers.
> - We will actually pay attention to problems and concerns raised by 
> users and developers.
> - We won't be control-freaks.

> I haven't worked out a complete design spec for this product.  The 
> reason is that what we think people want and what people REALLY want may 
> not be congruent.  If you have a good idea for a piece of graphics 
> hardware which you think would be beneficial to the free software 
> community (and worth it for a company to produce), then Tech Source, as 
> a graphics company, might be willing to sell it.
> 
> 

You might want to take a look at the onboard video market.  Providing an 
open-source 2D rendering engine and the PCI glue logic that work on an 
FPGA would probably revolutionize embedded PC applicatiuons that rely on 
a graphical interface.  Providing support to motherboard manufaturers 
who might want a low-cost onboard video solution (micro-ITX, etc) is 
another possibility.

You also might want to look at PC/104 and CompactPCI form factors - I 
think the industrial market will be a great target, and, after all, if 
you have to move 80% industrial equipment to justify the 20% AGP sales, 
it makes good sense.  There might even be a market for ISA, SBus, and 
MCA cards, for people stuck supporting seriously old machines (386, 486, 
SPARC) where it's almost impossible to find working graphics cards. 
Even if it's a DOS machine, hardware is hardware, and a brand-new VL-bus 
card for someone's 486 would be pretty cool :)

My $0.02

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Jim Nelson wrote:
> Timothy Miller wrote:
> 
>> I can produce more detail later, but first, some characteristics and 
>> advantages of what I'm proposing:
>>
>> - x86 BIOS/OpenBoot/OpenFirmware code under BSD and GPL license
>> - kernel drivers under BSD and GPL license
>> - X11 module under MIT license
>> - flashable PROM so that boot code can be added for more platforms
>> - usable as the console on any platform that can take a PCI, AGP, or 
>> PCI-Express card
>> - downloadable schematic for the circuit board
>> - FPGA-based graphics engine so it's reprogrammable
>> - instructions on how to reprogram the FPGA, so it's hackable
>> - if we discontinue a product, we may release the Verilog code for the 
>> FPGA
>> - Since this is designed to be open-source-friendly, we want to play 
>> by the rules of the open-source community.
>> - Tech Source would actively participate in the development and 
>> maintenance of our own drivers.
>> - We will actually pay attention to problems and concerns raised by 
>> users and developers.
>> - We won't be control-freaks.
> 
> 
>> I haven't worked out a complete design spec for this product.  The 
>> reason is that what we think people want and what people REALLY want 
>> may not be congruent.  If you have a good idea for a piece of graphics 
>> hardware which you think would be beneficial to the free software 
>> community (and worth it for a company to produce), then Tech Source, 
>> as a graphics company, might be willing to sell it.
>>
>>
> 
> You might want to take a look at the onboard video market.  Providing an 
> open-source 2D rendering engine and the PCI glue logic that work on an 
> FPGA would probably revolutionize embedded PC applicatiuons that rely on 
> a graphical interface.  Providing support to motherboard manufaturers 
> who might want a low-cost onboard video solution (micro-ITX, etc) is 
> another possibility.

Now, THIS is an excellent idea.  If the volumes there would be high 
enough, it could be what justifies the project.  We have had customers 
wanting embedded solutions, and through this project, we could provide 
them something even better in the future.

> You also might want to look at PC/104 and CompactPCI form factors - I 
> think the industrial market will be a great target, and, after all, if 
> you have to move 80% industrial equipment to justify the 20% AGP sales, 
> it makes good sense.  There might even be a market for ISA, SBus, and 
> MCA cards, for people stuck supporting seriously old machines (386, 486, 
> SPARC) where it's almost impossible to find working graphics cards. Even 
> if it's a DOS machine, hardware is hardware, and a brand-new VL-bus card 
> for someone's 486 would be pretty cool :)

This is a good idea too.  I've already decided to try to fit it onto a 
1/2 height, short PCI card (like the low-end 3ware cards) so that you 
can put the card into one of these compact cases.

At this time, I'm not sure it's worth it to do anything other than PCI, 
AGP, and PCIE, however.  Of course, if someone comes along with a large 
enough order, we'd be plenty willing to do whatever customization they want.

Force of will isn't going to get this project done.  Money is what 
matters here.  <sigh>  :)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jim Nelson]

Timothy Miller wrote:
> 
> 
> Jim Nelson wrote:
> 
>> Timothy Miller wrote:
>>
>>> I can produce more detail later, but first, some characteristics and 
>>> advantages of what I'm proposing:
>>>
>>> - x86 BIOS/OpenBoot/OpenFirmware code under BSD and GPL license
>>> - kernel drivers under BSD and GPL license
>>> - X11 module under MIT license
>>> - flashable PROM so that boot code can be added for more platforms
>>> - usable as the console on any platform that can take a PCI, AGP, or 
>>> PCI-Express card
>>> - downloadable schematic for the circuit board
>>> - FPGA-based graphics engine so it's reprogrammable
>>> - instructions on how to reprogram the FPGA, so it's hackable
>>> - if we discontinue a product, we may release the Verilog code for 
>>> the FPGA
>>> - Since this is designed to be open-source-friendly, we want to play 
>>> by the rules of the open-source community.
>>> - Tech Source would actively participate in the development and 
>>> maintenance of our own drivers.
>>> - We will actually pay attention to problems and concerns raised by 
>>> users and developers.
>>> - We won't be control-freaks.
>>
>>
>>
>>> I haven't worked out a complete design spec for this product.  The 
>>> reason is that what we think people want and what people REALLY want 
>>> may not be congruent.  If you have a good idea for a piece of 
>>> graphics hardware which you think would be beneficial to the free 
>>> software community (and worth it for a company to produce), then Tech 
>>> Source, as a graphics company, might be willing to sell it.
>>>
>>>
>>
>> You might want to take a look at the onboard video market.  Providing 
>> an open-source 2D rendering engine and the PCI glue logic that work on 
>> an FPGA would probably revolutionize embedded PC applicatiuons that 
>> rely on a graphical interface.  Providing support to motherboard 
>> manufaturers who might want a low-cost onboard video solution 
>> (micro-ITX, etc) is another possibility.
> 
> 
> Now, THIS is an excellent idea.  If the volumes there would be high 
> enough, it could be what justifies the project.  We have had customers 
> wanting embedded solutions, and through this project, we could provide 
> them something even better in the future.
> 

That would be your value-add there - provide the experience in video 
system design to the low-volume (<5000 unit) custom controller market. 
Smaller companies will not have the video experience to implement 
something like this.  You could even bill the PCI cards as "developer 
tools".  You'd just sell a lot of developer cards to *nix people...

>> You also might want to look at PC/104 and CompactPCI form factors - I 
>> think the industrial market will be a great target, and, after all, if 
>> you have to move 80% industrial equipment to justify the 20% AGP 
>> sales, it makes good sense.  There might even be a market for ISA, 
>> SBus, and MCA cards, for people stuck supporting seriously old 
>> machines (386, 486, SPARC) where it's almost impossible to find 
>> working graphics cards. Even if it's a DOS machine, hardware is 
>> hardware, and a brand-new VL-bus card for someone's 486 would be 
>> pretty cool :)
> 
> 
> This is a good idea too.  I've already decided to try to fit it onto a 
> 1/2 height, short PCI card (like the low-end 3ware cards) so that you 
> can put the card into one of these compact cases.
> 
> At this time, I'm not sure it's worth it to do anything other than PCI, 
> AGP, and PCIE, however.  Of course, if someone comes along with a large 
> enough order, we'd be plenty willing to do whatever customization they 
> want.
> 

I dunno.  That's what market research weenies are paid to do - figure 
out if the market for a product is good enough to justify developement.

If this does work, though, moving the core graphics rendering engine to 
an ASIC would mean that a very small amount of work would be necessary 
to move the core to various bus architectures - even high-end PDA's and 
cell phones are going to need some serious graphics horespower soon, if 
the screens on them keep going like they are.

You also might want to consider marketing "developer kits" that include 
dead-tree documentation, boards, re-branded FPGA tools, and raw chips 
for those looking to do custom work on their own.  I think it'd be fun 
to hack up an ISA graphics card on my own, even if mass production isn't 
feasible :)

It could be marketed to universities needing an undergraduate project in 
hardware design, too - for everything from video BIOS development to PCI 
interfacing to DAC implementation and physical board design.  And the 
students wouldn't need to sign an NDA to get access to the cool new 
hardware...

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Kasper Sandberg]

well.. while i like this idea, i doubt it is ever going to work, since
3d would probably be a requirement, and with stuff like nvidia around, i
doubt most people would want to pay the money it would require, since
ati and nvidia can smash out millions of cards, while it would probably
be at best, a couple of thousands of these opensource cards that could
be sold, i, for one would like to pay, however i dont think mainstream
will... and as of for 2d only, well :| i kindof needs 3d :(
but certainly a good idea, and maybe in future, if linux grows more
used, it will actually be possible to do something real kicking ass ;)

On Wed, 2004-10-20 at 18:02 -0400, Timothy Miller wrote:
<snip>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Kasper Sandberg

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Kasper Sandberg wrote:
> well.. while i like this idea, i doubt it is ever going to work, since
> 3d would probably be a requirement, and with stuff like nvidia around, i
> doubt most people would want to pay the money it would require, since
> ati and nvidia can smash out millions of cards, while it would probably
> be at best, a couple of thousands of these opensource cards that could
> be sold, i, for one would like to pay, however i dont think mainstream
> will... and as of for 2d only, well :| i kindof needs 3d :(
> but certainly a good idea, and maybe in future, if linux grows more
> used, it will actually be possible to do something real kicking ass ;)
> 
>

Perhaps typical end users are not our target market.  Instead, maybe we 
should be targeting companies that sell workstations and servers who 
want something which maximized stability, regardless of the cost and 
performance.

If you're selling a $5000 workstation, you might be willing to pay $300 
for a graphics card that saves you thousands in customer support calls 
that don't have to happen.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Simon Braunschmidt]

Timothy Miller schrieb:
> 
> 
> Kasper Sandberg wrote:
> 
>> well.. while i like this idea, i doubt it is ever going to work, since
>> 3d would probably be a requirement, and with stuff like nvidia around, i
>> doubt most people would want to pay the money it would require, since
>> ati and nvidia can smash out millions of cards, while it would probably
>> be at best, a couple of thousands of these opensource cards that could
>> be sold, i, for one would like to pay, however i dont think mainstream
>> will... and as of for 2d only, well :| i kindof needs 3d :(
>> but certainly a good idea, and maybe in future, if linux grows more
>> used, it will actually be possible to do something real kicking ass ;)
>>
>>
> 
> Perhaps typical end users are not our target market.  Instead, maybe we 
> should be targeting companies that sell workstations and servers who 
> want something which maximized stability, regardless of the cost and 
> performance.
> 
> If you're selling a $5000 workstation, you might be willing to pay $300 
> for a graphics card that saves you thousands in customer support calls 
> that don't have to happen.
> 

Is $300 with 3D in the class of geforce2/ati_r200?

Simon

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Simon Braunschmidt wrote:

>> If you're selling a $5000 workstation, you might be willing to pay 
>> $300 for a graphics card that saves you thousands in customer support 
>> calls that don't have to happen.
>>
> 
> Is $300 with 3D in the class of geforce2/ati_r200?


Well, that's a different story.  If the plan changes so that we decide 
to produce a high-end card, then we can do an ASIC, giving us more chip 
area and faster clock speeds.

The problem is that a $300 card isn't a card "for the masses".  My 
example there is only plausible for those cases where lots of money is 
already being spent.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Alan Cox]

On Mer, 2004-10-20 at 23:02, Timothy Miller wrote:
> - The card "just works" with Linux because, maybe, the drivers would go 
> into main-line

That bit ought to "just work" 8)

> - The drivers are easy to work on, since you don't ever have to guess 
> about anything.
> - The drivers are easy to debug because
>      (a) we document everything, and
>      (b) we'll talk to you.

Some other vendors pretty much did this but the takeup isn't that vast
because writing 3D drivers is not trivial (we have docs for about 5
cards and no drivers, some are pretty old some are fairly passable
cards)

> and they STILL don't document the internals of the BIOS so that the card 
> can be ported to a non-x86 system.  Furthermore, since all these vendors

Talking to one very large motherboard video company they actually can't
because the analogue side is done by the board vendor as is things like
the RAM choice.
 
> give me sufficient funding to produce an ASIC.  What this means is that 
> the design has to be small and simple and focus primarily on 2D 
> performance so that it can fit into an FPGA.

X actually needs very little functionality nowdays, although some of it
does not map well onto a generic 2D rendering card. Notably most 2D
engines lack alpha blend.

Essentially if you can do alpha, bitblit, blit from main memory and
a couple of fills and colour-expands X is happy.

> (1) Would the sales volumes of this product be enough to make it worth 
> producing (ie. profitable)?

I'm very dubious I must admit. 


I've actually always wondered what a hybrid video device would look like
for 3D. Doing the alpha blend and very basic operations only in the
hardware that are expensive in software - alpha and perhaps some of the
texture scaling, but walking textures in software, doing shaders in
software and so on.

Alan

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Alan Cox wrote:
> On Mer, 2004-10-20 at 23:02, Timothy Miller wrote:
> 
>>- The card "just works" with Linux because, maybe, the drivers would go 
>>into main-line
> 
> 
> That bit ought to "just work" 8)

Well, if you're in favor of it, it will, but not every patch submitted 
to Linus or Andrew ends up in the mainline kernel.  I'm a total unknown 
here.  I don't expect special treatment.

> 
> 
>>- The drivers are easy to work on, since you don't ever have to guess 
>>about anything.
>>- The drivers are easy to debug because
>>     (a) we document everything, and
>>     (b) we'll talk to you.
> 
> 
> Some other vendors pretty much did this but the takeup isn't that vast
> because writing 3D drivers is not trivial (we have docs for about 5
> cards and no drivers, some are pretty old some are fairly passable
> cards)

I would do the basic 3D drivers.  I'm going to have to spend a good bit 
of time learning all the math behind 3D graphics anyhow.  I mean, I 
understand the basics, and I do just fine with linear algebra, but I 
don't live in that zone right now, so I don't grok every detail.  In 
order to design the chip, I'll have to go there, and as a result, I 
should have little trouble doing the software portion.  After I'm done 
with it, others can do whatever they want with it.

Note:  It would be nice to release partial drivers early so others can 
hack at them, but we cannot sell a product without a complete, working, 
tested, driver suite for several platforms.  A beta period would be 
nice, where developers can get prototype boards, but prototypes can be 
very expensive to produce.

> 
>>and they STILL don't document the internals of the BIOS so that the card 
>>can be ported to a non-x86 system.  Furthermore, since all these vendors
> 
> 
> Talking to one very large motherboard video company they actually can't
> because the analogue side is done by the board vendor as is things like
> the RAM choice.

Yes, that is definately an issue.  Fortunately, if you have both specs 
for the RAM chips and the full register set for the GPU documented, then 
getting it to work with any arbitrary RAM chip is trivial.

Of course, generally speaking, since we're selling the boards, we'd 
simply just publish numbers and a code snippet for configuring the 
memory controller properly, so it's no big deal.

We're not expecting the community to do software development for this 
product, but we DO want them to be able to easily and freely address 
bugs and compatibility issues.

> 
>>give me sufficient funding to produce an ASIC.  What this means is that 
>>the design has to be small and simple and focus primarily on 2D 
>>performance so that it can fit into an FPGA.
> 
> 
> X actually needs very little functionality nowdays, although some of it
> does not map well onto a generic 2D rendering card. Notably most 2D
> engines lack alpha blend.

Well, adding alpha blend to 2D isn't that hard.  But when you want, say, 
oversampling AA, and then you start adding other features, then the 
point in having a separate 2D pipeline diminishes.

> 
> Essentially if you can do alpha, bitblit, blit from main memory and
> a couple of fills and colour-expands X is happy.

How about text, stipple fills, tile fills, and lines?  :)

Actually, if you do it right, only lines are a special case, and you can 
even hide that.

> 
>>(1) Would the sales volumes of this product be enough to make it worth 
>>producing (ie. profitable)?
> 
> 
> I'm very dubious I must admit. 
> 
> 
> I've actually always wondered what a hybrid video device would look like
> for 3D. Doing the alpha blend and very basic operations only in the
> hardware that are expensive in software - alpha and perhaps some of the
> texture scaling, but walking textures in software, doing shaders in
> software and so on.

Well, if a specific set of needs can be identified, we could easily 
enough develop a GPU which does only those things.


Something to keep in mind:  The chip contains more than just a rendering 
engine.  The VGA core, host interface (AGP/PCI), video controller, 
memory controller, and other misc things all take up a fair amount of 
space on their own.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jon Smirl]

An experimental feature I've heard being proposed is to generate font
bitmaps dynamically on the card. The idea is to load the TrueType
glyphs onto the card and then generate a temp bitmap when you know
exactly the size/subpixel alignment that you need. Implementing this
probably means you need 3D FP transform units. This is just an
experiment proposal, no one has built it yet so no one knows if it is
going to work very well. It might be an opportunity to try for some
patents.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Jon Smirl wrote:
> An experimental feature I've heard being proposed is to generate font
> bitmaps dynamically on the card. The idea is to load the TrueType
> glyphs onto the card and then generate a temp bitmap when you know
> exactly the size/subpixel alignment that you need. Implementing this
> probably means you need 3D FP transform units. This is just an
> experiment proposal, no one has built it yet so no one knows if it is
> going to work very well. It might be an opportunity to try for some
> patents.
> 


I would expect glyphs to be rendered into bitmaps on-demand and cached.
I would expect the cache to have such a HIGH hit rate that it's not 
worth dedicating hardware to the relatively infrequent event of 
rasterizing a glyph.

Now, providing the means to efficiently use those cached bitmaps, on the 
other hand, is definately worth the effort.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Alan Cox]

On Iau, 2004-10-21 at 16:10, Timothy Miller wrote:
> > Essentially if you can do alpha, bitblit, blit from main memory and
> > a couple of fills and colour-expands X is happy.
> 
> How about text, stipple fills, tile fills, and lines?  :)

They really don't seem to matter much. Text is generally a colour expand
fill (ie mono -> colour bitmap expansion) or alpha blended fill.
Stipples and tiles are no big deal and angled lines are used very
little, and are also very cheap because they don't cause any pci fetches
except for weird stuff like xor lines. The main users of those do
horizontal/vertical only which means they are just rectangles...

Alan

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Kendall Bennett]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> I've actually always wondered what a hybrid video device would
> look like for 3D. Doing the alpha blend and very basic operations
> only in the hardware that are expensive in software - alpha and
> perhaps some of the texture scaling, but walking textures in
> software, doing shaders in software and so on. 

Well that is what most of the early 3D cards started out as. A lot of the 
early SGI boxes that has '3D' were not full 3D rendering engines but span 
based rendering engines. Not only was setup done in software, but so was 
the walking of the triangle sides and the only thing passed to the 
hardware was commands to render spans (flat, smooth or textured). You 
could build any kind of complex renderer on top of this and in those days 
it was SGI GL (pre OpenGL) that was the rendering API. The systems were 
also reasonably fast for the day too.

I think the original 3DLabs GLINT SX chipset also did span rendering and 
support textured spans. The biggest problem is that the overhead required 
by the CPU to process anything close to the volume of triangles per 
second that high end cards can handle today is overwhelming. Even a 4Ghz 
P4 probably couldn't keep up trying to match the transform, lighting and 
span traversal to match even a basic Radeon 9000 card IMHO. And then 
you've got no CPU cycles left for anything else such as sound and game 
physics ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Kendall Bennett wrote:

> 
> Well that is what most of the early 3D cards started out as. A lot of the 
> early SGI boxes that has '3D' were not full 3D rendering engines but span 
> based rendering engines. Not only was setup done in software, but so was 
> the walking of the triangle sides and the only thing passed to the 
> hardware was commands to render spans (flat, smooth or textured). You 
> could build any kind of complex renderer on top of this and in those days 
> it was SGI GL (pre OpenGL) that was the rendering API. The systems were 
> also reasonably fast for the day too.
> 
> I think the original 3DLabs GLINT SX chipset also did span rendering and 
> support textured spans. The biggest problem is that the overhead required 
> by the CPU to process anything close to the volume of triangles per 
> second that high end cards can handle today is overwhelming. Even a 4Ghz 
> P4 probably couldn't keep up trying to match the transform, lighting and 
> span traversal to match even a basic Radeon 9000 card IMHO. And then 
> you've got no CPU cycles left for anything else such as sound and game 
> physics ;-)
> 


The bus (PCI, AGP, whatever) is a much more severe bottleneck than even 
the CPU.

If it takes two-dozen parameters to specify a triangle that ends up 
plotting only a single pixel on the screen, it's just not worth doing. 
But that is something that happens a lot onboard 3D chips.  That's why 
triangle rate is as important a factor as pixel rate.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jon Smirl]

I have heard a lot of complaints from embedded people about having few
choices for graphics chips. Many of the low end chips from ATI/NVidia
are no longer in production and you are forced into buying more chip
than you want. You should ask about this on embedded developer lists.

For the new X servers you have to have hardware alpha blending.
Another important feature is accelerated drawing to off-screen
buffers. Also, DMA command queues help a lot with parallelizing
drawing.

If you implement VGA you will be able to boot and work in any x86
system without writing any code other than the BIOS.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jon Smirl]

Another thought, TV out is important in the embedded market. Think
about Tivo/MythTV/set top boxes.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Stephen Wille Padnos]

Jon Smirl wrote:

>Another thought, TV out is important in the embedded market. Think
>about Tivo/MythTV/set top boxes.
>
OK - so the answer seems to be "if it does the right things, then it may 
sell"  It's hard to sell a card that doesn't do good 3D these days (re: 
Matrox Parhelia).  Speaking of the parhelia, I would look at that 
feature set as a starting point.  10-bit color, multiscreen accelerated 
3D, dual DVI, gamma corrected glyph antialiasing, etc.

So, let's try to figure out the right feature set.  (that is what was 
originally asked for, after all)

Looking at 2D, I would definitely want to see: (some taken from other 
emails on the subject)
alpha blending
antialiasing (related to alpha blending)
bitblt
fast primitive drawing
accelerated offscreen operations
more than 8 bits/color channel
video output - preferably with independent scale / refresh (ie, clone 
the 100Hz 1600x1200 monitor on a 648x480 60 Hz NTSC monitor)
video decoding acceleration (possibly some encoding functions as well)
bitmap scaling (think of font sizing and the like)
2D rotation
possibly 2.5D rotation - ie, the perspective "twist" of a plane image 
into 3D space (like Sun's Looking Glass environment)

I would think that a chip that has a lot of simple functions, but 
requires the OS to put them together to actually do something, would be 
great.  This would be the UNIX mentality brought to hardware: lots of 
small components that get strung together in ways their creator(s) never 
imagined.  If there can be a programmable side as well (other than 
re-burning the FPGA), that would be great.

I guess I would look at this as an opportunity to make a "visual 
coprocessor", that also has the hardware necessary to output to a 
monitor (preferably multiple monitors).

- Steve

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Stephen Wille Padnos wrote:
> Jon Smirl wrote:
> 
>> Another thought, TV out is important in the embedded market. Think
>> about Tivo/MythTV/set top boxes.
>>
> OK - so the answer seems to be "if it does the right things, then it may 
> sell"  It's hard to sell a card that doesn't do good 3D these days (re: 
> Matrox Parhelia).  Speaking of the parhelia, I would look at that 
> feature set as a starting point.  10-bit color, multiscreen accelerated 
> 3D, dual DVI, gamma corrected glyph antialiasing, etc.

I was thinking of pointing at the Permedia 2 or 3 as an example of the 
basic 3D feature set.

> 
> So, let's try to figure out the right feature set.  (that is what was 
> originally asked for, after all)
> 
> Looking at 2D, I would definitely want to see: (some taken from other 
> emails on the subject)

> alpha blending

Easy enough.

> antialiasing (related to alpha blending)

Antialiasing implies oversampling or supersampling, unless you're 
thinking about something else.  Sometimes, "antialiasing" is nothing 
more than a fuzzy texture.  For instance, the way the X11 font server 
handles antialiased text... it just spits out a grayscale bitmap which 
can be used as texture.

> bitblt
> fast primitive drawing

No problem.

> accelerated offscreen operations

It's funny that people mention that.  Every DDX module I have ever 
produced has had sophistocated off-screen memory management so that 
pixmaps could be accelerated.  I never even considered NOT supporting 
accelerated off-screen surfaces.

There was one chip I had to support a number of years ago which didn't 
have separate registers for the base pointers to source and destination 
surfaces.  That meant that you couldn't use "bitblt" to copy an image 
from off-screen to on-screen.  What I ended up having to do was 
implement bitblt as a texture-mapping operation.  (It wound up being 
slightly faster than the regular bitblt, even if the source and dest 
were the same surface.)

Anyhow, in my world, accelerated off-screen surfaces are a given.

> more than 8 bits/color channel

For rendering or for display?  A DVI transmitter won't do more than 8 
bits per channel, but it can be helpful to have more than 8 bits per 
channel for greater mathematical precision when compositing images.

> video output - preferably with independent scale / refresh (ie, clone 
> the 100Hz 1600x1200 monitor on a 648x480 60 Hz NTSC monitor)
 > video decoding acceleration (possibly some encoding functions as well)

While I have considered that for other products, I'm not sure I want to 
do through that trouble for a "low-end" card, unless you're happy with 
integer scaling, which isn't so bad.

Most LCD monitors I encounter will scale, but I don't know what's the 
best thing to do about your example.  I can see why you'd want to be 
able to squeeze your game display onto a TV, but I also wasn't thinking 
about supporting TV.  Consider how much that would increase the parts cost.

> bitmap scaling (think of font sizing and the like)
> 2D rotation
> possibly 2.5D rotation - ie, the perspective "twist" of a plane image 
> into 3D space (like Sun's Looking Glass environment)

Those are all subsets of texture-mapping.

> 
> I would think that a chip that has a lot of simple functions, but 
> requires the OS to put them together to actually do something, would be 
> great.  This would be the UNIX mentality brought to hardware: lots of 
> small components that get strung together in ways their creator(s) never 
> imagined.  If there can be a programmable side as well (other than 
> re-burning the FPGA), that would be great.

You're right, and you're not.  There are two reasons why modern 3D GPUs 
put the world mesh into the card framebuffer and do all the T&L in the 
GPU.  One reason is that it's faster to do it in dedicated hardware. 
The other more pressing reason is that the host interface (PCI or AGP) 
puts a very low upper-bound on your triangle rendering rate.

The number of parameters necessary to specify a single texture-mapped 
triangle are literally in the dozens.  If you did only 32-bit fixed 
point (16.16) for coordinates, that's still a huge amount of information 
to move across the bus to instruct the chip to render a single triangle. 
  And what if that triangle ends up amounting to a single pixel?  Think 
about the waste!

Instead, the un-transformed geometry is loaded into the card memory only 
once, and the GPU is instructed to render the scene based on the camera 
perspective and lighting information.  Aside from the need to cache 
textures on-card, this is another reason for the need to have LOTS of 
graphics memory.

> 
> I guess I would look at this as an opportunity to make a "visual 
> coprocessor", that also has the hardware necessary to output to a 
> monitor (preferably multiple monitors).

I don't think that's realistic.  We could do that, but it would have 
terrible performance.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Stephen Wille Padnos]

Timothy Miller wrote:

> You're right, and you're not.  There are two reasons why modern 3D 
> GPUs put the world mesh into the card framebuffer and do all the T&L 
> in the GPU.  One reason is that it's faster to do it in dedicated 
> hardware. The other more pressing reason is that the host interface 
> (PCI or AGP) puts a very low upper-bound on your triangle rendering rate.

I'm thinking more like microcode.  The functional blocks on the chip 
would be capable of being "rewired" by the OS, depending on the 
applications being run.  All of the functions would still operate out of 
card-local memory.

> The number of parameters necessary to specify a single texture-mapped 
> triangle are literally in the dozens.  If you did only 32-bit fixed 
> point (16.16) for coordinates, that's still a huge amount of 
> information to move across the bus to instruct the chip to render a 
> single triangle.  And what if that triangle ends up amounting to a 
> single pixel?  Think about the waste!
>
> Instead, the un-transformed geometry is loaded into the card memory 
> only once, and the GPU is instructed to render the scene based on the 
> camera perspective and lighting information.  Aside from the need to 
> cache textures on-card, this is another reason for the need to have 
> LOTS of graphics memory.

Yep - reminds me of the days with the old SGI Iris, which did OpenGL 
processing directly on the card, with the display list local to the 
GPU(s) (1280x1024@100 bit depth -24 bit color, 24-bit Z, another 48 bits 
for double-buffering, and 2 bits of overlay + 2 more underlay - those 
were the days :)

>> I guess I would look at this as an opportunity to make a "visual 
>> coprocessor", that also has the hardware necessary to output to a 
>> monitor (preferably multiple monitors).
>
> I don't think that's realistic.  We could do that, but it would have 
> terrible performance.

Sorry - I wasn't thinking in terms of an 8087 - more like a dedicated 
processor for image related functions - like a DSP card.  A display list 
based coprocessor would certainly be better than anything that has to 
repeatedly transfer commands over a slow bus.

- Steve

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jan Knutar]

On Thursday 21 October 2004 19:34, Stephen Wille Padnos wrote:

> I'm thinking more like microcode.  The functional blocks on the chip 
> would be capable of being "rewired" by the OS, depending on the 
> applications being run.  All of the functions would still operate out of 
> card-local memory.

Are you thinking something along the lines of an optimizing+profiling
host-CPU-software-renderer to FPGA-reprogrammed JIT accelerator? :)

The idea of reprogramming the hardware to toss out the line drawing and
other things that GTK and friends probably only present to X as pixmaps
anyway, and use that 'die space' for something else, is certainly appealing.

Of course, for a software -> hardware JITc, I think the budget required would
be a few magnitudes more than mentioned here earlier, and half a decade
of debugging or more ontop..

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jan Rychter]

>>>>> "Jan" == Jan Knutar <jk-lkml@sci.fi> writes:
 Jan> On Thursday 21 October 2004 19:34, Stephen Wille Padnos wrote:
 >> I'm thinking more like microcode.  The functional blocks on the chip
 >> would be capable of being "rewired" by the OS, depending on the
 >> applications being run.  All of the functions would still operate
 >> out of card-local memory.

 Jan> Are you thinking something along the lines of an
 Jan> optimizing+profiling host-CPU-software-renderer to
 Jan> FPGA-reprogrammed JIT accelerator? :)

 Jan> The idea of reprogramming the hardware to toss out the line
 Jan> drawing and other things that GTK and friends probably only
 Jan> present to X as pixmaps anyway, and use that 'die space' for
 Jan> something else, is certainly appealing.

 Jan> Of course, for a software -> hardware JITc, I think the budget
 Jan> required would be a few magnitudes more than mentioned here
 Jan> earlier, and half a decade of debugging or more ontop..

This isn't *strictly* related to the main topic of this discussion, but:
You might want to look at the Stretch CPU (http://www.stretchinc.com/),
which, incidentally, runs Linux. Or rather the Xtensa part of it does.

--J.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Jan Knutar wrote:
> On Thursday 21 October 2004 19:34, Stephen Wille Padnos wrote:
> 
> 
>>I'm thinking more like microcode.  The functional blocks on the chip 
>>would be capable of being "rewired" by the OS, depending on the 
>>applications being run.  All of the functions would still operate out of 
>>card-local memory.
> 
> 
> Are you thinking something along the lines of an optimizing+profiling
> host-CPU-software-renderer to FPGA-reprogrammed JIT accelerator? :)
> 
> The idea of reprogramming the hardware to toss out the line drawing and
> other things that GTK and friends probably only present to X as pixmaps
> anyway, and use that 'die space' for something else, is certainly appealing.
> 
> Of course, for a software -> hardware JITc, I think the budget required would
> be a few magnitudes more than mentioned here earlier, and half a decade
> of debugging or more ontop..


For this graphics design, and I'm getting into premature implementation 
details, but I'm a geek, so I can't help myself... I think having some 
sort of primitive microcontroller at the front end of the design is 
necessary.  Two major things it would do would be to control the DMA bus 
mastering, and translate commands (both DMA and PIO) into the parameters 
required by the rendering engine.

See, I would design a very flexible, programmable rasterizer which could 
be programmed to do anything.  But for many operations like bitblt and 
line drawing, there's a load of redundancy.  For lines, all you need are 
the end-points.  If software had to program that directly, it would be a 
major non-win for small primitives like short lines and small bitblts 
where sending the command over the AGP bus would take longer than 
actually doing the rendering.

In my experience, throwing CPU time at a problem in order to reduce the 
bus traffic is almost always a win, a significant performance boost.

A good compromise between having the host waste a lot of bus traffic and 
using up chip area with too much dedicated hardware is to have the 
front-end microcontroller ("setup engine") do a fair amount of the work. 
  This way, I could eliminate anything from the rasterizer that was 
there only so it could draw diagonal lines but STILL be able to draw 
fast diagonal lines.



Here's an interesting philosophical question:  If I spend too much time 
discussing the technical issues of the design BEFORE it is released, am 
I significantly increasing the risk of a competitor cutting us off at 
the knees before I can even get started?  On the one hand, everyone will 
be happy if ANYONE produces a completely open-spec design.  On the other 
hand, I would be very unhappy if I didn't get to do it myself.

ATI and nVidia are secretive for damn good reasons.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Chris Friesen]

Timothy Miller wrote:

> ATI and nVidia are secretive for damn good reasons.

One of nVidia's reasons is that they license 3rd party IP that they cannot make 
public.

Chris

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jeff Garzik]

I've thought about this a bit already, and had some chip designers 
correct my thoughts on a few things.  Here are my comments, in no 
particular order:


1) I agree it probably wouldn't be cost effective without selling to 
OEMs in volume

2) AGP/PCI-Express is practically required, if you want OEM sales, IMO

3) Your main bottlenecks are video RAM bandwidth to/from the GPU, 
PCI/AGP bus bandwidth, and system RAM bandwidth.

4) I am a bit dubious that FPGA will perform at a useful clock speed.

5) Key question:  generic GPU or not?

 From what I've read in ARS Technica and other tech sites, ATI and 
NVIDIA chips are moving towards a more generic, programmable CPU model. 
  Presumably on current (or future?) chips, you will push bytecoded 
shaders direct to your video card.  Essentially some future GPUs will be 
highly specialized, yet generic, CPUs with their own ISA.

On the other hand, if you only support a small number of graphics 
operations, it may be easier for the first rev of your chip to do all 
the 2D operations in silicon.


6) My preference:  generic OpenGL programming interface.

I feel my own personal design for video hardware interface is better 
than ATI or NVIDIA:  present to the OS driver a generic, open, public 
OpenGL interface, that very rarely (if ever) changes.  This must be a 
simple interface:  only a few key operations, such as "transfer {display 
list | shader | texture | ...} data to card" or "execute display list" 
should be presented to the OS driver.

The interface should have a standard "fall back to software rendering" 
response message, for minimalist hardware.

If your hardware presents a standard GL interface to OS driver,

a) there is a high potential industry standardization, if it's done right

b) reduce complexity in the OS driver.

c) stop the "driver rat race".  After the OS driver is initially 
written, the only maintenance costs are keeping up to date with the 
latest OpenGL standards.  You have very low cross-hardware support 
costs, because all the hardware presents the same interface to the OS 
driver.

d) makes it possible to add value to your hardware without changing the 
OS driver

e) makes it possible for multiple video chip vendors to compete, without 
worrying about OS driver issues, or Linux support issues.

f) this isn't a terribly new idea :)  But it's a good one, IMHO.

g) even on minimalist 2D-only hardware, you can implement this interface


7) two-chip solution

One thing I have pondered, with regards to #6:  what about implementing 
a multi-core solution?  One core to handle the graphics operations and 
control the video, and one core a much more generic microcontroller that 
runs ucLinux, and handles the GL "slow path" stuff.  The advantage of 
this approach is

a) 100% of 2D and 3D GL is "done in hardware".  The portions of GL that 
are not handled by the GPU core are handled by the microcontroller core, 
which is running a generic firmware.

b) Since a microcontroller is included, you can upgrade the firmware 
quite easily to support new OpenGL features.

c) you don't necessarily have to follow my design of one purpose built 
GPU core, and one generic microcontroller core.  If your FPGA is big 
enough, you can have plenty of execution engines (that's the beauty of 
hardware, it's inherently parallel).

But OTOH, maybe a multi-core solution will add too much latency into the 
picture, I dunno.



8) I don't find an open source video BIOS terribly exciting.  Yes, I do 
think it should be open source, but the interest is largely theoretical. 
  A video BIOS only does a couple things...  implements VESA/etc. BIOS 
calls, and initializes the hardware based on characteristics specific to 
the video board (i.e. OEM not GPU details, such as video RAM setup and 
clocking, which video inputs are actually implemented on the board, 
...).  I don't see there being a big programmer or developer interest

Such a video BIOS would probably have to be BSD-licensed, since the 
video BIOS code may wind up being #included into an OEM's system BIOS.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Jeff Garzik wrote:
> I've thought about this a bit already, and had some chip designers 
> correct my thoughts on a few things.  Here are my comments, in no 
> particular order:
> 
> 
> 1) I agree it probably wouldn't be cost effective without selling to 
> OEMs in volume

I have concluded that.

> 
> 2) AGP/PCI-Express is practically required, if you want OEM sales, IMO

AGP and PCI are very similar in terms of the state machine, although the 
signal drivers are different.  I expect we'll come out with PCI and AGP 
versions first and then PCIE soon after.  Any "early access" developer 
boards would be PCI-only.

> 
> 3) Your main bottlenecks are video RAM bandwidth to/from the GPU, 
> PCI/AGP bus bandwidth, and system RAM bandwidth.

The biggest bottleneck is the PCI/AGP bus.

> 
> 4) I am a bit dubious that FPGA will perform at a useful clock speed.

You can either clock fast, like Intel, or parallelize more, like AMD. 
Both work.

Of course, for an FPGA, both make it more expensive.

> 
> 5) Key question:  generic GPU or not?
> 
>  From what I've read in ARS Technica and other tech sites, ATI and 
> NVIDIA chips are moving towards a more generic, programmable CPU model. 
>  Presumably on current (or future?) chips, you will push bytecoded 
> shaders direct to your video card.  Essentially some future GPUs will be 
> highly specialized, yet generic, CPUs with their own ISA.
> 
> On the other hand, if you only support a small number of graphics 
> operations, it may be easier for the first rev of your chip to do all 
> the 2D operations in silicon.

It sounds like the best thing to do is implement a 3D pipeline and bolt 
on a translator to do 2D stuff.

What I don't know is how much 3D I can get away with not implementing.

> 
> 
> 6) My preference:  generic OpenGL programming interface.
> 
> I feel my own personal design for video hardware interface is better 
> than ATI or NVIDIA:  present to the OS driver a generic, open, public 
> OpenGL interface, that very rarely (if ever) changes.  This must be a 
> simple interface:  only a few key operations, such as "transfer {display 
> list | shader | texture | ...} data to card" or "execute display list" 
> should be presented to the OS driver.
> 
> The interface should have a standard "fall back to software rendering" 
> response message, for minimalist hardware.
> 
> If your hardware presents a standard GL interface to OS driver,
> 
> a) there is a high potential industry standardization, if it's done right
> 
> b) reduce complexity in the OS driver.
> 
> c) stop the "driver rat race".  After the OS driver is initially 
> written, the only maintenance costs are keeping up to date with the 
> latest OpenGL standards.  You have very low cross-hardware support 
> costs, because all the hardware presents the same interface to the OS 
> driver.
> 
> d) makes it possible to add value to your hardware without changing the 
> OS driver
> 
> e) makes it possible for multiple video chip vendors to compete, without 
> worrying about OS driver issues, or Linux support issues.
> 
> f) this isn't a terribly new idea :)  But it's a good one, IMHO.
> 
> g) even on minimalist 2D-only hardware, you can implement this interface
> 

At this moment, I'm taking a cue from the Linux driver ABI and thinking 
that standardizing the interface would be more limiting than helpful. 
While it might be a pain to have to carry around multiple driver 
versions, the fact that it's all open source kinda makes it easy to make 
drastic changes without hurting anything.

Plus, I don't expect to get it perfect the first time.  The first design 
will have to be very good, but I'm still expecting lots of complaints 
and suggestions from developers.  The second design would probably end 
up being a lot different from the first.  The third design, I expect, 
would change lots of things again, because by then, I'll look like an 
idiot if I don't have bump mapping and fully programmable virtex shaders.

> 
> 7) two-chip solution
> 
> One thing I have pondered, with regards to #6:  what about implementing 
> a multi-core solution?  One core to handle the graphics operations and 
> control the video, and one core a much more generic microcontroller that 
> runs ucLinux, and handles the GL "slow path" stuff.  The advantage of 
> this approach is
> 
> a) 100% of 2D and 3D GL is "done in hardware".  The portions of GL that 
> are not handled by the GPU core are handled by the microcontroller core, 
> which is running a generic firmware.
> 
> b) Since a microcontroller is included, you can upgrade the firmware 
> quite easily to support new OpenGL features.
> 
> c) you don't necessarily have to follow my design of one purpose built 
> GPU core, and one generic microcontroller core.  If your FPGA is big 
> enough, you can have plenty of execution engines (that's the beauty of 
> hardware, it's inherently parallel).
> 
> But OTOH, maybe a multi-core solution will add too much latency into the 
> picture, I dunno.

I've thought about that too.  Two FPGAs are cheaper than one which is 
twice the size.  I could have one chip for the host interface, VGA, and 
perhaps the microcontroller, 2^N chips for rendering pipelines, and 
another for the video/memory controllers.

Not cheap, though.  But at least in this case, it'll also LOOK 
correspondingly expensive.  :)

> 
> 
> 8) I don't find an open source video BIOS terribly exciting.  Yes, I do 
> think it should be open source, but the interest is largely theoretical. 
>  A video BIOS only does a couple things...  implements VESA/etc. BIOS 
> calls, and initializes the hardware based on characteristics specific to 
> the video board (i.e. OEM not GPU details, such as video RAM setup and 
> clocking, which video inputs are actually implemented on the board, 
> ...).  I don't see there being a big programmer or developer interest

I agree it's not a big deal.  But there's no reason to hide anything 
there.  Besides, if someone wants to port it to an obscure platform, 
they don't have to ask for anything.

> 
> Such a video BIOS would probably have to be BSD-licensed, since the 
> video BIOS code may wind up being #included into an OEM's system BIOS.

Yes, that is my plan.

I want to release all software under a BSD license (and MIT) so that it 
can be used under that license or converted to GPL at the option of the 
user.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jeff Garzik]

Timothy Miller wrote:
> AGP and PCI are very similar in terms of the state machine, although the 
> signal drivers are different.  I expect we'll come out with PCI and AGP 
> versions first and then PCIE soon after.  Any "early access" developer 
> boards would be PCI-only.

That's certainly quite reasonable.



> At this moment, I'm taking a cue from the Linux driver ABI and thinking 
> that standardizing the interface would be more limiting than helpful. 

No offense, but I strongly disagree :)

Standardizing the hardware interface lowers the cost of doing an OS 
driver for every chip maker that implements the interface.  The more 
chip makers that implement the interface, the greater the cost savings.

Concrete examples:
* IDE BMDMA interface on PCI.  Practically every ATA chipset in 
production supports this interface.  As a consequence, each individual 
ATA driver mainly involves setting chip-specific timings, and not much else.

* tulip (ethernet MAC).  Its ring and register designs were widely 
imitated across ethernet NICs; as a result, each ethernet driver is 
mainly a "paint by numbers" affair.

* the new AHCI SATA interface, which Intel has on all its new 
motherboards, and SiS soon will as well (as will others, I hope).


> While it might be a pain to have to carry around multiple driver 
> versions, the fact that it's all open source kinda makes it easy to make 
> drastic changes without hurting anything.

Ever-changing hardware and firmware interfaces are a huge pain.  I've 
been writing and maintaining drivers for years... I feel this pain every 
day :)

You want to design a hardware interface that allows you to upgrade and 
enhance your hardware over time, while keeping the changes to the 
hardware<->OS interface itself to a _bare minimum_.  That's why I 
suggested the microcontroller+GPU approach.  The microcontroller's 
firmware can be used to mask the transition between GPU revisions.

Drivers live for many years, even decades, and long after the hardware 
they support has been EOL'd.  It's in everybody's best interests to keep 
the changes to the drivers to a minimum.


> Plus, I don't expect to get it perfect the first time.  The first design 

Part of open source is open development.  If you develop the hardware 
interface in public, actively soliciting feedback during development, 
you'll wind up with a much better interface.

Regards,

	Jeff

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Jeff Garzik wrote:
> Timothy Miller wrote:
> 

> 
>> At this moment, I'm taking a cue from the Linux driver ABI and 
>> thinking that standardizing the interface would be more limiting than 
>> helpful. 
> 
> 
> No offense, but I strongly disagree :)
> 
> Standardizing the hardware interface lowers the cost of doing an OS 
> driver for every chip maker that implements the interface.  The more 
> chip makers that implement the interface, the greater the cost savings.
> 
> Concrete examples:
> * IDE BMDMA interface on PCI.  Practically every ATA chipset in 
> production supports this interface.  As a consequence, each individual 
> ATA driver mainly involves setting chip-specific timings, and not much 
> else.
> 
> * tulip (ethernet MAC).  Its ring and register designs were widely 
> imitated across ethernet NICs; as a result, each ethernet driver is 
> mainly a "paint by numbers" affair.
> 
> * the new AHCI SATA interface, which Intel has on all its new 
> motherboards, and SiS soon will as well (as will others, I hope).

Sure, but those standards had time to evolve to where they are.  I don't 
have that luxury in many respects.

> 
> 
>> While it might be a pain to have to carry around multiple driver 
>> versions, the fact that it's all open source kinda makes it easy to 
>> make drastic changes without hurting anything.
> 
> 
> Ever-changing hardware and firmware interfaces are a huge pain.  I've 
> been writing and maintaining drivers for years... I feel this pain every 
> day :)
> 
> You want to design a hardware interface that allows you to upgrade and 
> enhance your hardware over time, while keeping the changes to the 
> hardware<->OS interface itself to a _bare minimum_.  That's why I 
> suggested the microcontroller+GPU approach.  The microcontroller's 
> firmware can be used to mask the transition between GPU revisions.
> 
> Drivers live for many years, even decades, and long after the hardware 
> they support has been EOL'd.  It's in everybody's best interests to keep 
> the changes to the drivers to a minimum.

Ok, let me say this:  I will not change something I don't have to 
change, but I'm not going to be held back (and hold everyone else back) 
by some mistake I made in the past.

> 
>> Plus, I don't expect to get it perfect the first time.  The first design 
> 
> 
> Part of open source is open development.  If you develop the hardware 
> interface in public, actively soliciting feedback during development, 
> you'll wind up with a much better interface.

Fair enough, although the problem of a competitor getting the jump on us 
that way is yet to be addressed.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jeff Garzik]

Timothy Miller wrote:
> 
> 
> Jeff Garzik wrote:
> 
>> Timothy Miller wrote:
>>
> 
>>
>>> At this moment, I'm taking a cue from the Linux driver ABI and 
>>> thinking that standardizing the interface would be more limiting than 
>>> helpful. 
>>
>>
>>
>> No offense, but I strongly disagree :)
>>
>> Standardizing the hardware interface lowers the cost of doing an OS 
>> driver for every chip maker that implements the interface.  The more 
>> chip makers that implement the interface, the greater the cost savings.
>>
>> Concrete examples:
>> * IDE BMDMA interface on PCI.  Practically every ATA chipset in 
>> production supports this interface.  As a consequence, each individual 
>> ATA driver mainly involves setting chip-specific timings, and not much 
>> else.
>>
>> * tulip (ethernet MAC).  Its ring and register designs were widely 
>> imitated across ethernet NICs; as a result, each ethernet driver is 
>> mainly a "paint by numbers" affair.
>>
>> * the new AHCI SATA interface, which Intel has on all its new 
>> motherboards, and SiS soon will as well (as will others, I hope).
> 
> 
> Sure, but those standards had time to evolve to where they are.  I don't 
> have that luxury in many respects.
> 
>>
>>
>>> While it might be a pain to have to carry around multiple driver 
>>> versions, the fact that it's all open source kinda makes it easy to 
>>> make drastic changes without hurting anything.
>>
>>
>>
>> Ever-changing hardware and firmware interfaces are a huge pain.  I've 
>> been writing and maintaining drivers for years... I feel this pain 
>> every day :)
>>
>> You want to design a hardware interface that allows you to upgrade and 
>> enhance your hardware over time, while keeping the changes to the 
>> hardware<->OS interface itself to a _bare minimum_.  That's why I 
>> suggested the microcontroller+GPU approach.  The microcontroller's 
>> firmware can be used to mask the transition between GPU revisions.
>>
>> Drivers live for many years, even decades, and long after the hardware 
>> they support has been EOL'd.  It's in everybody's best interests to 
>> keep the changes to the drivers to a minimum.
> 
> 
> Ok, let me say this:  I will not change something I don't have to 
> change, but I'm not going to be held back (and hold everyone else back) 
> by some mistake I made in the past.
> 
>>
>>> Plus, I don't expect to get it perfect the first time.  The first design 
>>
>>
>>
>> Part of open source is open development.  If you develop the hardware 
>> interface in public, actively soliciting feedback during development, 
>> you'll wind up with a much better interface.
> 
> 
> Fair enough, although the problem of a competitor getting the jump on us 
> that way is yet to be addressed.

If you start competing based on interface, then that gets us right back 
to where we are now:  vendors so protective of their interface that they 
don't want to open source their drivers...  and each chip requires its 
own separate OS driver, with its own separate engineering team and 
brainshare.

A big bonus of my point #6 is that this is irrelevant -- if everyone is 
using the same, simple "do GL" interface, then you are competing on 
features/cost/time-to-market/etc., not interface.

I thought Alan Cox's point was fairly relevant here:  there are at least 
five(?) video chips out there with hardware docs available, but no 
engineers to write a complex 3D driver from scratch.  If your company 
_leads the industry_ in creating a standardized interface, doesn't 
everybody benefit?

Another advantage is that a simple "do GL" interface is much more 
"future-proof" interface, since it is a very high level interface.

	Jeff

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Alan Cox]

On Gwe, 2004-10-22 at 21:43, Jeff Garzik wrote:
> engineers to write a complex 3D driver from scratch.  If your company 
> _leads the industry_ in creating a standardized interface, doesn't 
> everybody benefit?

Not always - sometimes you win (Soundblaster, IBM PC) and sometimes you
lose. Often you only win if you have a quality differentiator so you can
sneer at the opposition and use words like "PC clone" and
"Soundblaster compatible"

> Another advantage is that a simple "do GL" interface is much more 
> "future-proof" interface, since it is a very high level interface.

Not really, we are heading towards real time raytrace and the hardware
and low level changes dramatically for that (including wanting to do non
light traces for audio mixing, explosion models etc)

Alan

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Francois Romieu]

Alan Cox <alan@lxorguk.ukuu.org.uk> :
[...]
> > Another advantage is that a simple "do GL" interface is much more 
> > "future-proof" interface, since it is a very high level interface.
> 
> Not really, we are heading towards real time raytrace and the hardware
> and low level changes dramatically for that (including wanting to do non
> light traces for audio mixing, explosion models etc)

Just curious: how would it prevent to push standardization through OpenGL
extensions if needed ?

--
Ueimor

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Alan Cox]

On Sad, 2004-10-23 at 18:20, Francois Romieu wrote:
> Just curious: how would it prevent to push standardization through OpenGL
> extensions if needed ?

The current specs are OpenGL like but not openGL - openrt

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Francois Romieu]

Alan Cox <alan@lxorguk.ukuu.org.uk> :
> On Sad, 2004-10-23 at 18:20, Francois Romieu wrote:
> > Just curious: how would it prevent to push standardization through OpenGL
> > extensions if needed ?
> 
> The current specs are OpenGL like but not openGL - openrt

Interesting.

The document "The OpenRT Application Programming Interface" suggests that
the authors are evaluating a move to an OpenGL extension API though.

--
Ueimor

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jeff Garzik]

Timothy Miller wrote:
> Ok, let me say this:  I will not change something I don't have to 
> change, but I'm not going to be held back (and hold everyone else back) 
> by some mistake I made in the past.

Oh, I do agree w/ this.

But if the OS<->hardware interface is kept simple (e.g. simple DMA ring 
of items to execute, or just xfer to video RAM, and perhaps another 
response msg ring) then the impact of any design changes you -do- make 
are mitigated, and the OS driver is kept small and simple as well.

	Jeff

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Roland Dreier]

    Jeff> 4) I am a bit dubious that FPGA will perform at a useful
    Jeff> clock speed.

    Jeff> 7) two-chip solution

    Jeff> One thing I have pondered, with regards to #6: what about
    Jeff> implementing a multi-core solution?  One core to handle the
    Jeff> graphics operations and control the video, and one core a
    Jeff> much more generic microcontroller that runs ucLinux, and
    Jeff> handles the GL "slow path" stuff.  The advantage of this
    Jeff> approach is

It's might be a bit expensive, but one could use a Xilinx Virtex 4
FPGA.  For example a XC4VFX60 has 16 SERDES (which could be used to
implement a 16X PCI Express link) and two embedded PowerPC 405 cores
(which can be used to run Linux -- there is already existing support
in the kernel for this).  The Virtex 4 can be clocked quite high (300
MHz wouldn't be out of the question), and interfaces like a wide DDR2
controller would be possible as well.

In fact the Virtex 4 has so many cool features it might be hard to
convert the code to an ASIC later....

 - R.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Helge Hafting]

On Fri, Oct 22, 2004 at 01:00:04PM -0400, Timothy Miller wrote:
> 
> 
> 
> For this graphics design, and I'm getting into premature implementation 
> details, but I'm a geek, so I can't help myself... I think having some 
> sort of primitive microcontroller at the front end of the design is 
> necessary.  Two major things it would do would be to control the DMA bus 
> mastering, and translate commands (both DMA and PIO) into the parameters 
> required by the rendering engine.
> 

Perhaps a cheap general purpose cpu (last year's duron or celeron)
could be used for this in order to save cost?  You could sell the
cheapest version of the card with an empty socket, because so many
people have such a processor lying around after the last upgrade.

Helge Hafting

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Helge Hafting wrote:
> On Fri, Oct 22, 2004 at 01:00:04PM -0400, Timothy Miller wrote:
> 
>>
>>
>>For this graphics design, and I'm getting into premature implementation 
>>details, but I'm a geek, so I can't help myself... I think having some 
>>sort of primitive microcontroller at the front end of the design is 
>>necessary.  Two major things it would do would be to control the DMA bus 
>>mastering, and translate commands (both DMA and PIO) into the parameters 
>>required by the rendering engine.
>>
> 
> 
> Perhaps a cheap general purpose cpu (last year's duron or celeron)
> could be used for this in order to save cost?  You could sell the
> cheapest version of the card with an empty socket, because so many
> people have such a processor lying around after the last upgrade.


No.

(1) Too expensive
(2) Too complicated
(3) Not good at what we need it to be good at.


No... I'm working on an idea of a CPU which is optimized specifically 
for what we need, nothing more.  AND it must fit inside the FPGA.

Tight fit.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[J.A. Magallon]

On 2004.10.21, Timothy Miller wrote:
> 
...
> > antialiasing (related to alpha blending)
> 
> Antialiasing implies oversampling or supersampling, unless you're 
> thinking about something else.  Sometimes, "antialiasing" is nothing 
> more than a fuzzy texture.  For instance, the way the X11 font server 
> handles antialiased text... it just spits out a grayscale bitmap which 
> can be used as texture.
> 
> > bitblt
> > fast primitive drawing
> 
> No problem.
> 
> > accelerated offscreen operations
> 
> It's funny that people mention that.  Every DDX module I have ever 
> produced has had sophistocated off-screen memory management so that 
> pixmaps could be accelerated.  I never even considered NOT supporting 
> accelerated off-screen surfaces.
> 
> There was one chip I had to support a number of years ago which didn't 
> have separate registers for the base pointers to source and destination 
> surfaces.  That meant that you couldn't use "bitblt" to copy an image 
> from off-screen to on-screen.  What I ended up having to do was 
> implement bitblt as a texture-mapping operation.  (It wound up being 
> slightly faster than the regular bitblt, even if the source and dest 
> were the same surface.)
> 
> Anyhow, in my world, accelerated off-screen surfaces are a given.
> 

Following with this, and looking at the new features that user interfaces
show, I think everything should be off-screen. Look.

Taking OSX as the best example, all the rendering is done offscreen, and
then the result is blittted and alpha merged to the screen. They use
OpenGL to draw each window offscreen, take the image and paste it as texture
onto a rectangular polygon, and then alpha-blend it with the others on the
screen. This is overkill, but allows to do things like put a movie onto
an spinning rectangle...

Without entering to 3D, I would design a card that always renders offscreen.
Each window has its own offscreen buffer, and redraws blit/blend the
pixmap onto the screen. With a good and fast scaler, you can get some
fancy things for free:
- antialiasing: just make the back buffer 2x2 or 4x4 the screen space of
  the window, and resample/filter it. Font rendering just needs to be
  monochrome, but at higher resolution. The rescaler will give you the
  antialiasing. Good work for a DSP.
- real multilayer transparency and shadows
- real time zooming, for things like expocity (metacity version of Exposé):
  no redrawing of contents, just rescaling.
- with some projective math in 2D, you can easily do things like rotations
  over the axis of the screen...simulated.

In short, you need:
- A ton of memory for offscreen buffer. Note: this depends on how much windows
  you want to handle, not on screen res...:)
- Fast (very high res) but simple (no algorthimic antialiasing for lines nor
  fonts) 2D renderer
- An _ultra fast_ scaler/blitter/blender. Scaling can be just 2D, and even
  power-of-2 based with good filtering.

Really simple things, the problem is that they need to be lightning fast.
No 3D needed, the stacking order can be stored in soft and just determines
the order for blending. OSX runs on my iBook, so if a G3 with an ATI 7200
can do, a modern FPGA sure can beat it.

I hope all this cr*k sm*king ends up in something useful for you...

Ah, and you can add later the 3D part as a daughterboard....;)

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandrakelinux release 10.1 (Community) for i586
Linux 2.6.9-rc4-mm1 (gcc 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)) #4

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Raphael Jacquot]

On Thu, 2004-10-21 at 12:08 -0400, Timothy Miller wrote:

> For rendering or for display?  A DVI transmitter won't do more than 8 
> bits per channel, but it can be helpful to have more than 8 bits per 
> channel for greater mathematical precision when compositing images.
> 

heres' an idea, have an option for an SDI and/or HDI transmitter , that
could be done as an add-on card (see SMPTE). those 5000 USD
www.bluefish444.com cards are way too expensive

oh, and throw 512M of ram on there :D

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

["Fernando O. Korndörfer"]

Stephen Wille Padnos wrote:

> OK - so the answer seems to be "if it does the right things, then it 
> may sell"  It's hard to sell a card that doesn't do good 3D these days 
> (re: Matrox Parhelia).  Speaking of the parhelia, I would look at that 
> feature set as a starting point.  10-bit color, multiscreen 
> accelerated 3D, dual DVI, gamma corrected glyph antialiasing, etc.
>
> So, let's try to figure out the right feature set.  (that is what was 
> originally asked for, after all)
>

What I would like to have is a card thar plays nice with weird extended 
VGA text modes like 132x60 and good refresh rates. Most cards don't 
support it and I'm stuck with a 80x25 terminal (and I don't like the 
slow frame buffer modes) or the refresh sucks so much that my eyes 
bleed. Good 2D performance and quality is also required for desktop 
stuff like browsing, coding, DVD, etc.

\m/
----------------
fok@quatro.com.br

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Raphael Jacquot]

On Wed, 2004-10-20 at 22:00 -0400, Stephen Wille Padnos wrote:

> I would think that a chip that has a lot of simple functions, but 
> requires the OS to put them together to actually do something, would be 
> great.  This would be the UNIX mentality brought to hardware: lots of 
> small components that get strung together in ways their creator(s) never 
> imagined.  If there can be a programmable side as well (other than 
> re-burning the FPGA), that would be great.
> 
> I guess I would look at this as an opportunity to make a "visual 
> coprocessor", that also has the hardware necessary to output to a 
> monitor (preferably multiple monitors).

this being an fpga, why not have various contents for it, such as all
the heavy lifters required for theora encoding, for instance,
so, you take 5 of those cards, and build a digital recorder that can
encode 4 tv shows in real time while viewing them at the same time,
you can sell the device for video surveillance, and so on...

Raphael

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Jon Smirl wrote:
> I have heard a lot of complaints from embedded people about having few
> choices for graphics chips. Many of the low end chips from ATI/NVidia
> are no longer in production and you are forced into buying more chip
> than you want. You should ask about this on embedded developer lists.
> 
> For the new X servers you have to have hardware alpha blending.
> Another important feature is accelerated drawing to off-screen
> buffers. Also, DMA command queues help a lot with parallelizing
> drawing.

DMA not only allows for more parallelism, but it's also more efficient 
to transport commands and image data using DMA than with PIO, particular 
on some platforms which do not try to optimize PIOs.

> If you implement VGA you will be able to boot and work in any x86
> system without writing any code other than the BIOS.

I don't think we can get away without supporting some minimal VGA 
functionality.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Shaun Kruger]

> 
> I don't think we can get away without supporting some minimal VGA
> functionality.
> 

Just a thought...  What would be the viability of buying someone elses
low end card design?  Would anyone in the market place be willing to
part with one of their old 2D chipsets with the understanding that it
would be developed and optimized for open source applications?  I
would probably start with a chip maker who has some video chipsets,
but is moving away from it because they don't have the market share
they want...

It's probably crazy, but it doesn't hurt to look around.

Shaun Kruger

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS dpu s:++ a-- C++ UL+++ P+ L+++ E--- W+ N o- K- w++
O M- V- PS+ PE++ Y+ PGP- t 5 X R tv b+ DI+++ D+
G e h-- r* !y
------END GEEK CODE BLOCK------

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Shaun Kruger wrote:
>>I don't think we can get away without supporting some minimal VGA
>>functionality.
>>
> 
> 
> Just a thought...  What would be the viability of buying someone elses
> low end card design?  Would anyone in the market place be willing to
> part with one of their old 2D chipsets with the understanding that it
> would be developed and optimized for open source applications?  I
> would probably start with a chip maker who has some video chipsets,
> but is moving away from it because they don't have the market share
> they want...
> 
> It's probably crazy, but it doesn't hurt to look around.


It's not really design effort that is at issue here.  If the design time 
were zero, we'd still run into the problem of keeping manufacturing 
costs down.  In fact, my whole discussion sorta glosses over design 
effort... I roll it into 'profit' and 'worthwhile'.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Kendall Bennett]

Jon Smirl <jonsmirl@gmail.com> wrote:

> I have heard a lot of complaints from embedded people about having
> few choices for graphics chips. Many of the low end chips from
> ATI/NVidia are no longer in production and you are forced into
> buying more chip than you want. You should ask about this on
> embedded developer lists. 

Most embedded customers care less about overall performance of the 
graphics hardware but more about low cost, low power and longevity. That 
is the reason that ATI committed to continue production of the Radeon 
Mobility M1 for many years to come. That is also the reason the Chips & 
Tech (now Asiliant) 6900 chipset is so popular for embedded customers, 
because they have been using the same hardware for years (but now that 
the 69000 is winding down, many are moving to the Mobility M1).

So the biggest hurdle with selling a solution such as this to the 
embedded market is going to be customer confidence that if they invest 
the time and energy building a solution around a particular chip, that 
the chip will still be around for them to purchase from the suppler in 5-
7 years time. If the company is small and not well known, that might be a 
problem.

Then again if the solution is 'Open' so that the customer could second 
source it from a different vendor, you may get a lot of traction in the 
embedded space. So that might be an angle to play.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Adrian Cox]

On Thu, 2004-10-21 at 20:30, Kendall Bennett wrote:

> Most embedded customers care less about overall performance of the 
> graphics hardware but more about low cost, low power and longevity. That 
> is the reason that ATI committed to continue production of the Radeon 
> Mobility M1 for many years to come. That is also the reason the Chips & 
> Tech (now Asiliant) 6900 chipset is so popular for embedded customers, 
> because they have been using the same hardware for years (but now that 
> the 69000 is winding down, many are moving to the Mobility M1).

Also consider the Fujitsu Coral parts for embedded use:
http://www.fme.gsdc.de/gsdc.htm?macrofam/mb86295.htm

They have a large manual, though I can't vouch for completeness. They
have 3D and alpha blending. They don't have legacy VGA registers, and
they don't have a VGA BIOS. In an embedded system, that's a bonus.

This is the competition facing a new open source graphics chip in the
embedded segment. 

- Adrian Cox
Humboldt Solutions Ltd.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Geert Uytterhoeven]

On Fri, 22 Oct 2004, Adrian Cox wrote:
> On Thu, 2004-10-21 at 20:30, Kendall Bennett wrote:
> > Most embedded customers care less about overall performance of the 
> > graphics hardware but more about low cost, low power and longevity. That 
> > is the reason that ATI committed to continue production of the Radeon 
> > Mobility M1 for many years to come. That is also the reason the Chips & 
> > Tech (now Asiliant) 6900 chipset is so popular for embedded customers, 
> > because they have been using the same hardware for years (but now that 
> > the 69000 is winding down, many are moving to the Mobility M1).
> 
> Also consider the Fujitsu Coral parts for embedded use:
> http://www.fme.gsdc.de/gsdc.htm?macrofam/mb86295.htm
> 
> They have a large manual, though I can't vouch for completeness. They
> have 3D and alpha blending. They don't have legacy VGA registers, and
> they don't have a VGA BIOS. In an embedded system, that's a bonus.
> 
> This is the competition facing a new open source graphics chip in the
> embedded segment. 

And the embedded solutions from Silicon Motion.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Adrian Cox]

On Fri, 2004-10-22 at 21:10, Geert Uytterhoeven wrote:
> And the embedded solutions from Silicon Motion.

Good choice on x86, but with a couple of problems:
No big-endian 16bpp mode for PowerPC.
Poor documentation of initialisation and setting video modes.

In the end we set the video mode we wanted in Windows and copied the
register settings across to the Linux machine.

- Adrian Cox
Humboldt Solutions Ltd.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Geert Uytterhoeven]

On Wed, 20 Oct 2004, Jon Smirl wrote:
> If you implement VGA you will be able to boot and work in any x86
> system without writing any code other than the BIOS.

Ugh... I prefer _not_ to have VGA compatibility.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Geert Uytterhoeven wrote:
> On Wed, 20 Oct 2004, Jon Smirl wrote:
> 
>>If you implement VGA you will be able to boot and work in any x86
>>system without writing any code other than the BIOS.
> 
> 
> Ugh... I prefer _not_ to have VGA compatibility.

Well, some people agree with you, but if I can squeeze it small enough, 
it's worth having because it maximized compatibility.  It's vital for 
x86 consoles.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Helge Hafting]

On Fri, Oct 22, 2004 at 06:07:37PM -0400, Timothy Miller wrote:
> 
> 
> Geert Uytterhoeven wrote:
> >On Wed, 20 Oct 2004, Jon Smirl wrote:
> >
> >>If you implement VGA you will be able to boot and work in any x86
> >>system without writing any code other than the BIOS.
> >
> >
> >Ugh... I prefer _not_ to have VGA compatibility.
> 
> Well, some people agree with you, but if I can squeeze it small enough, 
> it's worth having because it maximized compatibility.  It's vital for 
> x86 consoles.

I can't see how it is "vital", or even makes a difference at all.
Other than upping the price a bit.  The pc doesn't need VGA compatibility
to boot - because you supply a video bios.  The mainboard bios
uses the video bios. (There have been pc's with ibm-incompatible
displays before)
Linux d(and other open os'es) doesn�'t need VGA at all, because 
you supply docs.  You probably won't even have to write the driver
yourself.
Windows doesn't need VGA - if you supply a windows driver.  That
shouldn�'t be hard to do.  

Now, what's left? :-)

Helge Hafting

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Helge Hafting wrote:
> On Fri, Oct 22, 2004 at 06:07:37PM -0400, Timothy Miller wrote:
> 
>>
>>Geert Uytterhoeven wrote:
>>
>>>On Wed, 20 Oct 2004, Jon Smirl wrote:
>>>
>>>
>>>>If you implement VGA you will be able to boot and work in any x86
>>>>system without writing any code other than the BIOS.
>>>
>>>
>>>Ugh... I prefer _not_ to have VGA compatibility.
>>
>>Well, some people agree with you, but if I can squeeze it small enough, 
>>it's worth having because it maximized compatibility.  It's vital for 
>>x86 consoles.
> 
> 
> I can't see how it is "vital", or even makes a difference at all.
> Other than upping the price a bit.  The pc doesn't need VGA compatibility
> to boot - because you supply a video bios.  The mainboard bios
> uses the video bios. (There have been pc's with ibm-incompatible
> displays before)
> Linux d(and other open os'es) doesn�'t need VGA at all, because 
> you supply docs.  You probably won't even have to write the driver
> yourself.
> Windows doesn't need VGA - if you supply a windows driver.  That
> shouldn�'t be hard to do.  


We have a number of cards which do not support VGA, and a few years ago, 
I experimented with the idea of writing a VGA BIOS which emulated the 
VGA text screen in software.

What I discovered was that absolutely everything, including the DOS 
shell, expects there to be REAL VGA (or CGA or whatever) hardware there, 
so hooking int 10 just did not do the job... it practically never got 
called.  What I ended up doing was hooking the timer interrupt and 
comparing the text screen against a shadow copy.  That worked very well 
for most DOS applications... except for those which tried to do anything 
in protected mode.  The instant an OS switched to protected mode, the 
interrupt handler got blown away and the display froze.

Then we though we'd put a proper driver into the OS, but the problem is 
that in Windows and Solaris, the console driver doesn't kick in until 
WAY late in the boot process, so you end up with a useless console for 
THE MAJORITY of the boot process.

For Windows, there is a requirement for 640x480x4 and some 320x480x?? 
mode to be supported by the hardware using the standard VGA IO space 
registers.  That is, IF you want a console.  Yes, you can boot without 
VGA, but your screen is blank until the driver kicks in, so if there's a 
PROBLEM, you're hosed.

VGA is so "expected" that pretty much everything just assumes it's there 
and bangs on the hardware directly.

The only thing the VGA BIOS does on most modern cards is configure the 
non-VGA bits of the card to function properly and get it into text mode. 
  After that, it's all VGA until an OS loads a graphics driver.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Helge Hafting]

On Mon, Oct 25, 2004 at 11:47:51AM -0400, Timothy Miller wrote:
> 
> >I can't see how it is "vital", or even makes a difference at all.
> >Other than upping the price a bit.  The pc doesn't need VGA compatibility
> >to boot - because you supply a video bios.  The mainboard bios
> >uses the video bios. (There have been pc's with ibm-incompatible
> >displays before)
> >Linux d(and other open os'es) doesn�'t need VGA at all, because 
> >you supply docs.  You probably won't even have to write the driver
> >yourself.
> >Windows doesn't need VGA - if you supply a windows driver.  That
> >shouldn�'t be hard to do.  
> 
> 
> We have a number of cards which do not support VGA, and a few years ago, 
> I experimented with the idea of writing a VGA BIOS which emulated the 
> VGA text screen in software.
> 
> What I discovered was that absolutely everything, including the DOS 
> shell, expects there to be REAL VGA (or CGA or whatever) hardware there, 

Remember who you're talking to. :-)
VGA, (or at least CGA) may indeed be necessary to run dos.
(Well, dos 2.11 ran fine on the incomptaible DEC rainbow...)
So if you need dos compatibility - sure.  

But this is the linux kernel list - you asked what the
open source community want.  We _really_ don't care about dos.
And I believe this is true for many others too - dos _is_ dead.
Even the microsoft fans use windows exclusively.
So don't worry about dos - it is such a niche os today.

> so hooking int 10 just did not do the job... it practically never got 
> called.  What I ended up doing was hooking the timer interrupt and 
> comparing the text screen against a shadow copy.  That worked very well 
> for most DOS applications... except for those which tried to do anything 
> in protected mode.  The instant an OS switched to protected mode, the 
> interrupt handler got blown away and the display froze.

Sure - but who's running dos these days?  Is there any market share
in _dos_?  And there is freedos, for which the source code is
available and free.  So if you really need dos for something,
(such as flashing mainboard bioses?) then add the necessary support
to freedos. 
 
> Then we though we'd put a proper driver into the OS, but the problem is 
> that in Windows and Solaris, the console driver doesn't kick in until 
> WAY late in the boot process, so you end up with a useless console for 
> THE MAJORITY of the boot process.
> 
> For Windows, there is a requirement for 640x480x4 and some 320x480x?? 
> mode to be supported by the hardware using the standard VGA IO space 
> registers.  That is, IF you want a console.  Yes, you can boot without 
> VGA, but your screen is blank until the driver kicks in, so if there's a 
> PROBLEM, you're hosed.

Sure - that could be a problem.  This depends on how much you want to
sell to windows users.  We linux users, and other open source users,
don't worry that much about windows console deficiencies.  
Particularly considering how the common windows user doesn't use his
console anyway - ms hides everything behind a pretty "Please wait,
windows is starting" screen. And they reinstall if something goes wrong :-/

You are sure that an "early boot" console driver for windows is impossible?
Ms provides no clue about replacing this thing?  Rendering text onto vga
must be done somewhere, possibly in a library that could be replaced.

> 
> VGA is so "expected" that pretty much everything just assumes it's there 
> and bangs on the hardware directly.

So it is a question of what you want to support, and how numerous
these VGA users are.  Perhaps you won't have to implement _all_
of VGA though - that might save space in your FPGA.  Full VGA have some
rarely used oddball modes and features - and backwards compatibility
cruft.  Who needs the EGA modes or ability to load textmode
fonts for example - when all the user need is to see some
boot messages before the real driver takes over.

If you go for VGA, then I hope the VGA bits will be
somewhat optional or possible to disable, so the VGA bits
doesn�'t get in the way when trying to use several cards
simultaneously.  You may make cards that cooperate nicely with
each other - but there may be other card(s) in the machine
too that also mess with VGA registers at strange times.

If VGA is implemented entirely in the FPGA then perhaps there
will be alternate FPGA firmwares for different purposes. (Surely
cheaper than making different boards).  One variant could
be VGA-less, the space may then be used for other purposes. An 
extra 3D-unit of some sort perhaps. :-)

Helge Hafting

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Helge Hafting wrote:
> On Mon, Oct 25, 2004 at 11:47:51AM -0400, Timothy Miller wrote:
> 
>>>I can't see how it is "vital", or even makes a difference at all.
>>>Other than upping the price a bit.  The pc doesn't need VGA compatibility
>>>to boot - because you supply a video bios.  The mainboard bios
>>>uses the video bios. (There have been pc's with ibm-incompatible
>>>displays before)
>>>Linux d(and other open os'es) doesn�'t need VGA at all, because 
>>>you supply docs.  You probably won't even have to write the driver
>>>yourself.
>>>Windows doesn't need VGA - if you supply a windows driver.  That
>>>shouldn�'t be hard to do.  
>>
>>
>>We have a number of cards which do not support VGA, and a few years ago, 
>>I experimented with the idea of writing a VGA BIOS which emulated the 
>>VGA text screen in software.
>>
>>What I discovered was that absolutely everything, including the DOS 
>>shell, expects there to be REAL VGA (or CGA or whatever) hardware there, 
> 
> 
> Remember who you're talking to. :-)
> VGA, (or at least CGA) may indeed be necessary to run dos.
> (Well, dos 2.11 ran fine on the incomptaible DEC rainbow...)
> So if you need dos compatibility - sure.  
> 
> But this is the linux kernel list - you asked what the
> open source community want.  We _really_ don't care about dos.
> And I believe this is true for many others too - dos _is_ dead.
> Even the microsoft fans use windows exclusively.
> So don't worry about dos - it is such a niche os today.

Forget DOS.  How about the BIOS configuration screen?  How about all 
those messages that come up before the boot-loader has even been fetched 
from disk?

> 
> 
>>so hooking int 10 just did not do the job... it practically never got 
>>called.  What I ended up doing was hooking the timer interrupt and 
>>comparing the text screen against a shadow copy.  That worked very well 
>>for most DOS applications... except for those which tried to do anything 
>>in protected mode.  The instant an OS switched to protected mode, the 
>>interrupt handler got blown away and the display froze.
> 
> 
> Sure - but who's running dos these days?  Is there any market share
> in _dos_?  And there is freedos, for which the source code is
> available and free.  So if you really need dos for something,
> (such as flashing mainboard bioses?) then add the necessary support
> to freedos. 

Don't get stuck on DOS.  What it does represents what lots of other 
things do with regard to the display.  They assume CGA-compatible 
hardware is there and bang on the hardware directly.

Also, as countless people have said, it would be foolish to shut out 
Windows users.  Many people would like this card so that they can dual-boot.

>  
> 
>>Then we though we'd put a proper driver into the OS, but the problem is 
>>that in Windows and Solaris, the console driver doesn't kick in until 
>>WAY late in the boot process, so you end up with a useless console for 
>>THE MAJORITY of the boot process.
>>
>>For Windows, there is a requirement for 640x480x4 and some 320x480x?? 
>>mode to be supported by the hardware using the standard VGA IO space 
>>registers.  That is, IF you want a console.  Yes, you can boot without 
>>VGA, but your screen is blank until the driver kicks in, so if there's a 
>>PROBLEM, you're hosed.
> 
> 
> Sure - that could be a problem.  This depends on how much you want to
> sell to windows users.  We linux users, and other open source users,
> don't worry that much about windows console deficiencies.  
> Particularly considering how the common windows user doesn't use his
> console anyway - ms hides everything behind a pretty "Please wait,
> windows is starting" screen. And they reinstall if something goes wrong :-/

I see a bit of irony in calling the card "platform agnostic" if it 
doesn't work right with Windows.

> 
> You are sure that an "early boot" console driver for windows is impossible?
> Ms provides no clue about replacing this thing?  Rendering text onto vga
> must be done somewhere, possibly in a library that could be replaced.

Unfortunately, Microsoft dictates the rules here and they're not going 
to change for us.

Remember the BIOS config screen.

> 
>>VGA is so "expected" that pretty much everything just assumes it's there 
>>and bangs on the hardware directly.
> 
> 
> So it is a question of what you want to support, and how numerous
> these VGA users are.  Perhaps you won't have to implement _all_
> of VGA though - that might save space in your FPGA.  Full VGA have some
> rarely used oddball modes and features - and backwards compatibility
> cruft.  Who needs the EGA modes or ability to load textmode
> fonts for example - when all the user need is to see some
> boot messages before the real driver takes over.

Exactly.  We need the absolute minimum.  I'm thinking there's got to be 
some way to do most of it by emulating it in the setup engine.

Big ROMs which contain lots of setup engine code are NOT a problem.

Consider this:  POST configures the PC to see one of the framebuffer 
apertures as the "screen" for 80x25 text or 640x480 VGA.  The setup 
engine just sits there and continuously translates from that to graphics 
for the video controller.

There may be some issues with the "io space" accesses, but we'll just 
have to design it so that the setup engine can intercept those (kinda 
like it'll intercept pseudo-registers for 2D emulation).

> If you go for VGA, then I hope the VGA bits will be
> somewhat optional or possible to disable, so the VGA bits
> doesn�'t get in the way when trying to use several cards
> simultaneously.  You may make cards that cooperate nicely with
> each other - but there may be other card(s) in the machine
> too that also mess with VGA registers at strange times.

At the very minimum, the host controller will have to have the logic 
necessary to handle io space accesses.  The thing is, for a non-console, 
they won't get enabled at POST.  Problem solved.

If necessary, we'll add a jumper to the board.

> 
> If VGA is implemented entirely in the FPGA then perhaps there
> will be alternate FPGA firmwares for different purposes. (Surely
> cheaper than making different boards).  One variant could
> be VGA-less, the space may then be used for other purposes. An 
> extra 3D-unit of some sort perhaps. :-)

I want to minimize dedicated logic for VGA.

Re: HARDWARE:Graphics Cards or TOE?

[Nuno Silva]

Timothy Miller wrote:

...

> - flashable PROM so that boot code can be added for more platforms
> - usable as the console on any platform that can take a PCI, AGP, or 
> PCI-Express card
> - downloadable schematic for the circuit board
> - FPGA-based graphics engine so it's reprogrammable
> - instructions on how to reprogram the FPGA, so it's hackable

Something tells me that many people in this ml will hijack your 
"video-output-device" and use it as a TOE over AGP/PCIe instead :-)

Peace,
Nuno Silva

Re: HARDWARE:Graphics Cards or TOE?

[Timothy Miller]

Nuno Silva wrote:
> Timothy Miller wrote:
> 
> ...
> 
>> - flashable PROM so that boot code can be added for more platforms
>> - usable as the console on any platform that can take a PCI, AGP, or 
>> PCI-Express card
>> - downloadable schematic for the circuit board
>> - FPGA-based graphics engine so it's reprogrammable
>> - instructions on how to reprogram the FPGA, so it's hackable
> 
> 
> Something tells me that many people in this ml will hijack your 
> "video-output-device" and use it as a TOE over AGP/PCIe instead :-)

I intend that people should be able to buy this product and "hijack" it 
for uses I did not intend.  If they want to turn it into a network card, 
I'd think that was very cool.  :)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Kurt Wall]

On Wed, Oct 20, 2004 at 06:02:51PM -0400, Timothy Miller took 163 lines to write:
> I've brought this up the following subject before on LKML, but it wasn't 
> really resolved, and also, management at my company (Tech Source) has 
> only now started to warm up to my idea.

[long snip]

> So, here are some questions to answer:
> 
> (1) Would the sales volumes of this product be enough to make it worth 
> producing (ie. profitable)?

Hard to say. My crystal ball doesn't work any better than yours.

> (2) How much would you be willing to pay for it?

It depends. I'd probably be willing to drop $100 USD on such a card simply
to vote with my wallet what my priorities and values are.

> (3) How do you feel about the choice of neglecting 3D performance as a 
> priority?  How important is 3D performance?  In what cases is it not?

For most of what I do, 3-D is irrelevant. It makes nice eye candy, but
that's about it. For games, hardware-accelerated 3-D is more or less
required.

> (4) How much extra would you be willing to pay for excellent 3D performance?

An extra $100 USD. For superior 3-D performance (and a buttload of RAM on
the card), I'd go an extra $200.

> (5) What's most important to you, performance, price, or stability?

Stability, followed by performance. I'm less price sensitive than I used to
be.

Regards,

Kurt

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Kurt Wall wrote:

>>(5) What's most important to you, performance, price, or stability?
> 
> 
> Stability, followed by performance. I'm less price sensitive than I used to
> be.
> 


But only if there are lots of people and/or system integrators who feel 
the same would we have a viable product.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Pascal Patry]

I have to say that it's a really good idea... For my point of view, I 
think that stability is the best point to get. But getting a such type 
of graphic board with the open source community will be stable enough in 
a small amount of time...

As I said, I agree completely with the subject and I think that trying 
to get a small team to begin development is the first step to go though...

Pascal


Timothy Miller wrote:

>
>
> Kurt Wall wrote:
>
>>> (5) What's most important to you, performance, price, or stability?
>>
>>
>>
>> Stability, followed by performance. I'm less price sensitive than I 
>> used to
>> be.
>>
>
>
> But only if there are lots of people and/or system integrators who 
> feel the same would we have a viable product.
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Adrian Bunk]

On Wed, Oct 20, 2004 at 06:02:51PM -0400, Timothy Miller wrote:

>...
> (1) Would the sales volumes of this product be enough to make it worth 
> producing (ie. profitable)?

no

> (2) How much would you be willing to pay for it?

with DVI output:
29 Euro

without DVI output:
< 10 Euro (current Ebay prices including shipping for a Matrox G200 
           which is a really good 2D card)

> (3) How do you feel about the choice of neglecting 3D performance as a 
> priority?  How important is 3D performance?  In what cases is it not?
> (4) How much extra would you be willing to pay for excellent 3D performance?

3D is a nice feature, but I wouldn't pay extra money for it

> (5) What's most important to you, performance, price, or stability?

1. stability
2. no fan
3. price

> Feel free to insert your own questions and answers here.  Remember, I'm 
> an engineer.  My understanding of business is dilettantish at best.
>...

I do not care that much about 3D performance.

My graphics card has a ATI Radeon 7000 and offers as output
VGA, DVI and VideoCinch. The card has no fan.

This card is more than enough for all my uses (I use DVI, but not 
VideoCinch; even Tuxracer runs fine although I wouldn't need the 3D 
suppport).

This card is well-supported with open source drivers (and I'm using 
only open source drivers).

I didn't experience any problems with it.

This card which is more than enough for all of my uses is sold in it's 
32 MB version for 29 Euro [1] in many shops.

cu
Adrian

[1] that's not a special offer, this price is stable for at about half a
    year now

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Simon Braunschmidt]

If i could buy a card with complete documentation as original poster 
proposed, and with reprogramable logic, i would be willing to pay as 
much as 125 EURO/Dollar.

Key features for me are:

DVI out
no fan
very low power requirements, something like < 4.5Watt
must be able to play fair with my second gfx card for gaming(deactivated 
when i work)
basic SDK

Cool extras would be (2D):
video acceleration (compatible with XvMC)
texture/overlay scaling in hardware
alpha blending
advanced SDK

For 3D acceleration in the range of something between geforce1 and 
geforce2 (i own a geforce2 and its fast enough for every game i play)
i would pay an extra $$$ like 150-200 EURO/Dollar.

Lots of money, but thinking of lost time reading bug-reports, howtos and 
fixing all kinds of instability related problems, its allmost nothing.

Simon

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Jurriaan]

From: Simon Braunschmidt <braunschmidt@corscience.de>
Date: Thu, Oct 21, 2004 at 03:14:26PM +0200
> If i could buy a card with complete documentation as original poster 
> proposed, and with reprogramable logic, i would be willing to pay as 
> much as 125 EURO/Dollar.
> 
> Key features for me are:
> 
> DVI out
> no fan
> very low power requirements, something like < 4.5Watt
> must be able to play fair with my second gfx card for gaming(deactivated 
> when i work)
> basic SDK
> 
> Cool extras would be (2D):
> video acceleration (compatible with XvMC)

YES - that I'd like to see, and make it hdtv-compatible (allowing to
view hdtv-streams on say a P4 2.0)

Also, I want the very best signal quality - the best 1600x1200@100 Hz or
1920x1080@80 Hz that money can buy.

I'd be willing to pay up to US$ 250 for such a card.

Jurriaan
-- 
I am the wrong number that wakes you at 3:00 a.m.
	Darkwing Duck
Debian (Unstable) GNU/Linux 2.6.9-rc3-mm1 2x6078 bogomips load 0.76

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Adrian Bunk wrote:
> On Wed, Oct 20, 2004 at 06:02:51PM -0400, Timothy Miller wrote:
> 
> 
>>...
>>(1) Would the sales volumes of this product be enough to make it worth 
>>producing (ie. profitable)?
> 
> 
> no


In other words, Richard Stallman is too idealistic.  :)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Alan Cox]

On Iau, 2004-10-21 at 17:26, Timothy Miller wrote:
> > no
> In other words, Richard Stallman is too idealistic.  :)

I don't think even rms believes that hardware should be free in that
sense. 

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Alan Cox wrote:
> On Iau, 2004-10-21 at 17:26, Timothy Miller wrote:
> 
>>>no
>>
>>In other words, Richard Stallman is too idealistic.  :)
> 
> 
> I don't think even rms believes that hardware should be free in that
> sense. 


That's because hardware is tangible.  But what I meant was that in order 
to have open source drivers, there has to be a lot of disclosure of the 
inner workings of the hardware.  That disclosure comes with certain risks.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Tobias Diedrich]

Timothy Miller wrote:

> (2) How much would you be willing to pay for it?

For a GFX card without 3D I'd say about $30, maybe double it for the
geekness/support the idea factor.

> (5) What's most important to you, performance, price, or stability?
> Please read the FAQ at  http://www.tux.org/lkml/

I'd like to see a graphics card with a really good YV12 to RGB Overlay
and/or a blitter that can do the conversion.  A lot of cards do
ok when scaling YUY2, but have problems with YV12 (This _might_ be a
driver problem).  Scaling is more difficult with YV12 because
the chroma resolution is half the luma resolution in both dimensions
and not just in the horizontal direction.

Also more than 8Bits per Channel could noticably improve video quality.
(AFAIK good Standalone DVD Players do 10bits per component, which is the
maximum the mpeg2 spec supports)

Many cards have 10bit DACs to improve precision when gamma correction is
used, but AFAIK you can't directly output video with that precision.

I also wondered wether it would be feasible to have a video capture card
directly capture into GFX memory, show the video being captured on the
overlay and do a dma transfer into cpu memory while reordering the data
as to improve cpu cacheline usage for DCT processing (Have the
macroblocks use contiguous memory chunks or let the card do
the DCT). :-)

And even if the card doesn't do 3D it might be useful to have some pixel
shader functionality, IIRC the ATI Windoze drivers can use the pixel
shaders to do deblock/dering video postprocessing on the card.

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de
失敗する可能性のあるものは、失敗する。
np: RAID - 不誠実な道の上でのサバイバル

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Florian Schmidt]

On Wed, 20 Oct 2004 18:02:51 -0400
Timothy Miller <miller@techsource.com> wrote:

> In short, what I have been proposing to my superiors is the development 
> of a graphics card specifically for open source systems.  This means 
> full disclosure on all register interfaces so that no one has to deal 
> with anything closed source (BIOS included).  The goal here is to 
> produce a graphics card which is a Free Software geek's dream in terms 
> of openness.  If Tech Source (me being its avatar) can develop a 
> relationship with the Linux (and BSD) community, users and developers 
> can get a product that they want without being locked out by hardware 
> vendors that feel they have to protect every last little bit of IP 
> relating to their products.  The EXPRESS PURPOSE of this product is to 
> be free-software-friendly.

Maybe a graphics card is too coslty to develop and implement. I would really
like to see such a project for an open soundcard. I mean how expensive can
it be to slap a dsp plus some DA/AD's on a pci board? A simple 4in/4out card
doing up to 48/16 or even 96/24 could probably be developed much cheaper
than a graphics card. And it could serve as a test on how people would react
to such an "open" hardware product.

flo

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Lee Revell]

On Fri, 2004-10-22 at 01:02 +0200, Florian Schmidt wrote:
> Maybe a graphics card is too coslty to develop and implement. I would really
> like to see such a project for an open soundcard. I mean how expensive can
> it be to slap a dsp plus some DA/AD's on a pci board? A simple 4in/4out card
> doing up to 48/16 or even 96/24 could probably be developed much cheaper
> than a graphics card. And it could serve as a test on how people would react
> to such an "open" hardware product.

I think Florian is on to something.  The market for pro audio hardware
is WAY more forgiving than 3D cards.  There are many, many smaller
companies doing quite well.  This is still a business where some guy in
his garage in Utah (MetaSonix) designs and builds effects pedals by
hand, and a band like U2 will hear one somewhere and immediately send
their people down to scoop up every MetaSonix box in NYC...  Unlike in
the computer industry, people are not easily fooled by hype and
marketing, they are professionals and know what sounds good.

The big players are companies like DigiDesign and MoTU, where what
people really need is the software, but they bundle it with
sometimes-good, sometimes-bad, always-overpriced hardware so it's a
little harder to figure out how hard you are being screwed.  The
DigiDesign Mbox for example is the absolute entry-level Pro Tools rig.
It consists of a crappy USB (!) sound interface, 2 in/2 out, no DSP,
plus a dumbed down version their software of course, and they charge
like $450 for it.  If you want something decent, say a FireWire
interface with analog pres and a SHARC DSP, you are looking at
$800-2000.

They are making money hand over fist.  A good chunk of the market is
people who _need_ a DAW, and cost is often no object.  Even the most
Luddite recording engineers, people who master to analog tape and get
their vocal sound by plugging the mic into a crappy guitar amp, have to
use Pro Tools to edit and track because the alternative is things like
"window edits", where you literally cut out a square of tape with a
razor to splice in a new take.

Ever heard of an "iLok" aka a "Pro Tools Key"?  It's a USB
authentication key that you can buy at almost any music store.  Because,
of course, once you have the Pro Tools rig, if you want to do things
like sync to SMPTE, or import another file format, please insert your
key and have your credit card ready...

I could go on and on, but I think you get the picture - there is a huge
market out there, dominated by crappy software, bundled with good
hardware.  It's like if the Microsoft tax were 75%.  On the other hand
there is a lot of _amazing_ proprietary software that is not tied to any
hardware.  And of course there are some great Linux audio apps.
Unfortunately there is no "open" audio hardware available, and currently
with the exception of RME Linux audio users are mostly stuck with the
low end stuff.

For example, no FireWire audio interfaces are supported, because the
people who make them make WAY too much money selling software upgrades.
So we are stuck reverse engineering consumer and semi-pro soundcards.
The ALSA developers are too busy fixing stupid bugs caused by the
chronic lack of docs for crappy integrated sound hardware, and vendors
who release completely different and incompatible variations of their
cheap laptop AC97 card, just to make it a few cents cheaper...  no one
has had the time, inclination, and ability to reverse engineer a real
device.  Besides, reverse engineering even simple devices like sound
cards is a losing battle, as soon as you figure it out then hardware
makers find some new corner to cut...

If there were one decent, sub-$500 piece of open sound hardware (no
offense to RME but they are definitely at the high end of the market) it
would sell like hotcakes.  People on LAU would be lining up around the
block, Windows and Mac users too.  There are more than a few would-be
Linux audio systems integrators, who _know_ they could do better than
the proprietary folks, but are waiting for any acceptable hardware to
become available.

How much would a 6in/6out FireWire interface, with XLR and 1/4"
connections on the chassis or via a dongle, decent DA/AD converters, and
a SHARC DSP cost to produce?  A guitar level input with trim, like on
the old Tascam 4-tracks, would be a very nice feature; many cards claim
you can plug a guitar into them but the impedance is wrong.  You could
offer a version with more DSP power, and worse quality DAC/ADC, for low
powered/embedded/stomp box apps, and maybe one with better converters
and less DSP power for high end systems. 

Anyway, my point is that Nvidia and ATI are very, very good at what they
do.  Digi & their ilk were the first to market, made a killing and are
now fat and lazy and resting on their laurels, just begging to be taken
down...

;-P

Lee

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Rene Herman]

Timothy Miller wrote:

Reading this rather late and I see you've already gotten many replies. I 
would like to emphasize the "onboard" reply you got though.

> (1) Would the sales volumes of this product be enough to make it worth 
> producing (ie. profitable)?

If you'd be producing "a videocard", unlikely. To a gamer, openness will 
not offset non-stellar performance and stellar performance would very 
likely propel the cost of this card very quickly far past the cost of a 
comparable nVidia or ATI card.

Your users then, would likely need to be non-gamers such as myself. For 
reference, my current videocard is an ATI Rage128 with 16MB and a TV-OUT 
with which I'm still very pleased. For me, you would be competing with 
onboard solutions, and especially Intel's onboard solutions since as far 
as I'm aware those _are_ actually openly documented, at least upto the 
level that I consider it important. That is, I can go read a datasheet, 
go "cool stuff this" and then compile a completely opensource driver 
into any kernel I please.

My first computer was AMD based, my current computer is almost entirely 
AMD (CPU and chipset, that is) and my next computer seems likely to be 
an AMD64 machine. However, I should really say "EM64T machine", since it 
is probably going to be an Intel one, completely due to the chipsets.

I'd actually prefer AMD, but the AMD market isn't offfering a solution 
comparable to Intel's integrated video. That means AMD and VIA and the 
like are loosing (some, mine at least :-) money since they don't have a 
graphics solution comparable to Intel, in terms of openness and 
basicness. I believe really only nForce and (to a degree; I hardly see 
it) ATI IGP are available in the AMD motherboard market. If you could 
produce something as good or better as Intel's, you might want to go 
talk to VIA, or AMD directly, and have them license it from you and 
massproduce it into their chipsets.

> (2) How much would you be willing to pay for it?

Nothing. I want it on my motherboard.

> (3) How do you feel about the choice of neglecting 3D performance as a 
> priority?  How important is 3D performance?  In what cases is it not?

It's okay, and especially when board makers have the option to also 
offer a "slotted" videocard in addition (or instead of) your onboard chip.

> (4) How much extra would you be willing to pay for excellent 3D 
> performance?

Nothing.

> (5) What's most important to you, performance, price, or stability?

Stability, no fan, (very) good 2d picture quality/stability, price, 
gadgets (tv-out), performance.

Rene.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Kevin Puetz]

Rene Herman wrote:

> I'd actually prefer AMD, but the AMD market isn't offfering a solution
> comparable to Intel's integrated video. That means AMD and VIA and the
> like are loosing (some, mine at least :-) money since they don't have a
> graphics solution comparable to Intel, in terms of openness and
> basicness. I believe really only nForce and (to a degree; I hardly see
> it) ATI IGP are available in the AMD motherboard market. If you could
> produce something as good or better as Intel's, you might want to go
> talk to VIA, or AMD directly, and have them license it from you and
> massproduce it into their chipsets.

Well, there are the via k8m800 chipsets. That's (I believe?) a unichrome2
IGP, which should have opensource DRI support via unichrome.sf.net (caveat
- I have a unichrome1 in an epia M1000, not the athlon64 variant). It's no
hot-rod performer, but it's good enough for tuxracer and neverball. I have
no idea how it really compares performance-wise to the intel stuff, but it
does at least have open drivers and reasonable GL acceleration.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Rene Herman]

Kevin Puetz wrote:

> Rene Herman wrote:
> 
>>I'd actually prefer AMD, but the AMD market isn't offfering a solution
>>comparable to Intel's integrated video. That means AMD and VIA and the
>>like are loosing (some, mine at least :-) money since they don't have a
>>graphics solution comparable to Intel, in terms of openness and
>>basicness. I believe really only nForce and (to a degree; I hardly see
>>it) ATI IGP are available in the AMD motherboard market. If you could
>>produce something as good or better as Intel's, you might want to go
>>talk to VIA, or AMD directly, and have them license it from you and
>>massproduce it into their chipsets.
> 
> 
> Well, there are the via k8m800 chipsets.

I see, must say I hadn't seen it before. Have basically stopped paying 
attention to VIA some time ago but read lately (mostly on this list, I 
believe) that they were actually getting better at opening up some 
things. When I just now checked, I see there's still not a datasheet in 
sight though. As far as I can see best I can hope for is that VIA would 
consider me "an appropriate open source developer" which, considering 
that I will not be developing for many things I still like to read the 
datasheets for, seems unlikely. But more to the point, even if it were 
likely, the competition here is developer.intel.com, not $RANDOMCORP's 
discretion.

 From this, VIA seems a bit better than nVidia (if only because it would 
be hard to be worse) and comparable to ATI's developer program. Since I 
see that all the rest of their chipsets is equally undocumented, at 
least publicly, for me personally this means I will not be buying their 
products.

> That's (I believe?) a unichrome2 IGP, which should have opensource
> DRI support via unichrome.sf.net (caveat - I have a unichrome1 in an
> epia M1000, not the athlon64 variant). It's no hot-rod performer, but
> it's good enough for tuxracer and neverball. I have no idea how it
> really compares performance-wise to the intel stuff, but it does at
> least have open drivers and reasonable GL acceleration.

I see from unichrome.sf.net that they are piecing together register info 
from drivers they got VIA to release...

Okay, so talking to VIA was a bad idea. AMD is good with documentation 
(looking at printed copies of the AMD 751/756 datasheets as we speak) 
but haven't been too interested in chipsets upto now. They generally do 
one or a few and lay off when VIA gets upto speed. Not having anything 
basic and open available _is_ driving some customers to Intel though, so 
maybe they're still interested in it for a basic chipset, with VIA for 
the gadget-add market.

Rene.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Lee Revell]

On Sat, 2004-10-23 at 19:02 +0200, Rene Herman wrote:
> I see from unichrome.sf.net that they are piecing together register info 
> from drivers they got VIA to release...

They are not "piecing it together".  They have signed NDA with VIA to
get docs.  Many vendors have no objection to open source drivers, they
just want to know who has their chip documentation. 

Anyway the 3D support is somewhat lacking, not for lack of information
but for lack of developers.  Maybe if you want to improve the 3D driver
then VIA would work with you.

Lee 

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Rene Herman]

Lee Revell wrote:

> On Sat, 2004-10-23 at 19:02 +0200, Rene Herman wrote:
> 
>>I see from unichrome.sf.net that they are piecing together register info 
>>from drivers they got VIA to release...
> 
> They are not "piecing it together".  They have signed NDA with VIA to
> get docs.

http://sourceforge.net/docman/display_doc.php?docid=23693&group_id=102048

Rene.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Helge Hafting]

On 21-10-2004 00:02:51, Timothy Miller wrote:
[...]
> So, here are some questions to answer:
> 
> (1) Would the sales volumes of this product be enough to make it  
> worth producing (ie. profitable)?
No idea about this.

> (2) How much would you be willing to pay for it?

About the same as for other video cards.  As a buyer, I look for what
different cards do and what I want.  Note that many otherwise great
cards loose because fantastic 3D is lost when there is no linux driver.
Or when the linux driver don't get that fantastic performance.  Or when
it is x86-binary only - someday I'll run a 64-bit kernel on my opteron,  
and loose some x86-binary stuff.  So I try not to have it in advance.

Drivers won't be a problem for your card, so it beats all those who  
have such problems.  And that might be most of them . . .

Openness _is_ a feature, so I'll pay more for that, but not lots more.

> (3) How do you feel about the choice of neglecting 3D performance as  
> a priority?  How important is 3D performance?  In what cases is it  
> not?

I want 3D - but I don't need high-end 3D.  My nice old G550 is fine
for playing tuxracer at 1280x1024.  Actually, 640x512 is okay for
gaming.

Now, I also want several cards in one machine, for a multiuser setup.
This is hard, because the newest cards doesn't like to be
secondary and old cards are not available in shops. (And buying used
usually mean you can't return it...)

> (4) How much extra would you be willing to pay for excellent 3D
> performance?

Not that much - you might want this to be an option, such as an
empty socket where the high-end people plug in a expensive high-end 3D  
add-on chip/card.

> (5) What's most important to you, performance, price, or stability?
>
Stability
price
performance

Of course performance can't be _too_ bad, but it _have_ to be stable.


> Feel free to insert your own questions and answers here.  Remember,
> I'm
> an engineer.  My understanding of business is dilettantish at best.
> 
> I haven't worked out a complete design spec for this product.  The
> reason is that what we think people want and what people REALLY want
> may
> not be congruent.  If you have a good idea for a piece of graphics
> hardware which you think would be beneficial to the free software
> community (and worth it for a company to produce), then Tech Source,
> as
> a graphics company, might be willing to sell it.
>


Video stuff I want:
===================

24-bit color
------------
Nice 2D performance & stability when using 24-bit color.  I do photo
editing, 16-bit color isn't really enough for this.  I have noticed  
some cards loose performance and stability when going 24-bit.  I can
understand the performance loss (more data) but not the instability.
Of course the complete docs will help with any stability issues.

Some 3D
-------
Enough 3D to play open-source games like tuxracer.  Hopefully the more
demanding games will work by lowering detail or configuring them
to not try to use advanced graphics operations the "simple" card
doesn't support.

Multiuser capabilities
----------------------
Ability to have several users use independend displays.  I.e.
the displays are controlled by different xserver processes,
_not_ one xserver running them all.  This is necessary for
multiuser setups.

The point here is that I don't want to maintain two PCs when
one pc with two sets of screen+kbd+mouse will do.  Ideally,
the two fully independent graphichs engines should go on one
card.  Not to get it cheaper, I'll happily pay the price of
two cards for this, but to get the higher bandwith of the AGP bus for  
both users.  Sure - they'll have to share it - I guess sharing the
AGP bandwith still beats having one user using AGP and the other
using PCI.  At least for the user with the pci card . . .

I'll settle for the two-card solution though - with this being
a niche product already you probably don't want a niche
product within the niche. :-/

I have problems implementing this sort of thing with other cards.
The pc bios only initialize the bios on the "primary" card, probably
because VGA devices clash with each other.  Now this is an
argument for _not_ supporting VGA.  This cause trouble for all
cards that needs proper bios initialization to work with linux.
Of course your card won't really need such initialization, being
fully documented means that the linux kernel framebuffer driver
and/or the xfree driver can initialize it itself!
Still, it is sometimes nice being able to have the initial console
on a secondary card, so finding some way to have all the cards
in the machine set up early is nice.  (Including the case where
your card is secondary and the primary is someone else's card,
so we can't rely on the primary card bios initializing other
cards too.  Perhaps a dip switch on the card that makes it
announce itself as a "mass storage device" instead - the pc
bios call the initialization function on all of those. :-)

Other problems I see with dual xservers is that screen blanking,
resolution switching or the xserver restarting on one card occationally  
cause trouble on the other.  That is probably a
xserver problem - make sure the xserver for your card have no such  
issues. Selling extra cards to people who want such setups might
become a nice fraction of your market.  After all, an extra card,  
keyboard, screen and mouse is a lot cheaper than an entire extra pc.
It saves space and power too, and the user don't have to install
software twice, upgrade twice and so on.  It is a fantastic
solution for budget-constrained home users.

Video frequency programming
---------------------------
Ability to have the exact same frequencies in X and on the
framebuffer console - and switching between X and
consoles without upsetting the sync signals. Upsetting the
video signals a little is ok, I don't mind flickering
but I hate to wait for the dead slow resynchronization
on my flat panels.

I also like the ability to switch seamlessly between different  
resolutions that happens to be equivalent seen from the
monitor side.  Such as between 1280x1024 and a 640x512 doublescan mode.
The doublescan mode simply turns one pixel into four - the frequencies
remain the same as it really is 1280x1024 based on less data.  Other  
cards can do this, but they manage to
loose sync with the monitor half of the time anyway, perhaps they
try to make the switch and start a new frame in the middle of
a scanline or some such.


What I see no need for - stuff to drop to get it cheaper:
=========================================================
* Less than 24-bit color modes - if dropping those simplifies anything.
  Fully documented graphichs acceleration ought to get decent
  performance from this thing anyway.

* VGA compatibility.  It is such a non-issue.
  Totally unnecesary when you provide a bios that
  lets the thing boot anyway, and full documentation for the
  framebuffer and xserver people. I don't know if this actually saves
  much - don't include VGA if it might increase price by 10%. Also,
  legacy VGA is only trouble for those who want two or more
  cards in the same machine.


Other ideas
===========
* Windows driver.  Nice for those that still run windows occationally
  on the same machine.  Perhaps some non-gaming windows users will
  consider the card too, if it is cheap or use a lot less power than
  others.  Windows is still big, so you won't need a big percentage
  of this market before it is a nice amount of extra sales.
  Businesses might actually like the inability to run the latest
  3D-heavy games - it prevents users from wasting time at work.

* Consider a version to include on motherboards.  Low-end 3D shouldn't
  be a problem there, because those who really care about 3D always
  buys the latest 3D board anyway and never use the onboard thing.
  Not even if it is good 3D, because the very best is always newer.
  Make sure it works both as primary and secondary device in this case
  too.  It'll be nice for server boards - those rarely need  high-
  end 3D.  Those concerned about security might like the fact that
  hw bugs may be fixed by reprogramming the FPGA. It may also be an
  option for makers of cheap boards - they might want to boast about
  having on-board graphichs for a all-in-one motherboard, but they
  might not want to include a expensive high-end chip.
  Also, a deal with some board manufacturer might get you some volume
  for the chips.  The windows driver will probably be necessary for
  this.

* Consider using ordinary DIMM slots for the memory.  Selling a memory-
  less version of the card lets users put in whatever amount they
  think they need - today and next year.  And tinkerers can reuse
  memory from old machines.

Helge Hafting

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Giuseppe Bilotta]

Helge Hafting wrote:
> * Consider a version to include on motherboards.  Low-end 3D shouldn't
>   be a problem there, because those who really care about 3D always
>   buys the latest 3D board anyway and never use the onboard thing.
>   Not even if it is good 3D, because the very best is always newer.
>   Make sure it works both as primary and secondary device in this case
>   too.  It'll be nice for server boards - those rarely need  high-
>   end 3D.  Those concerned about security might like the fact that
>   hw bugs may be fixed by reprogramming the FPGA. It may also be an
>   option for makers of cheap boards - they might want to boast about
>   having on-board graphichs for a all-in-one motherboard, but they
>   might not want to include a expensive high-end chip.
>   Also, a deal with some board manufacturer might get you some volume
>   for the chips.  The windows driver will probably be necessary for
>   this.

Very good post, Helge. Excellent, if I might say.

Another important market to look into is laptops, IMO. 
Especially when memory consumption comes in, if the card can do 
"enough" 3D you could probably beat ATI and nVidia on the 
market.

(Of course, the definition of "enough" is quite subjective ... 
my 3D game is BZFlag, and for very complex maps at the max 
quality settings even my nVidia GeForce2 Go has its problems at 
1600x1200x32 ...)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Giuseppe Bilotta]

Giuseppe Bilotta wrote:
> Another important market to look into is laptops, IMO. 
> Especially when memory consumption comes in, if the card can do 
                  ^^^^^^
Ahem. Of course this should read "power"

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

Salut,

On Fri, Oct 22, 2004 at 10:57:16AM +0000, Helge Hafting wrote:
> 24-bit color
> ------------

Why don't you use 32-bit colors?  24-bit packed pixels are a pita, and
a lot of OpenGL hardware doesn't support 24bpp. You might atcually get
better graphics/performance/etc. if you  stick to 32bpp. Only that the
framebuffer size increases by 1/3rd.

			    Tonnerre

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Tonnerre wrote:
> Salut,
> 
> On Fri, Oct 22, 2004 at 10:57:16AM +0000, Helge Hafting wrote:
> 
>>24-bit color
>>------------
> 
> 
> Why don't you use 32-bit colors?  24-bit packed pixels are a pita, and
> a lot of OpenGL hardware doesn't support 24bpp. You might atcually get
> better graphics/performance/etc. if you  stick to 32bpp. Only that the
> framebuffer size increases by 1/3rd.

It's been ages since I've encountered a GPU which could do packed 24.  I 
think when people talk about "24 bit color", they're also thinking "32 
bits per pixel".  Besides, there's the alpha channel.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Giuliano Pochini]

On Mon, 25 Oct 2004, Timothy Miller wrote:

>
>
> Tonnerre wrote:
> > Salut,
> >
> > On Fri, Oct 22, 2004 at 10:57:16AM +0000, Helge Hafting wrote:
> >
> >>24-bit color
> >>------------
> >
> >
> > Why don't you use 32-bit colors?  24-bit packed pixels are a pita, and
> > a lot of OpenGL hardware doesn't support 24bpp. You might atcually get
> > better graphics/performance/etc. if you  stick to 32bpp. Only that the
> > framebuffer size increases by 1/3rd.
>
> It's been ages since I've encountered a GPU which could do packed 24.  I
> think when people talk about "24 bit color", they're also thinking "32
> bits per pixel".  Besides, there's the alpha channel.

Well, in order to save memory and bandwidth, the data can be 24bpp, but
the software sees it 32bpp.

I didn't follow the whole thread, but IMHO the most important thing is 2D.
If you like gaming, a slow 3D card is useless. I would prefer a card with
excellent 2D features instead.


--
Giuliano.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Helge Hafting]

On Mon, Oct 25, 2004 at 06:32:27PM +0200, Giuliano Pochini wrote:
> 
> 
> On Mon, 25 Oct 2004, Timothy Miller wrote:
> 
> >
> >
> > Tonnerre wrote:
> > > Salut,
> > >
> > > On Fri, Oct 22, 2004 at 10:57:16AM +0000, Helge Hafting wrote:
> > >
> > >>24-bit color
> > >>------------
> > >
> > >
> > > Why don't you use 32-bit colors?  24-bit packed pixels are a pita, and
> > > a lot of OpenGL hardware doesn't support 24bpp. You might atcually get
> > > better graphics/performance/etc. if you  stick to 32bpp. Only that the
> > > framebuffer size increases by 1/3rd.
> >
> > It's been ages since I've encountered a GPU which could do packed 24.  I
> > think when people talk about "24 bit color", they're also thinking "32
> > bits per pixel".  Besides, there's the alpha channel.
> 
Nothing wrong with 32-bit color.  What I meant, was to
prioritize 24-bit _or better_ - don't waste space on
16-bit or even less stuff. 

> Well, in order to save memory and bandwidth, the data can be 24bpp, but
> the software sees it 32bpp.
> 
Or one could go the other way - if we use 32 bits, then
consider 10 bits per color.  I've always wondered about the purpose
of a 8-bit alpha channel.  what exactly is supposed to show
in "transparent" places?  Transparency makes sense when talking about 
windows - you see the underlying window through a transparent spot.
But this is the frame buffer we're talking about - what is
supposed to be behind that?  Another frame buffer?

> I didn't follow the whole thread, but IMHO the most important thing is 2D.
> If you like gaming, a slow 3D card is useless. I would prefer a card with
> excellent 2D features instead.

No, a slow 3D card is very useful.  Remember the original doom?  It
ran fine on a 486 with no graphichs accelerator other than the cpu
itself.  Then came games that used 3D acceleration - the early 3D
accelerators were simple stuff comparted with this year's cards.

If he can make an open card that runs most 3-year old 3D-stuff, then
great!  There is _lots_ of such programs around.  They doesn't cease
to exist, they doesn't stop getting used just because they're old.

There is a handful of opensource 3D games that works fine with
old 3D cards. There will likely be more with time too.

Games is much more than the "latest and greatest".  Don't fall
into the trap thinking that this month's top seller game is
all that counts.  People still fire up their old C64's from
time to time . . .

Also, there is the fact that the closed nature of many new 3D
cards means their potential isn't realized under linux, where
I play _all_ my games anyway.  Competing with someone who
have no driver is easy, and someone with a severely lacking driver
isn't so hard to beat either.

Helge Hafting


 

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Geert Uytterhoeven]

On Thu, 28 Oct 2004, Helge Hafting wrote:
> Or one could go the other way - if we use 32 bits, then
> consider 10 bits per color.  I've always wondered about the purpose
> of a 8-bit alpha channel.  what exactly is supposed to show
> in "transparent" places?  Transparency makes sense when talking about 
> windows - you see the underlying window through a transparent spot.
> But this is the frame buffer we're talking about - what is
> supposed to be behind that?  Another frame buffer?

Possibly. Or a life video plane.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[David Greaves]

Helge Hafting wrote:

>Or one could go the other way - if we use 32 bits, then
>consider 10 bits per color.  I've always wondered about the purpose
>of a 8-bit alpha channel.  what exactly is supposed to show
>in "transparent" places?  Transparency makes sense when talking about 
>windows - you see the underlying window through a transparent spot.
>But this is the frame buffer we're talking about - what is
>supposed to be behind that?  Another frame buffer?
>  
>
Well, The Hauppage 350 via the ivtv driver provides a framebuffer 'OSD' 
(On Screen Display) that overlays the hardware video (as in TV) layer.
Transparency determines how much of the video shows through.

It's good having a framebuffer that can run X (or whatever) overlayed 
onto the video stream.

David

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Helge Hafting wrote:

>>>It's been ages since I've encountered a GPU which could do packed 24.  I
>>>think when people talk about "24 bit color", they're also thinking "32
>>>bits per pixel".  Besides, there's the alpha channel.
>>
> Nothing wrong with 32-bit color.  What I meant, was to
> prioritize 24-bit _or better_ - don't waste space on
> 16-bit or even less stuff. 

Yeah.  There may be some demand for 8-bit pseudocolor, but 16-bit 
truecolor seems a bit pointless.

However, if the host interface has some intelligence in it, then we 
could have pixels in the framebuffer ALWAYS 32 bits, but we can make 
them LOOK like 8 or 16 bit pixels to the host.

> 
>>Well, in order to save memory and bandwidth, the data can be 24bpp, but
>>the software sees it 32bpp.
>>
> 
> Or one could go the other way - if we use 32 bits, then
> consider 10 bits per color.  I've always wondered about the purpose
> of a 8-bit alpha channel.  what exactly is supposed to show
> in "transparent" places?  Transparency makes sense when talking about 
> windows - you see the underlying window through a transparent spot.
> But this is the frame buffer we're talking about - what is
> supposed to be behind that?  Another frame buffer?

When compositing images, it's important to know "how much pixel" has 
been painted already.  If the screen's blank and all pixels therefore 
are completely transparent, and you draw something with antialised 
edges, you want to keep track of the fact that the edges are "not all 
there" so that if another triangle gets drawn that abuts the first one, 
they merge together perfectly.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Clemens Schwaighofer]

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

On 10/21/2004 07:02 AM, Timothy Miller wrote:

Most important feature for me: Dual Head with speed & fastness on both
heads. Independent resolutions on each head, without loosing speed.

lg, clemens
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBeYlqjBz/yQjBxz8RArYJAKDN7JWwaVTkgnv0UeDw77ai3QZ2DwCg3hae
daWt43Qu4WA+jKAmfjsOY1g=
=Yosg
-----END PGP SIGNATURE-----

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Markus Törnqvist]

I have been thinking about this aloud on IRC for quite a while, just wishing
someone with the resources would get into the same idea, and now it finally
happened :) Hooray! :)

Timothy Miller Wrote:

>(1) Would the sales volumes of this product be enough to make it worth 
>producing (ie. profitable)?

This seems the biggest concern, but I'd say yes. Of course, promotion
besides Word of Mouth would be needed, I guess.

I see it as an issue that you should get them cheap, say almost non-profit,
to companies who sell pre-installed Linux boxes, just to get volume, fame
and name.

>(2) How much would you be willing to pay for it?

Unsure, but looking at the kerneltrap page, it doesn't seem likely it'd
be too expensive. I'd shell out the extra bucks for the cause, and hope
other people would as well.

>(3) How do you feel about the choice of neglecting 3D performance as a 
>priority?  How important is 3D performance?  In what cases is it not?

I do like my 3D. Well, I get by with my current Radeon 9000; it's fast
enough without having to resort to the binary drivers. This is what I
bought it for. If it has any chance of being on-par or a little
better, I'm there to buy it. Even if it wasn't a real upgrade but
a vote of the wallet.

>(4) How much extra would you be willing to pay for excellent 3D performance?

Impossible to say, time would tell, but I would be willing

>(5) What's most important to you, performance, price, or stability?

Freedom ;)
I wouldn't buy a card that wouldn't have the three aforementioned features.
But performance isn't all that critical, I prefer a sharper picture over
a blurry fast one.

Anyway, this also has the chance of catching the eye of an
open-source-friendly angel, which always something to hope for.

What about distribution of this card? "Order from the factory" or
"buy at the store nearest you"?

Well, my two cents.. Best of luck, and I hope this goes through.
It may not beat the shit out of nvidia and ati in the beginning, but
every effort starts small.

-- 
mjt

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]

Salut,

My CHF 0.05 (we don't have smaller pieces):

Open hardware is just as necessary in this world as open software. The
Freedom CPU people know that, and they're a bunch of people developing
open hardware, having  no money for the step  of actually producing. I
agree that their  design is debatable. But the idea  is clear: we need
open hardware to write truly open software on.

I know several companies who would like to produce open hardware, too,
but have  the same fears that  your company has. Someone  will have to
step  up   and  produce  open   hardware,  and  if  someone   does  it
successfully, I guess a whole  aeroplane of companies is going to take
off producing open hardware as well.

The  thing companies  tend  to  disregard is  the  fact that  whenever
something is open, there will be people developing on it in their free
time. It's  that with Open Source  software, and it  will certainly be
the same with open hardware.

For a graphics  card, OpenGL support is almost  vital. This means that
you'll have to implement it in  order to be successful. Because 90% of
the  people out  there, if  not more,  are using  their  computers for
playing games.

That said, I  think there are lots of people  willing to contribute to
your hardware  design. I'll be  glad to do  that, once I got  the time
to. The Freedom CPU people might  as well. I guess that people will do
a lot more than just the firmware for you. I mean, AMD developed their
Opteron based on suggestions from (open source) developers, people who
need  to  handle  that  hardware,   and  it  turned  out  to  be  damn
good. People  should just  listen to those  who got probably  the best
idea of what hardware should be like: those who code on it.

If you  can show  good 3D performance,  you might  as well get  a good
chance to get lots of Windows  Quake players to use your hardware. And
if you were to support  OpenGL 2.0, people will suddenly start kissing
your feet.

Maybe we  can start off an  open hardware development  group with your
company selling the end products...

On Wed, Oct 20, 2004 at 06:02:51PM -0400, Timothy Miller wrote:
> - x86 BIOS/OpenBoot/OpenFirmware code under BSD and GPL license

BSD without advertisement clause should be enough, I guess?

> (1) Would  the sales volumes  of this product  be enough to  make it
> worth producing (ie. profitable)?

This depends on how public the  product gets. Lots of people here will
be able to help you a lot  with that step. If IBM and/or Intel were to
say,  "$COMPANY supports  Open Hardware  because it's  good",  I guess
people will actually start buying open hardware.

> (2) How much would you be willing to pay for it?

People already pay several hundreds of CHF for a graphics card.

> (3) How do you feel about the choice of neglecting 3D performance as
> a priority?  How  important is 3D performance?  In  what cases is it
> not?

Since 3D  and software suspend are  about the only problem  we have, I
guess the card wouldn't have a  chance if it wasn't to have remarkable
3D performance.

> (5) What's most important to you, performance, price, or stability?

To  us  it's  stability,  however,  to  the rest  of  the  world  it's
performance. I'm not sure whether geeks are a big enough market.

			    Tonnerre

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Stuart Longland]

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

Timothy Miller wrote:
[ ... snip ... ]

> In short, what I have been proposing to my superiors is the development
> of a graphics card specifically for open source systems.  This means
> full disclosure on all register interfaces so that no one has to deal
> with anything closed source (BIOS included).  The goal here is to
> produce a graphics card which is a Free Software geek's dream in terms
> of openness.

This would be my dreams come true.  At the moment I'm running a Radeon
9200SE in my box -- which really under-performs under Linux using the
opensource driver.  Unfortunately, ATI's crappy binary (yick! I hate
binary drivers in general) messed up my X server settings, needless to
say it was gone in 5 minutes flat.

An alternate video card manufacturer who is open to everyone would make
a nice change.

Perhaps you could test the water with other devices?  Some people
mentioned sound cards, but also why not ethernet, wireless network
cards, etc?

> I can produce more detail later, but first, some characteristics and
> advantages of what I'm proposing:
>
[ ... snip ... ]
> - The card "just works" with Linux because, maybe, the drivers would go
> into main-line

This would be a *big* bonus.  One of the things that drove me away fron
nVidia and the later ATI cards is having to recompile their crappy
driver each time I update the kernel.

Not to mention the pain when to compilling programs, only to discover
that they've fiddled with the openGL libraries.

> (1) Would the sales volumes of this product be enough to make it worth
> producing (ie. profitable)?

Difficult to say.  Provided it wasn't too expensive, I'd consider it
worth while.  This is why I suggest testing the water with something
else for starters... that would get you income you can pour into
researching and developing a video card chipset.

> (2) How much would you be willing to pay for it?

Bear in mind that I'm a poor uni student :-)
I spose AU $80 would be as much as I'd pay for a purely 2D graphic card.

> (3) How do you feel about the choice of neglecting 3D performance as a
> priority?  How important is 3D performance?  In what cases is it not?

This is fair enough... suppose you went with the fully programmable
firmware idea -- upgrading the card would largely be a case of replacing
the firmware.  In that case, this would seem reasonable to me.

> (4) How much extra would you be willing to pay for excellent 3D
> performance?

Quadruple the above price maybe?  That would be absolute TOPS for me.

One question that needs to be asked -- how would one obtain one of these
cards?  Would I have to somehow order it online or would there be a
distributor somewhere in Australia where I could obtain one?

> (5) What's most important to you, performance, price, or stability?

1. Stability
2. Price
3. Performance

> I haven't worked out a complete design spec for this product.  The
> reason is that what we think people want and what people REALLY want may
> not be congruent.  If you have a good idea for a piece of graphics
> hardware which you think would be beneficial to the free software
> community (and worth it for a company to produce), then Tech Source, as
> a graphics company, might be willing to sell it.

I think the idea of implementing OpenGL fully in hardware has some nice
benefits.  A bit point is that there's less in the driver to go wrong,
less code to debug.  The other point is that it makes cross-platform
drivers more trivial.

> Oh, and before you flame me, YES, I AM doing market research for Tech
> Source here, but NO, I am not doing it at THEIR request.

Hey... I'm glad you had the courage to come here and ask :-) I get to
have my say that way. :-D

Probably my main comment, if anything would be to initially start small.
 Okay, the 2D market is more or less sorted -- one can pick up a decent
Matrox or S3 video card to perform that task for under AU$20, so unless
you we're really able to cut the costs down, this would not be so
profitable (except for the embedded market of course).

Is it worth perhaps looking at implementing a card with crude OpenGL
(i.e. ATI Mach64/NVidia Riva grade) and working up from there?

Again, I'll make the point that it may be worth producing some other
hardware (e.g. network cards, sound cards, etc) to test the water.  That
way, you get an idea of what the market is for opensource hardware in
general.  This will also give you an income that can help fund the
development of a GPU for use on your final holy grail.

I'd be interested to see how it goes... Good luck with this venture.
Hope it goes well.
- --
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project     -oOo-    http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBfOlvuarJ1mMmSrkRApNiAJ0TVNnlANztd3KTfCyvYQem3nLPVQCeMCxG
4WbFlfSAw5k+xfvFmuR42Fs=
=JkPG
-----END PGP SIGNATURE-----

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Lars Roland]

Hi, great idea

> (1) Would the sales volumes of this product be enough to make it worth
> producing (ie. profitable)?

I think, at my work we spend a great deal of money on Linux/OS
compatible products and I know many others that do so, also if you can
get the chip working in a low power environment, people like me doing
embedded devices will be really interested.

> (2) How much would you be willing to pay for it?
This depends on many things. I just paid 120$ for a Matrox g550, just
for the sole fact that it had open source drivers, it has dual dvi and
it has enough 3D power to use the latest spiffy stuff in xorg 6.8.0 -
for gaming I just use a secondary graphic card or my ps2.

> (3) How do you feel about the choice of neglecting 3D performance as a
> priority?  How important is 3D performance?  
As I said, it should have enough 3D features to be used together with
xorg both now and in the future - so you should look hard at what
Longhorn /Mac OS X have done and decide what features to implement. I
do not care if it can run doom3 or not, I have yet to come across a
graphic card that can run the latest games and have decent Linux
support (this is especially true when you are running dual head).

> (4) How much extra would you be willing to pay for excellent 3D performance?
200-300$ but then it should also run Doom3/Halflife2 at a playable speed. 

> (5) What's most important to you, performance, price, or stability?
Dual head, there is just no good option here any more, the old Matrox
cards (G400, G450 and G550) are just not that good anymore (if you run
dual dvi, the maximum res is 1024*1280, that is not good enough on a
19 LCD screen). I know a lot of computer professionals, that would
love to get there hands on a graphic card with dual/quad output, that
have great Linux support and can run at high resolutions.

For my own part I can tell you, that a dual head dvi card is high on
my wish list (if it can run 1200*1600 on each head), if you can make
one with Linux support, then I would be happy to pay 200-300$ for it,
even if it did not have the best 3D support (just enough power for
future xorg/enlightenment effect and I am happy).

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Lars Roland wrote:

> 
> For my own part I can tell you, that a dual head dvi card is high on
> my wish list (if it can run 1200*1600 on each head), if you can make
> one with Linux support, then I would be happy to pay 200-300$ for it,
> even if it did not have the best 3D support (just enough power for
> future xorg/enlightenment effect and I am happy).
> 
> 

I expect that we will offer a multi-head model.

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Helge Hafting]

On Mon, Oct 25, 2004 at 01:08:00PM -0400, Timothy Miller wrote:
> 
> 
> Lars Roland wrote:
> 
> >
> >For my own part I can tell you, that a dual head dvi card is high on
> >my wish list (if it can run 1200*1600 on each head), if you can make
> >one with Linux support, then I would be happy to pay 200-300$ for it,
> >even if it did not have the best 3D support (just enough power for
> >future xorg/enlightenment effect and I am happy).
> >
> >
> 
> I expect that we will offer a multi-head model.

Great!

Will this be a card with two pci id's, and two
fully independent graphichs accelerators?

That is necessary for two-user setups.  A single-user
setup with xinerama use a single xserver process that
can deal with hardware dependencies.  A two-user
setup use two xserver processes that doesn��'t cooperate
at all.  One basically doesn�'t know that the other exists,
so it cannot know what register the other process messes
with and so on.  A dual processor machine might even
mean that both servers runs simultaneosuly - so
there cannot be dependencies.  Also, an xserver likes
to reserve a pci ID for itself, so life gets much
easier if the card has two pci ids - i.e. two
graphichs cards on a single circuit board.

Of course I am willing to pay twice the single-card
price for such a card that has two of every chip
(except for the shared bus interface circuits).

I hope such a design won't be too much extra work,
basically you design the single-card accelerator FPGA
and other supporting chips
and stuff two of everything on the same PCB.

Note that this  "double" card improves performance for
the more common case of one user with two screens too. :-)

Helge Hafting

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Timothy Miller]

Helge Hafting wrote:
> On Mon, Oct 25, 2004 at 01:08:00PM -0400, Timothy Miller wrote:
> 
>>
>>Lars Roland wrote:
>>
>>
>>>For my own part I can tell you, that a dual head dvi card is high on
>>>my wish list (if it can run 1200*1600 on each head), if you can make
>>>one with Linux support, then I would be happy to pay 200-300$ for it,
>>>even if it did not have the best 3D support (just enough power for
>>>future xorg/enlightenment effect and I am happy).
>>>
>>>
>>
>>I expect that we will offer a multi-head model.
> 
> 
> Great!
> 
> Will this be a card with two pci id's, and two
> fully independent graphichs accelerators?

Maybe.  Or maybe two independent graphics contexts in the same chip, or 
any number of other solutions.

This isn't a serious technical hurdle.  If nothing else, we can stick a 
bridge between two chips and the bus.

> 
> That is necessary for two-user setups.  A single-user
> setup with xinerama use a single xserver process that
> can deal with hardware dependencies.  A two-user
> setup use two xserver processes that doesn��'t cooperate
> at all.  One basically doesn�'t know that the other exists,
> so it cannot know what register the other process messes
> with and so on.  A dual processor machine might even
> mean that both servers runs simultaneosuly - so
> there cannot be dependencies.  Also, an xserver likes
> to reserve a pci ID for itself, so life gets much
> easier if the card has two pci ids - i.e. two
> graphichs cards on a single circuit board.
> 
> Of course I am willing to pay twice the single-card
> price for such a card that has two of every chip
> (except for the shared bus interface circuits).

The economics are much more complex than that, although I don't really 
understand them well.  What you're asking for is a niche product and is 
subject to niche pricing.  It will sell for what the market will bear.

Products like this may have to have a higher profit margin, in order to 
make up for slimmer margins on more commodity products.  But don't quote 
me because I'm officially clueless on this topic.  :)

> I hope such a design won't be too much extra work,
> basically you design the single-card accelerator FPGA
> and other supporting chips
> and stuff two of everything on the same PCB.
> 
> Note that this  "double" card improves performance for
> the more common case of one user with two screens too. :-)

Quite true.  :)

Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Salut,

On Mon, Oct 25, 2004 at 06:38:48PM +0200, Lars Roland wrote:
> As I said, it should have enough 3D features to be used together with
> xorg both now and in the future - so you should look hard at what
> Longhorn /Mac OS X have done and decide what features to implement. I
> do not care if it can run doom3 or not, I have yet to come across a
> graphic card that can run the latest games and have decent Linux
> support (this is especially true when you are running dual head).

You don't want  good Longhorn support, as currently  at least Longhorn
still uses  the proprietary GDI 2D drawing  algorithms, and DirectDraw
in rare cases.  MacOS/X does  the drawing and effects in OpenGL, which
is what  you want.  As  will X.Org.  So  you want OpenGL  support, and
you'll be done. (Once framebuffers  are being drawn in OpenGL as well,
which isn't impossible to happen.)

Maybe we'll need a graphics card that does OpenGL *only*...

			    Tonnerre

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]