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.
On Wed, 20 Oct 2004 18:02:51 -0400, Timothy Miller
<[email protected]> 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
I'm posting from home, so this won't look right. Sorry.
Anyhow, Andre Eisenbach said this:
>>>
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 have tried using cards with VESA drivers before, and I found it to be
very painful. Certainly, you can turn off certain features and get a
reasonably useful UI experience, but dragging windows around with "show
window contents while moving" enabled is painfully slow, even with AGP
4x. Just imagine doing it over PCI.
When it comes to desktop applications, the FIRST thing you need is good
2D acceleration. In fact, that's really the ONLY thing. OpenOffice
does not need to use OpenGL. GNOME doesn't need to use OpenGL. In
fact, for the most part, they don't bother. There are some instances
where they use OpenGL, but most of what a workstation user does fits
squarely within all the functionality supplied by Xlib, which is
entirely 2D.
Ok, so with limited 3D support, it's almost not worth trying to play
Doom II (let alone III), but that's never affected me. On Linux, I use
nedit, Mozilla, GNOME, KDE... ALL 2D apps. I use Linux as a
development platform for chip logic, X server modules, and web sites.
I also do a fair amount of tinkering with CPU-intensive things like
genetic algorithms. In fact, the ONLY time I have EVER played with 3D
on Linux was when I fiddled with some of the screensavers.
Ok, so I'm really limited in my use. But what about what a secretary
would use? GNOME, OpenOffice, Evolution, Mozilla. All 100% 2D apps.
How about a sysadmin? Well, he wants something simple in his server
that lets him run his Red Hat configuration tools. What's a system
integrator want? Something that won't result in any tech-support
calls.
Nevertheless, I do think 3D is very important. MacOS has moved to pure
3D, and Longhorn's Aero Glass thingy is all 3D too. Plus there's that
Sun thing. With Linux, we're kinda constrained by the fact that core
X11 protocol is strictly 2D, but soon, GNOME and KDE will surely find a
way around that too. I know we could not sell a graphics device which
did not have ANY 3D support. But keep in mind that the more
sophistocated the 3D support, the larger an FPGA you'll need. The
prices of FPGA's go up exponentially with die area.
I've been given a very limited budget here for development. (Well, I
haven't been given a budget yet--I've just been told that we're not
going to spend $100K to do an ASIC for something this speculative.)
I'm further constrained by the impact of FPGA chip cost on the end
product.
Here's an off-the-cuff guess as to the parts cost for one board (I'm
sure I have most of the prices wrong):
- FPGA $30
- PCB $5
- DAC $10
- DVI transmitter $10
- RAM $20
- Assembly $??
- Development cost $??
- Profit $??
The parts alone are $75, and I've left plenty out. If the board is
profitable at $100... who will buy it?
I'll do whatever anyone wants, as long as it fits into these
constraints!!
One idea I have is to merge the 2D and 3D pipelines into one. This
way, we can get better 3D functionality, and 2D comes in for free. The
problem is that 2D performance would be a LOT slower in this case. But
forget I said that, because it's absolutely pointless to talk
implementation details at this point.
The whole issue comes down to this: This is technically feasible.
Should we do it?
The open source community often complains about hardware vendors being
too tight-lipped with their IP. Here, we have a golden opportunity to
get what we want, both in terms of features and disclosure. How do we
figure out how to not miss that opportunity?
In case you're wondering why I'm writing so much about this... it's
because I REALLY REALLY REALLY want to do this. As a geek who enjoys
designing stuff, this is an exciting idea to me. I'm also a free
software zealot, but I often feel like a leech because I haven't given
anything back (well, there's GTerm, but who cares.). I just don't know
how to justify the cost of this project to my employer.
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
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
On 2004.10.21, Timothy Miller wrote:
...
>
> When it comes to desktop applications, the FIRST thing you need is good
> 2D acceleration. In fact, that's really the ONLY thing. OpenOffice
> does not need to use OpenGL. GNOME doesn't need to use OpenGL. In
> fact, for the most part, they don't bother. There are some instances
> where they use OpenGL, but most of what a workstation user does fits
> squarely within all the functionality supplied by Xlib, which is
> entirely 2D.
>
Have you looked at xorg-x11 recently ? IE, the Composite, Damage and
Render extensions ?
OSX uses OpenGL because it is the API they have to access things like
alpha blending, image scaling, and so on, so they can do those nice
effects of transparencies, shadows, genie's and so on. At least until
Panther. For me, it looks like the new Tiger implementation (CoreImage) is
their own implementation of the OpenGL pixel pipeline, talking directly
to drivers instead of using OpenGL as intermediary.
Probably desktop systems would not need the T&L part of 3D, but be sure
they will need at least managing windows at different depths, blending them,
anti-aliasing them an so on.
So, as I see it, for an appealing 2D card, you need to program a 2 1/2
graphics engine, with really _fast_ alpha blending and antialiasing.
You can only kill the matrix part. I do not know if you will be able to
get rid completely of floating point, for those alpha mixes and assorted
candy...
--
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
--- "J.A. Magallon" <[email protected]> wrote:
>
> On 2004.10.21, Timothy Miller wrote:
> ...
> >
> > When it comes to desktop applications, the FIRST thing you need is
> good
> > 2D acceleration. In fact, that's really the ONLY thing.
> OpenOffice
> > does not need to use OpenGL. GNOME doesn't need to use OpenGL. In
> > fact, for the most part, they don't bother. There are some
> instances
> > where they use OpenGL, but most of what a workstation user does
> fits
> > squarely within all the functionality supplied by Xlib, which is
> > entirely 2D.
> >
>
> Have you looked at xorg-x11 recently ? IE, the Composite, Damage and
> Render extensions ?
>
> OSX uses OpenGL because it is the API they have to access things like
> alpha blending, image scaling, and so on, so they can do those nice
> effects of transparencies, shadows, genie's and so on. At least until
> Panther. For me, it looks like the new Tiger implementation
> (CoreImage) is
> their own implementation of the OpenGL pixel pipeline, talking
> directly
> to drivers instead of using OpenGL as intermediary.
>
> Probably desktop systems would not need the T&L part of 3D, but be
> sure
> they will need at least managing windows at different depths,
> blending them,
> anti-aliasing them an so on.
>
> So, as I see it, for an appealing 2D card, you need to program a 2
> 1/2
> graphics engine, with really _fast_ alpha blending and antialiasing.
> You can only kill the matrix part. I do not know if you will be able
> to
> get rid completely of floating point, for those alpha mixes and
> assorted
> candy...
Alright. Excellent points. If I don't have to do any scaling or
rotation, alpha-blending won't be that big of a deal. I already would
have to read the destination of applying a raster-op or a planemask, so
alpha-blend would become just another part of the merge at the end of
the pipeline.
Of course, with only 8 significant bits, you could get noticable
cumulative round-off error.
As you start to add 3D features to the 2D pipeline, the point in
keeping them separate diminishes.
Oh, and there's antialiasing... now, sometimes, it just LOOKS like
antialiasing, like with the font server used by X11. When it renders
characters, it produces an 8-bit grayscale bitmap which is
pre-antialiased, which you then have to color while rendering. If you
want to do other things, then you get back into scaling, which is just
a special case of texture-mapping.
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
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
[email protected]
Another thought, TV out is important in the embedded market. Think
about Tivo/MythTV/set top boxes.
--
Jon Smirl
[email protected]
On Wed, 2004-10-20 at 16:48 -0700, Timothy Miller wrote:
> I'm posting from home, so this won't look right. Sorry.
>
> Anyhow, Andre Eisenbach said this:
>
> >>>
> 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 have tried using cards with VESA drivers before, and I found it to be
> very painful. Certainly, you can turn off certain features and get a
> reasonably useful UI experience, but dragging windows around with "show
> window contents while moving" enabled is painfully slow, even with AGP
> 4x. Just imagine doing it over PCI.
>
> When it comes to desktop applications, the FIRST thing you need is good
> 2D acceleration. In fact, that's really the ONLY thing. OpenOffice
> does not need to use OpenGL. GNOME doesn't need to use OpenGL. In
> fact, for the most part, they don't bother. There are some instances
> where they use OpenGL, but most of what a workstation user does fits
> squarely within all the functionality supplied by Xlib, which is
> entirely 2D.
[snip]
My opinion, for what its worth:
Do 3D first and only. 2D is a subset of 3D. Implement as much of
OpenGL as you can in hardware and software can emulate any 2D interface
desired.
I agree that existing graphics cards do 2D just fine. I can get a ATI
card for $20 that does all the 2D I need. But 2D isn't enough for me.
I spend $400 on one Nvidia card. Maybe I'm not the average, common
user, but users like me have the highest profit margin. :-)
I'm a pragmatic user. I'd like full-featured Open Source drivers for my
Nvidia card but I use the binary because they work really well and for
me, (excellent_performance - closed_drivers) > (crappy_performance +
open_drivers).
If it can be done well enough to run Doom 3 in 640x480 at 20 fps for
less than $500, I'll buy one. That's the performance level where I'd
consider sacrificing 60 fps for the open drivers.
Of course, in 5 years I'll expect 120 fps so its definitely a moving
target.
--
Zan Lynx <[email protected]>
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
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
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
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
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
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Kasper Sandberg
Timothy Miller writes:
> (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?
Stability with a kernel of my choice on possibly
non-x86 hardware matters most. Digital DVI, fanless
operation, and DVD scaling are next. After that, 3D.
I'm not so sure you have to give up 3D. You can put
at least 4 AltiVec-capable "G4" CPUs on a PCI board
without having horrible power and temperature issues.
(Perhaps an AGP board can safely support even more.)
Each will do 4 32-bit floating-point fused-multiply-add
operations per cycle. That's got to be good for something.
I think the latest chips have built-in memory interfaces.
They have RapidIO interfaces. So you make your FPGA
speak RapidIO protocol (easy) and have each CPU render
every fourth frame.
One could even put the X server on the card.
Ultimately, this is a huge risk, with potentially
great reward. One must take some risks to succeed,
and this one is a whopper.
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
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
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. :)
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.
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> :)
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.
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.
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
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
[email protected]
>
> 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------
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.
> From: Timothy Miller [mailto:[email protected]]
> Sent: 21 October 2004 16:13
> To: Jon Smirl
> Cc: Linux Kernel Mailing List
> Subject: Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
>
> 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.
Actually what I'd love to see is an FPGA based graphics card which is
*extremely* minimal - essentially just a integer DSP. I'd issue coprocessor
commands to it like:
QueueSpanRender(long out_address, int pixels, Texture *source_tex, TexCoords
*coords);
And that would be about the most complicated thing it would do. All
geometry, clipping, texture coordinate calculation etc done on the CPU. Even
the coefficients for traversing the texture are done by the CPU. You then
only need to implement a very small number of primitives in FPGA. You could
probably "emulate" VGA and friends using a small microcontroller on the
board monitoring frame buffer and IO access, and a ton of waitstates :) But
hey, that's just to boot the machine.
In a purely software renderer, it's the pixel pushing which (last I checked)
takes an enormous chunk of CPU time. You latest GPUs are doing something
like 4-32 texture lookups and applications per cycle these days, which a
general purpose CPU really struggles to get anywhere near. It's something a
DSP/dedicated hardware can do far better than a general purpose CPU. It'd be
interesting to try, actually: run Doom 3 on linux under Mesa (if that's at
all possible :), turn off all pixel rendering in Mesa, and see how much
faster it runs.
This would probably also make a good trade-off on an embedded platform.
- John Ripley
Albert Cahalan wrote:
> Timothy Miller writes:
>
>
>>(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?
>
>
> Stability with a kernel of my choice on possibly
> non-x86 hardware matters most. Digital DVI, fanless
> operation, and DVD scaling are next. After that, 3D.
My aside from the DVD bit, my original 2D concept would make all of that
possible.
So, say you decide that you want to use this card for some obscure
variant of BSD or an Amiga or something, and you're having some trouble
with the porting of the available drivers, I'd be happy to assist in
that process.
>
> I'm not so sure you have to give up 3D. You can put
> at least 4 AltiVec-capable "G4" CPUs on a PCI board
> without having horrible power and temperature issues.
> (Perhaps an AGP board can safely support even more.)
> Each will do 4 32-bit floating-point fused-multiply-add
> operations per cycle. That's got to be good for something.
> I think the latest chips have built-in memory interfaces.
> They have RapidIO interfaces. So you make your FPGA
> speak RapidIO protocol (easy) and have each CPU render
> every fourth frame.
A CPU and a GPU don't do the same things. A GPU naturally parallelizes
things, both in time (pipelining of rendering functions) and space
(multiple pipelines). A CPU, even a superscalar one, does things in
essentially a sequential fashion. Thus, a 200Mhz GPU will absolutely
cream your 1Ghz G4 in graphics performance, even WITH clever AltiVec
hacks. Dedicated hardware is ALWAYS going to be faster than doing it in
software.
That being said, I'm not rejecting your G4 idea out-right. While you
can't expect stellar performance out of it, you CAN program it to do
absolutely every kind of 3D rendering you want.
I'm going to propose this as a possible solution to the problem.
> One could even put the X server on the card.
'Tis true.
>
> Ultimately, this is a huge risk, with potentially
> great reward. One must take some risks to succeed,
> and this one is a whopper.
>
>
>
>
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. :)
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
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.
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.
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 idea is a step in the right direction. To make the project
viable, you might be better off trying to court a slightly different
audience (instead of the cost-sensitive/3D-performant market). What if
instead, you were selling a highly parallel reprogrammable computing
core, which also happened to do graphics? I could see a potentially
much bigger and higher profit margin market for a standardized interface
from Linux to an FPGA. Image people buying them for headless servers as
crypto accellerators. Or as DSP/FFT accellerators (for speech
recognition , MPEG compression, or whatever). I'm sure you'd sell a few
to grad students writing theses on data flow machines, parallel
languages, prime factorization etc. Heck, I'd buy one just because it'd
be cool to try and write a 1000 element merge sort in hardware that
completed in one or two clock cycles. It's not hard to imaging people
using it to speed up emulators like QEMU. Maybe the distributed
computing folks (Folding@Home, SETI) would also be interested, since
their work is already highly parallelizable. You get the idea.
In my mind, this could be a much better "hook" than the promise of
openess alone.
Here's some people trying to do general purpose computing with current
graphics cards.
http://www.gpgpu.org/
http://graphics.stanford.edu/projects/brookgpu/
And be sure to look into existing open hardware projects to see if they
have anything to offer.
http://opencores.org/browse.cgi/by_category
Greg Buchholz
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
From: Simon Braunschmidt <[email protected]>
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
> From: Greg Buchholz [mailto:[email protected]]
> Sent: 21 October 2004 18:08
> To: [email protected]
> Subject: Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
>
> 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 idea is a step in the right direction. To make the project
> viable, you might be better off trying to court a slightly different
> audience (instead of the cost-sensitive/3D-performant
> market). What if
> instead, you were selling a highly parallel reprogrammable computing
> core, which also happened to do graphics? I could see a potentially
> much bigger and higher profit margin market for a
> standardized interface
> from Linux to an FPGA. Image people buying them for headless
> servers as
> crypto accellerators. Or as DSP/FFT accellerators (for speech
> recognition , MPEG compression, or whatever). I'm sure you'd
> sell a few
> to grad students writing theses on data flow machines, parallel
> languages, prime factorization etc. Heck, I'd buy one just
> because it'd
> be cool to try and write a 1000 element merge sort in hardware that
> completed in one or two clock cycles. It's not hard to imaging people
> using it to speed up emulators like QEMU. Maybe the distributed
> computing folks (Folding@Home, SETI) would also be interested, since
> their work is already highly parallelizable. You get the idea.
>
> In my mind, this could be a much better "hook" than the promise of
> openess alone.
It would also really reduce the cost and effort involved in producing the
card. It wouldn't take much (heh) to get it up and running as a simple frame
buffer + blitter, but it could be scaled to do fancy multi-texture ops over
time - all just by reprogramming the FPGA. All the manufacturer needs to
provide is a "getting started" FPGA file and output to a video DAC. The
community would do the rest over time.
I think "Open" hardware is one thing, but open *and* completely
reprogrammable is a far greater hook, at least for me. I'd be prepared to
shell out a few $100 for something as hackable as that. Hey, it's an FPGA on
a PCI Express card at the end of the day, what can't you do with it!
- John Ripley
Zan Lynx wrote:
> On Wed, 2004-10-20 at 16:48 -0700, Timothy Miller wrote:
>
>>I'm posting from home, so this won't look right. Sorry.
>>
>>Anyhow, Andre Eisenbach said this:
>>
>>
>>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 have tried using cards with VESA drivers before, and I found it to be
>>very painful. Certainly, you can turn off certain features and get a
>>reasonably useful UI experience, but dragging windows around with "show
>>window contents while moving" enabled is painfully slow, even with AGP
>>4x. Just imagine doing it over PCI.
>>
>>When it comes to desktop applications, the FIRST thing you need is good
>>2D acceleration. In fact, that's really the ONLY thing. OpenOffice
>>does not need to use OpenGL. GNOME doesn't need to use OpenGL. In
>>fact, for the most part, they don't bother. There are some instances
>>where they use OpenGL, but most of what a workstation user does fits
>>squarely within all the functionality supplied by Xlib, which is
>>entirely 2D.
>
> [snip]
>
> My opinion, for what its worth:
>
> Do 3D first and only. 2D is a subset of 3D. Implement as much of
> OpenGL as you can in hardware and software can emulate any 2D interface
> desired.
If that's what's important, then fine. Just keep in mind the resulting
performance hit for many 2D operations.
A 2D engine is simple, and it's very parallelizable. For instance, the
logic to process 8 pixels at a time isn't much more than what's required
to process 1 pixel at a time. Since everything has a fixed orientation,
you can make lots of simplifying assumptions. With 3D, you can't
parallelize things like texture-mapping in the same way, because
although the destination pixels are fixed in orientation, the source
pixels are not. So while you can have one 2D pipeline that processes 8
pixels, the 3D equivalent would be 8 separate 3D pipelines. In other
words, 2D scales better than 3D.
>
> I agree that existing graphics cards do 2D just fine. I can get a ATI
> card for $20 that does all the 2D I need. But 2D isn't enough for me.
> I spend $400 on one Nvidia card. Maybe I'm not the average, common
> user, but users like me have the highest profit margin. :-)
I don't think we can produce a $20 card, at least not as a first-run.
To get our volumes up, we would TRY to sell this card into the Windows
market. Yeah, I know... PAIN. But even so, Windows is a different
world where ideals like open source don't matter, which means the
benefits of this product mostly disappear.
As I understand it, one of the reasons nVidia doesn't release specs is
because they don't own all of their IP, so they're contractually
disallowed from releasing certain information. And that's just fine.
The problem is that if you want to save money and buy a faster, cheaper
nVidia card, you're stuck with closed-source drivers. If you run into a
kernel bug, LKML members are going to be reluctant to help you with your
tainted kernel.
I don't know anything about ATI's position, but since I don't want to
deal with closed-source drivers (and the fact that ATI's drivers don't
play nice with fbconsole), I'm stuck with a Radeon 9000. (I do believe
the 9200 also works with the open source drivers.) I'm also stuck with
3D acceleration which is not nearly what I'd get from ATI-supplied drivers.
I REALLY LIKE ATI and nVidia cards.... for WINDOWS. For Linux, I think
I want something else.
Hmmm... so it seems that if you want open source drivers, you're going
to have to live with slow 3D no matter WHAT you do. :)
> I'm a pragmatic user. I'd like full-featured Open Source drivers for my
> Nvidia card but I use the binary because they work really well and for
> me, (excellent_performance - closed_drivers) > (crappy_performance +
> open_drivers).
I haven't upgraded my kernel on this RH7.2 box here in AGES, because
every time I do, I have to try to remember how to rebuild the nVidia
driver. Eventually, I just gave up on it. Of course, that leaves me
without all sorts of enhancements and bug fixes. Some time soon, I'm
going to switch over to Gentoo, but to do that, I've procured a Radeon
9200 so I don't have to worry about closed-source drivers.
> If it can be done well enough to run Doom 3 in 640x480 at 20 fps for
> less than $500, I'll buy one. That's the performance level where I'd
> consider sacrificing 60 fps for the open drivers.
Well, that might be doable at $500. I don't know. I haven't started
thinking about some of the more high-end stuff like programmable virtex
shading, bump mapping, or applying multiple textures in a single pass.
> Of course, in 5 years I'll expect 120 fps so its definitely a moving
> target.
Heh.
Oh, hey... another advantage of doing the open approach is that if we
decide to completely redesign the register set, it isn't a problem,
because there won't be any guessing about what's changed and what hasn't.
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.
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.
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'.
John Ripley wrote:
>
> Actually what I'd love to see is an FPGA based graphics card which is
> *extremely* minimal - essentially just a integer DSP. I'd issue coprocessor
> commands to it like:
>
> QueueSpanRender(long out_address, int pixels, Texture *source_tex, TexCoords
> *coords);
>
> And that would be about the most complicated thing it would do. All
> geometry, clipping, texture coordinate calculation etc done on the CPU. Even
> the coefficients for traversing the texture are done by the CPU. You then
> only need to implement a very small number of primitives in FPGA. You could
> probably "emulate" VGA and friends using a small microcontroller on the
> board monitoring frame buffer and IO access, and a ton of waitstates :) But
> hey, that's just to boot the machine.
>
> In a purely software renderer, it's the pixel pushing which (last I checked)
> takes an enormous chunk of CPU time. You latest GPUs are doing something
> like 4-32 texture lookups and applications per cycle these days, which a
> general purpose CPU really struggles to get anywhere near. It's something a
> DSP/dedicated hardware can do far better than a general purpose CPU. It'd be
> interesting to try, actually: run Doom 3 on linux under Mesa (if that's at
> all possible :), turn off all pixel rendering in Mesa, and see how much
> faster it runs.
>
> This would probably also make a good trade-off on an embedded platform.
Not too long ago, some people were experimenting with nVidia cards and
trying to use them as part of a renderer. One of the things they found
was that although the GPU was orders of magnitude faster at rendering
than was the host CPU, the time it took to get the commands onto the
card and the results back off was so high that it eliminated most of the
advantage.
I have before thought of the idea of selling a "card full of FPGAs" that
developers could use for all sorts of compute-intensive projects. You
could program them to do rendering or protein folding or FFT's for SETI.
But in that case, I'm not sure what Tech-Source's value add would be,
since you'd have to get all of your software tools from the FPGA vendor.
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. :)
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
$B<:GT$9$k2DG=@-$N$"$k$b$N$O!"<:GT$9$k!#(B
np: RAID - $BIT@?<B$JF;$N>e$G$N%5%P%$%P%k(B
John Ripley wrote:
>
> It would also really reduce the cost and effort involved in producing the
> card. It wouldn't take much (heh) to get it up and running as a simple frame
> buffer + blitter, but it could be scaled to do fancy multi-texture ops over
> time - all just by reprogramming the FPGA. All the manufacturer needs to
> provide is a "getting started" FPGA file and output to a video DAC. The
> community would do the rest over time.
>
> I think "Open" hardware is one thing, but open *and* completely
> reprogrammable is a far greater hook, at least for me. I'd be prepared to
> shell out a few $100 for something as hackable as that. Hey, it's an FPGA on
> a PCI Express card at the end of the day, what can't you do with it!
>
Ok, I'll bite. What you're suggesting is that instead of developing
just a graphics card, I should develop a card populated with a bunch of
FPGA's that's reprogrammable. Putting aside the logic design tool issue
(which may be difficult), what you'd get is a very expensive
reprogrammable card with some RAM and some video output hardware.
How much would you pay for THIS card? $2000?
Now, the thing is, this card is SO generic that Tech Source would have
very little value-add. Say we populate it with a bunch of Spartan 3
400's... well, you'd download Xilinx's WebPack, code up your design in
Verilog (Do you want to learn chip design??? It's not like programming
in C!!!), and then use our open source utility to upload your code.
GREAT... until some other company comes along and clones it, which would
be WAY too easy to do. Now, for the users of this sort of product, it's
a fine thing. But it becomes a pointless investment for Tech Source,
which is where I work and who pays me to work on this stuff, which they
wouldn't do if it's not worth it.
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.
On Thu, 21 Oct 2004 14:15:06 -0400, Timothy Miller
<[email protected]> 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)
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.
Timothy Miller wrote:
>
> Ok, I'll bite. What you're suggesting is that instead of developing
> just a graphics card, I should develop a card populated with a bunch of
> FPGA's that's reprogrammable. Putting aside the logic design tool issue
> (which may be difficult), what you'd get is a very expensive
> reprogrammable card with some RAM and some video output hardware.
>
> How much would you pay for THIS card? $2000?
$300
Here's a rough breakdown (FPGA $ => http://makeashorterlink.com/?F23722699
$52 for 8 (eight!) Spartan 3/400 (XC3S400 = $6.50 @ 250k qty)
$30 for 256MB DRAM
$60 for Board, D/A, manufacturing, etc.
----
$142 rough guesstimate hardware costs
$158 for software/profit
>
> Now, the thing is, this card is SO generic that Tech Source would have
> very little value-add. Say we populate it with a bunch of Spartan 3
> 400's... well, you'd download Xilinx's WebPack, code up your design in
> Verilog
Yeah, that's probably the catch, because I'd want to use gvs (GNU
verilog/VHDL synthesis ;)
> (Do you want to learn chip design??? It's not like programming
> in C!!!), and then use our open source utility to upload your code.
Chip design isn't that much different than writing code. Plus it
would be a great learning experience for anyone who hasn't tried a
hardware design language. (Kinda like how learning lisp is an eye
opener for most people). Besides, I think someone would eventually
port or create some interesting high level concurrent languages to use.
(I could see some interesting primitives added to a language like Erlang
or Oz to try to exploit the parallel nature of the FPGAs)
> GREAT... until some other company comes along and clones it, which would
> be WAY too easy to do. Now, for the users of this sort of product, it's
> a fine thing.
It might not turn out to be a high profit margin business, but then
again, I don't think slapping together "white boxes" is high margin
either, but there doesn't seem to be a shortage of them.
> But it becomes a pointless investment for Tech Source,
> which is where I work and who pays me to work on this stuff, which they
> wouldn't do if it's not worth it.
The hardest part would seem to be the software needed, i.e. a free
synthesizer/mapper. But somehow we've managed to create an entire free
operating system. I suppose it just takes time. Maybe in another 5/10
years. Or maybe we need to think of a better way to fund open hardware
projects. If there were 25,000 of us who really wanted this project, we
could pay our $300 into an escrow account ($7.5E6 total). When the
boards were delivered, the manufacturing company would get half the
money, and when version 1.0 of the software was completed, they'd get
the other half. Surely a bank would loan money against that kind of
collateral. But now I'm probably rambling.
Greg Buchholz
On Thu, 2004-10-21 at 19:09, Timothy Miller wrote:
> I have before thought of the idea of selling a "card full of FPGAs" that
> developers could use for all sorts of compute-intensive projects. You
> could program them to do rendering or protein folding or FFT's for SETI.
> But in that case, I'm not sure what Tech-Source's value add would be,
> since you'd have to get all of your software tools from the FPGA vendor.
Something like this http://www.fpga4fun.com/board_dragon.html with this
http://www.fpga4fun.com/PongGame.html
That covers the base to do VGA display with an FPGA. But the cost is
pretty much prohibitive at over $250 per unit.
Baruch
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...
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
Greg Buchholz wrote:
> Timothy Miller wrote:
>
>>Ok, I'll bite. What you're suggesting is that instead of developing
>>just a graphics card, I should develop a card populated with a bunch of
>>FPGA's that's reprogrammable. Putting aside the logic design tool issue
>>(which may be difficult), what you'd get is a very expensive
>>reprogrammable card with some RAM and some video output hardware.
>>
>>How much would you pay for THIS card? $2000?
>
>
> $300
>
> Here's a rough breakdown (FPGA $ => http://makeashorterlink.com/?F23722699
>
> $52 for 8 (eight!) Spartan 3/400 (XC3S400 = $6.50 @ 250k qty)
> $30 for 256MB DRAM
> $60 for Board, D/A, manufacturing, etc.
> ----
> $142 rough guesstimate hardware costs
> $158 for software/profit
How are you getting these prices for the FPGAs? Maybe they have changed
since I last checked. And what volumes are you expecting here?
Anyhow, this is helpful, also, in terms of the parts costs for the
graphics board idea. We need to update our prices.
>
>>Now, the thing is, this card is SO generic that Tech Source would have
>>very little value-add. Say we populate it with a bunch of Spartan 3
>>400's... well, you'd download Xilinx's WebPack, code up your design in
>>Verilog
>
>
> Yeah, that's probably the catch, because I'd want to use gvs (GNU
> verilog/VHDL synthesis ;)
If you can get it to talk to a Xilinx, I don't care.
>
>>(Do you want to learn chip design??? It's not like programming
>>in C!!!), and then use our open source utility to upload your code.
>
>
> Chip design isn't that much different than writing code. Plus it
> would be a great learning experience for anyone who hasn't tried a
> hardware design language. (Kinda like how learning lisp is an eye
> opener for most people). Besides, I think someone would eventually
> port or create some interesting high level concurrent languages to use.
> (I could see some interesting primitives added to a language like Erlang
> or Oz to try to exploit the parallel nature of the FPGAs)
I'm a pretty good engineer, and I have to tell you that it took me 2
years before I got a real "grok"-level feel for chip design. When
programming C, there are just certain things you "know" about how the
code you write is going to translate into machine code. The same thing
is true for designing hardware. It took me about a week to learn
Verilog syntax really well (even got some of the concepts that trip
people up like "natural size"), but it took me a LONG time to really get
GOOD at it.
There's this general rule of thumb that if you write your C code more
compactly, you often get a faster result. Not always true, but more
often than not. Well, the exact opposite is true for HDL. The more
elaborate and specific you are, the better your results are, because the
synthesizer has more information about what it is that you really want.
I see programming and chip design as two very different things. One is
sequential, and the other has everything going on in parallel. Maybe
I'm unnecessarily compartmentalizing.
Oh, and I do get the LISP thing, although if I got into it, I'd probably
prefer Scheme, because I've seen too many examples of LISP code that
seem to violate my understanding of what LISP is supposed to be like. I
can't recall the specific example, however.
>
>>GREAT... until some other company comes along and clones it, which would
>>be WAY too easy to do. Now, for the users of this sort of product, it's
>>a fine thing.
>
>
> It might not turn out to be a high profit margin business, but then
> again, I don't think slapping together "white boxes" is high margin
> either, but there doesn't seem to be a shortage of them.
This company is used to being a niche player. The profit margins are
higher in vertical markets. This commodity graphics board idea is going
to be hard enough sell as it is.
>
>>But it becomes a pointless investment for Tech Source,
>>which is where I work and who pays me to work on this stuff, which they
>>wouldn't do if it's not worth it.
>
>
> The hardest part would seem to be the software needed, i.e. a free
> synthesizer/mapper. But somehow we've managed to create an entire free
> operating system. I suppose it just takes time. Maybe in another 5/10
> years. Or maybe we need to think of a better way to fund open hardware
> projects. If there were 25,000 of us who really wanted this project, we
> could pay our $300 into an escrow account ($7.5E6 total). When the
> boards were delivered, the manufacturing company would get half the
> money, and when version 1.0 of the software was completed, they'd get
> the other half. Surely a bank would loan money against that kind of
> collateral. But now I'm probably rambling.
Some of these things will require a "grass roots" effort amongst open
source developers. I can tell you that Tech Source, among other
companies, I'm sure, may be willing to produce hardware according to
someone's open design.
The further away from our core business I stray, the hardware it will be
to sell the idea to management.
On Wed, 20 Oct 2004 18:02:51 -0400
Timothy Miller <[email protected]> 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
Timothy Miller wrote:
>
> How are you getting these prices for the FPGAs? Maybe they have changed
> since I last checked. And what volumes are you expecting here?
I took the pricing from a xilinx press release found here (for 250k
qty)...
http://www.xilinx.com/prs_rls/silicon_spart/03142s3_pricing.htm
"Pricing and Availability: The 3S50, 3S200, and 3S400 Spartan-3 devices
with 50,000, 200,000, and 400,000 system gates respectively, are
available for less than $6.50*. The 3S1000 Spartan-3 device with 1
million system gates is also available for under $12.00*. The entire
Spartan-3 family will be available in volume production in early 2004
from distributors worldwide, or direct from Xilinx at
http://www.xilinx.com/spartan/"
> I'm a pretty good engineer, and I have to tell you that it took me 2
> years before I got a real "grok"-level feel for chip design. When
> programming C, there are just certain things you "know" about how the
> code you write is going to translate into machine code. The same
> thing is true for designing hardware. It took me about a week to
> learn Verilog syntax really well (even got some of the concepts that
> trip people up like "natural size"), but it took me a LONG time to
> really get GOOD at it.
I'll bet it also took you two years from the time you were first
exposed to programming to the time when you could look at a chunk of C
code and know about how many assembly instructions would be generated
;-).
> There's this general rule of thumb that if you write your C code more
> compactly, you often get a faster result. Not always true, but more
> often than not. Well, the exact opposite is true for HDL. The more
> elaborate and specific you are, the better your results are, because
> the synthesizer has more information about what it is that you really
> want.
C is to assembly as Verilog is to schematic entry. Which means C
and Verilog are both increadibly low level languages. Some day most
digital circuits will be designed with higher level language like Lava
(http://www.xilinx.com/labs/lava/) or Ruby HDL
(http://web.comlab.ox.ac.uk/oucl/work/geraint.jones/ruby/). (Or at
least that's what I'm hoping for). And maybe a project like this will
bring that day sooner.
> I see programming and chip design as two very different things. One
> is sequential, and the other has everything going on in parallel.
Nah, two sides of the same coin. Think sum of products vs. product
of sums, functional programming languages vs. imperative programming
languages, time domain vs. frequency domain, analytical methods vs.
numerical methods, ying vs. yang...
> This company is used to being a niche player. The profit margins are
> higher in vertical markets. This commodity graphics board idea is
> going to be hard enough sell as it is.
Yeah, I've mostly drifted into the dream world of what I'd like to
see, not necessarily what is practical. But you've got to admit, the
board with 8 FPGAs would be one hell of cool hack.
Greg Buchholz
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..
How about something simpler, an extender for Myth TV. It is a small
box that sits next to a TV/stero and lets it play video/audio streamed
off from a PC located elsewhere. A few of these have been discussed on
slashdot lately but nothing open source.
Windows Media Center version
http://www.pcmag.com/review/0%2C2491%2Cs%3D26227&a%3D136832%2C00.asp
--
Jon Smirl
[email protected]
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.
Greg Buchholz <[email protected]> said on Thu, 21 Oct 2004 10:08:08 -0700:
> Stephen Wille Padnos wrote:
> >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 idea is a step in the right direction. To make the project
> viable, you might be better off trying to court a slightly different
> audience (instead of the cost-sensitive/3D-performant market). What if
> instead, you were selling a highly parallel reprogrammable computing
> core, which also happened to do graphics? I could see a potentially
> much bigger and higher profit margin market for a standardized interface
> from Linux to an FPGA. Image people buying them for headless servers as
> crypto accellerators. Or as DSP/FFT accellerators (for speech
> recognition , MPEG compression, or whatever). I'm sure you'd sell a few
> to grad students writing theses on data flow machines, parallel
> languages, prime factorization etc. Heck, I'd buy one just because it'd
> be cool to try and write a 1000 element merge sort in hardware that
> completed in one or two clock cycles. It's not hard to imaging people
> using it to speed up emulators like QEMU. Maybe the distributed
> computing folks (Folding@Home, SETI) would also be interested, since
> their work is already highly parallelizable. You get the idea.
People would happily pay millions for this.
Tim has probably heard of Grape?
I don't know whether grape uses FPGAs or not, but take a look at the
photo down the bottom of this:
http://grape.c.u-tokyo.ac.jp/~fukushig/paper/sc96/sc96.html
I reckon if we could put an accelarator card in each of our 200 new
machines, that could be programmed on the fly to do N-body
calculations, or then changed to do SPH, or whatever, and we only had
to pay $500 per card, and it doubled performace, we'd do it in a
second. Half the number of computers, drop energy consumption (and
cooling), etc. It'd be great.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
A mouse is a device used to focus xterms.
>>>>> "Jan" == Jan Knutar <[email protected]> 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.
Timothy,
I don't think you can approach the price-to-performance ratio close
enough to get a market share to make it worthwhile. I hope I'm wrong
and I respect what you're trying to do.
Roy
P.S. Stability would be higher than anything else in my book.
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/
----------------
[email protected]
Jon Smirl <[email protected]> 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! ~
David Lang <[email protected]> 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! ~
Alan Cox <[email protected]> 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! ~
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.
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
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
http://www.bluefish444.com cards are way too expensive
oh, and throw 512M of ram on there :D
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, http://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.
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
> From: Timothy Miller [mailto:[email protected]]
> Sent: 21 October 2004 19:26
> To: John Ripley
> Cc: 'Greg Buchholz'; [email protected]
> Subject: Re: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?
>
> John Ripley wrote:
>
> > It would also really reduce the cost and effort involved in
> > producing the
> > card. It wouldn't take much (heh) to get it up and running
> > as a simple frame
> > buffer + blitter, but it could be scaled to do fancy
> > multi-texture ops over
> > time - all just by reprogramming the FPGA. All the
> > manufacturer needs to
> > provide is a "getting started" FPGA file and output to a
> > video DAC. The
> > community would do the rest over time.
> >
> > I think "Open" hardware is one thing, but open *and* completely
> > reprogrammable is a far greater hook, at least for me. I'd
> > be prepared to
> > shell out a few $100 for something as hackable as that.
> > Hey, it's an FPGA on
> > a PCI Express card at the end of the day, what can't you do with it!
>
>
> Ok, I'll bite. What you're suggesting is that instead of developing
> just a graphics card, I should develop a card populated with
> a bunch of
> FPGA's that's reprogrammable. Putting aside the logic design
> tool issue
> (which may be difficult), what you'd get is a very expensive
> reprogrammable card with some RAM and some video output hardware.
>
> How much would you pay for THIS card? $2000?
Considering you can get a Spartan 2 300,000 gate chip on a board with SDRAM
etc for about $100... I'd say that's a very high estimate. Greg's pricing up
of about $300 sounds about right, and that's with 8 Spartan 3 chips on a
board.
> Now, the thing is, this card is SO generic that Tech Source
> would have
> very little value-add. Say we populate it with a bunch of Spartan 3
> 400's... well, you'd download Xilinx's WebPack, code up your
> design in
> Verilog (Do you want to learn chip design??? It's not like
> programming
> in C!!!), and then use our open source utility to upload your code.
I'm well aware that C programming doesn't translate to chip design skills.
I've been playing with Verilog on simulators for a while now and I'd love to
actually put it on some real FPGA hardware. There's plenty of people with
good chip design knowledge willing to provide Free source - just look at
opencores.org. I'm doing ALL of my Verilog toying with Free (properly)
software, and I think there's even a Free tool to interface to Xilinx FPGAs.
> GREAT... until some other company comes along and clones it,
> which would
> be WAY too easy to do. Now, for the users of this sort of
> product, it's
> a fine thing. But it becomes a pointless investment for Tech Source,
> which is where I work and who pays me to work on this stuff,
> which they wouldn't do if it's not worth it.
And what would stop them cloning a graphics card with completely Open specs?
That's always an issue no matter what you do.
- John Ripley
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
In gmane.linux.kernel John Ripley wrote:
> There's plenty of people with
> good chip design knowledge willing to provide Free source - just look at
> opencores.org.
Agreed, open hardware design seems to be stuck at the point that good
solutions exist, that are not made accessible like it's done by Linux
distributors in the software world. For Techsource it might be more
worthwhile to play that role than developing a design from scratch.
There's even a project for an open 3D GPU in VHDL:
http://icculus.org/manticore
Cheers,
Moritz
On Thu, Oct 21, 2004 at 02:26:15PM -0400, Timothy Miller wrote:
>
>
> John Ripley wrote:
>
> >
> >It would also really reduce the cost and effort involved in producing the
> >card. It wouldn't take much (heh) to get it up and running as a simple
> >frame
> >buffer + blitter, but it could be scaled to do fancy multi-texture ops over
> >time - all just by reprogramming the FPGA. All the manufacturer needs to
> >provide is a "getting started" FPGA file and output to a video DAC. The
> >community would do the rest over time.
> >
> >I think "Open" hardware is one thing, but open *and* completely
> >reprogrammable is a far greater hook, at least for me. I'd be prepared to
> >shell out a few $100 for something as hackable as that. Hey, it's an FPGA
> >on
> >a PCI Express card at the end of the day, what can't you do with it!
> >
>
>
> Ok, I'll bite. What you're suggesting is that instead of developing
> just a graphics card, I should develop a card populated with a bunch of
> FPGA's that's reprogrammable. Putting aside the logic design tool issue
> (which may be difficult), what you'd get is a very expensive
> reprogrammable card with some RAM and some video output hardware.
>
> How much would you pay for THIS card? $2000?
>
> Now, the thing is, this card is SO generic that Tech Source would have
> very little value-add. Say we populate it with a bunch of Spartan 3
> 400's... well, you'd download Xilinx's WebPack, code up your design in
> Verilog (Do you want to learn chip design??? It's not like programming
> in C!!!), and then use our open source utility to upload your code.
>
> GREAT... until some other company comes along and clones it, which would
> be WAY too easy to do. Now, for the users of this sort of product, it's
> a fine thing. But it becomes a pointless investment for Tech Source,
> which is where I work and who pays me to work on this stuff, which they
> wouldn't do if it's not worth it.
Make a PCI-Express card -> dual DVI output, with whatever number of
FPGA's gets you to $500 cost. If people want to play with reconfigurable
whatever, let them go ahead.
Techsource's value-add is an *optimized* high-performance bitstream that
implements a nice graphics card that has fully documented open-source
linux drivers. You can sell the hardware at cost, but what people really
want (and will pay for) is the fastest high-end 3d rendering stuff for
engineering and technical applications. They will probably also pay for
subscribtion updates where techsource takes the latest innovate ideas
that someone implemented on this hardware as a research project, and
then someone with the experience in graphics and hardware design can
make it go fast and work with the rest of the other optimized features.
You could go so far as to do something like ghostscript and release the
verilog source after 2 years when nobody cares about the old hardware it
runs on anymore (execept the hobbyists).
Greg Buchholz wrote:
> Timothy Miller wrote:
>
>>How are you getting these prices for the FPGAs? Maybe they have changed
>>since I last checked. And what volumes are you expecting here?
>
>
> I took the pricing from a xilinx press release found here (for 250k
> qty)...
>
> http://www.xilinx.com/prs_rls/silicon_spart/03142s3_pricing.htm
>
> "Pricing and Availability: The 3S50, 3S200, and 3S400 Spartan-3 devices
> with 50,000, 200,000, and 400,000 system gates respectively, are
> available for less than $6.50*. The 3S1000 Spartan-3 device with 1
> million system gates is also available for under $12.00*. The entire
> Spartan-3 family will be available in volume production in early 2004
> from distributors worldwide, or direct from Xilinx at
> http://www.xilinx.com/spartan/"
Unless we have a major Linux hardware vendor partnering with us, I
cannot feel confident that we could make those sorts of volumes. Think
of the out-lay just to purchase the initial stock. And then by the time
we sell 1/10 of them, the price will have dropped and we'll have a stock
of chips worth less than we paid for them.
Bleh. I feel very stupid when it comes to the business and economics of
this. I'm an engineer with what I think is a cool idea, but right now
I'm working on crash-coursing myself in all the business of it. Before
long, the real marketing people here will get interested, but I have to
prove some things to them first.
It won't be long, though. The Slashdot buzz has everyone in the company
coming by my office to distract me from writing this LKML post. :)
>>I'm a pretty good engineer, and I have to tell you that it took me 2
>>years before I got a real "grok"-level feel for chip design. When
>>programming C, there are just certain things you "know" about how the
>>code you write is going to translate into machine code. The same
>>thing is true for designing hardware. It took me about a week to
>>learn Verilog syntax really well (even got some of the concepts that
>>trip people up like "natural size"), but it took me a LONG time to
>>really get GOOD at it.
>
>
> I'll bet it also took you two years from the time you were first
> exposed to programming to the time when you could look at a chunk of C
> code and know about how many assembly instructions would be generated
> ;-).
No. Maybe 15 to 20 for that. :)
>
>
>>There's this general rule of thumb that if you write your C code more
>>compactly, you often get a faster result. Not always true, but more
>>often than not. Well, the exact opposite is true for HDL. The more
>>elaborate and specific you are, the better your results are, because
>>the synthesizer has more information about what it is that you really
>>want.
>
>
> C is to assembly as Verilog is to schematic entry. Which means C
> and Verilog are both increadibly low level languages. Some day most
> digital circuits will be designed with higher level language like Lava
> (http://www.xilinx.com/labs/lava/) or Ruby HDL
> (http://web.comlab.ox.ac.uk/oucl/work/geraint.jones/ruby/). (Or at
> least that's what I'm hoping for). And maybe a project like this will
> bring that day sooner.
My point is that understanding assembly does not in any way
automatically translate into an understanding of logic circuitry. In
fact, I'd have to say that I had to break as many habits as I developed
when learning to be a chip designer.
>
>>I see programming and chip design as two very different things. One
>>is sequential, and the other has everything going on in parallel.
>
>
> Nah, two sides of the same coin. Think sum of products vs. product
> of sums, functional programming languages vs. imperative programming
> languages, time domain vs. frequency domain, analytical methods vs.
> numerical methods, ying vs. yang...
I'll have to talk to my wife about this. She has a law degree and is
working on an information science degree right now. I find that I
compartmentalize my understanding of things, so when I explain technical
things to her, she has trouble understanding them sometimes, not because
she can't grok it, but because I make assumptions of dichotomies which
are completely arbitrary and make no sense from the outside.
For instance, we had a frustrating discussion where she seemed to be
assuming that there was no difference, abstractly, between an HTML
document and a Java program. I always thought of programs and documents
as two different things. Eventually, she got it through my thick skull
that if you see an executable file and an HTML document and a JPG file
as nothing more than symbols that have to be interpreted by something
else, then they really ARE the same thing.
Here's the kicker that caused so much confusion: The idea that there
could be one level or multiple levels of interpretation seemed so
trivially obvious to her that it never occurred to her to mention the
idea. :)
Now, it's obvious enough to me, but I never thought of it as so
PAINFULLY obvious. When you look at things this way, you start to see
that, for example, a CPU is nothing more than "middleware" between
machine code and physical reality. :)
Anyhow, the reason for that long discussion is because I see chip design
and software programming as generally incompatible mindsets. Sure, one
can certainly help you to learn the other, but many methodologies that
apply to one would be horrible to apply to the other. Learning Verilog
syntax and then trying to apply software programming concepts to it will
get you absolutely nowhere. Perhaps she can help me to see it your way. :)
>
>>This company is used to being a niche player. The profit margins are
>>higher in vertical markets. This commodity graphics board idea is
>>going to be hard enough sell as it is.
>
>
> Yeah, I've mostly drifted into the dream world of what I'd like to
> see, not necessarily what is practical. But you've got to admit, the
> board with 8 FPGAs would be one hell of cool hack.
It would be a cool thing to play with, and I'm not taking it off the
table, but I have to start out at least LOOKING like I'm doing something
practical. :)
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.
Timothy Miller wrote:
> Anyhow, the reason for that long discussion is because I see chip design
> and software programming as generally incompatible mindsets. Sure, one
> can certainly help you to learn the other, but many methodologies that
> apply to one would be horrible to apply to the other.
Hmm...I've got a buddy doing a Master's in codesign, where you literally design
the chip and the software to run on it at the same time, so you can simulate
them both at the same time and optimise which bits you do in hardware and which
in software.
Seems to me that chip design and software programming (at least for low-level
high-performance stuff) are tightly intertwined.
Of course there's the other side of things where you write in prolog or lisp and
are totally abstracted from the hardware--but I don't see too many people
writing e.g. graphics drivers in those languages.
Chris
I agree that trying to sell first to the open market would not be
cost-effective. Some have suggested, however, that we sell to system
integrators and motherboard manufacturers primarily. As a side-effect,
you'd be able to buy one at a reasonable price.
Roy Butler wrote:
> Timothy,
>
> I don't think you can approach the price-to-performance ratio close
> enough to get a market share to make it worthwhile. I hope I'm wrong
> and I respect what you're trying to do.
>
>
> Roy
>
>
> P.S. Stability would be higher than anything else in my book.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
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.
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
Chris Friesen wrote:
> Timothy Miller wrote:
>
>> Anyhow, the reason for that long discussion is because I see chip
>> design and software programming as generally incompatible mindsets.
>> Sure, one can certainly help you to learn the other, but many
>> methodologies that apply to one would be horrible to apply to the other.
>
>
> Hmm...I've got a buddy doing a Master's in codesign, where you literally
> design the chip and the software to run on it at the same time, so you
> can simulate them both at the same time and optimise which bits you do
> in hardware and which in software.
>
> Seems to me that chip design and software programming (at least for
> low-level high-performance stuff) are tightly intertwined.
>
> Of course there's the other side of things where you write in prolog or
> lisp and are totally abstracted from the hardware--but I don't see too
> many people writing e.g. graphics drivers in those languages.
>
Oh, they are intertwined, alright. They just require different mindsets
to do either of then WELL. I'm sure your friend is equally adept at
both mindsets, so that isn't an issue.
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.
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.
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)
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.
On Thu, 21 Oct 2004, J.A. Magallon wrote:
> So, as I see it, for an appealing 2D card, you need to program a 2 1/2
> graphics engine, with really _fast_ alpha blending and antialiasing.
> You can only kill the matrix part. I do not know if you will be able to
> get rid completely of floating point, for those alpha mixes and assorted
> candy...
Alpha blending (and Porter-Duff operations in general) can easily be done in
integer. You do want to read Rasterman's excellent comments in the Imlib2
sources, though.
Been there, done that... (for a STB without FPU and without hardware blending)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
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)
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 -- [email protected]
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
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 -- [email protected]
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
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
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
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
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.
-----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-----
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.
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
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.
John Ripley wrote:
> And what would stop them cloning a graphics card with completely Open specs?
> That's always an issue no matter what you do.
Our value-add would be the graphics core whose code we wouldn't release
until (maybe) the design was a few generations old. Sure, they could
clone the functionality, but they's still have to reengineer it from
scratch.
Timothy Miller wrote:
> 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.
What has this to do with the kernel? More relevant on X server, OpenGL or GPGPU lists?
Baseline - I can get accelerated 3D graphics and video overlay
and YV12 and VGA registers with open source driver that compiles
for PowerPC and DEC Alpha today for $85 - Radeon 7500 PCI.
X.org 'ati' driver at http://x.org
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/drivers/ati/?root=xorg
If you can improve on that then I will buy one for each of my Alpha and PowerPC systems.
http://www.gpgpu.org/ are programming multivendor graphics cards for
general purpose computing BUT the toolchain involves a proprietary
compiler which is single platform.
What good is a card with open source hardware and open source
driver that is programmable BUT the toolchain is proprietary?
Stephen Lewis
On Friday 22 October 2004 13:15, Stephen Lewis wrote:
>Timothy Miller wrote:
>> 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.
>
>What has this to do with the kernel? More relevant on X server,
> OpenGL or GPGPU lists?
>
>Baseline - I can get accelerated 3D graphics and video overlay
>and YV12 and VGA registers with open source driver that compiles
>for PowerPC and DEC Alpha today for $85 - Radeon 7500 PCI.
'scuse me, but have you tried to buy one of those locally? The
unwashed masses of us are stuck with whatever we can buy at Circuit
City et all, and the cheapest thing today for an AGP slot is the
house brands of the 9200 SE w/128 megs of ddr ram.
>X.org 'ati' driver at http://x.org
>http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xf
>ree86/drivers/ati/?root=xorg If you can improve on that then I will
> buy one for each of my Alpha and PowerPC systems.
Has this links code been substantially updated since the 6.8.1 release
as built on an x86 system? If not, then this common readily
available card is still not supported all that well, my lspci outputs
say the vendor codes are unknown. And my glxgears is 198 fps.
>
>http://www.gpgpu.org/ are programming multivendor graphics cards for
>general purpose computing BUT the toolchain involves a proprietary
>compiler which is single platform.
>What good is a card with open source hardware and open source
>driver that is programmable BUT the toolchain is proprietary?
>
>Stephen Lewis
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
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.
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.
Kendall Bennett wrote:
> David Lang <[email protected]> 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.
On Sat, 23 Oct 2004 00:45:49 -0400
Gene Heskett <[email protected]> wrote:
...
> >Baseline - I can get accelerated 3D graphics and video overlay
> >and YV12 and VGA registers with open source driver that compiles
> >for PowerPC and DEC Alpha today for $85 - Radeon 7500 PCI.
>
> 'scuse me, but have you tried to buy one of those locally? The
> unwashed masses of us are stuck with whatever we can buy at Circuit
> City et all, and the cheapest thing today for an AGP slot is the
> house brands of the 9200 SE w/128 megs of ddr ram.
What do you have against eBay?
>...
> Has this links code been substantially updated since the 6.8.1 release
> as built on an x86 system? If not, then this common readily
> available card is still not supported all that well, my lspci outputs
> say the vendor codes are unknown. And my glxgears is 198 fps.
>
Sorry I have no x86 systems.
9200SE is listed as 3d accelerated see here:
http://freedesktop.org/~xorg/X11R6.8.0/doc/radeon.4.html
maybe you do not have dri loaded?
> --
> Cheers, Gene
Stephen Lewis
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
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.
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
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
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.
If you want to be able to see the BIOS, you'll need some legacy emulation,
but it should be enough to implement MDA output.
Since some VGA cards used to depend on the MDA/CGA BIOS routines, most
(all?) BIOS variants will implement all nescensary IO functions. You'll
need some MDA registers for the cursor position (that don't even clash with
EGA/VGA/CGA), 4K mapped memory at B000:0000 and a loop translating the text.
--
Top 100 things you don't want the sysadmin to say:
21. where did you say those backup tapes were kept?
Alan Cox <[email protected]> :
[...]
> > 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
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.
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
Alan Cox <[email protected]> :
> 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
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
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
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
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
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
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
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.
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
Not exactly the question you asked - but an alternative thought.
I wonder what interest there might would be in an open source
one-time-password secure id type card?
Not sure how easy it would be to make reset/resync the card to
the server random sequence via something - serial/usb/ethernet?
Something like an rsa secureid card but open source server?
I am sure community could help program the server side?
Not sure of the business implications as large institutions
can afford to amortize a larger cost - however small businesses,
eductional institutions and home users might be very happy
with a standard secure remote access facility.
Again OEM's might be happy to have this as a standard option -
you know an sell the cards as a standard addon - small or large quantity.
Thoughts?
gene/
On Fri, Oct 22, 2004 at 01:04:38PM -0400, Timothy Miller wrote:
> Please read the FAQ at http://www.tux.org/lkml/
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!
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
Bodo Eggert 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.
>>
>>
>If you want to be able to see the BIOS, you'll need some legacy emulation,
>but it should be enough to implement MDA output.
>
>
Nope. The PC BIOS looks for "expansion ROMs", and calls initialization
routines in the ones it finds. It then expects to be able to call INT
10 to position the cursor and print text (and read the cursor position,
what's on screen, etc.). You could have a BIOS on a network card that
provides the necessary interrupt routines, but actually talks to a
remote X server for display functions. (yes - it might need to
advertise itself as a video device for this to work)
>Since some VGA cards used to depend on the MDA/CGA BIOS routines, most
>(all?) BIOS variants will implement all nescensary IO functions. You'll
>need some MDA registers for the cursor position (that don't even clash with
>EGA/VGA/CGA), 4K mapped memory at B000:0000 and a loop translating the text.
>
>
Right - all video cards provide these BIOS routines (including one the
one being considered here). They aren't in the system BIOS. (Not that
there are no broken BIOSes around, but strictly speaking, there is no
need at all for the system BIOS to know anything about the display card
being used)
- Steve
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
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.
On Sun, Oct 24, 2004 at 09:44:49PM -0400, Stephen Wille Padnos wrote:
> >Since some VGA cards used to depend on the MDA/CGA BIOS routines, most
> >(all?) BIOS variants will implement all nescensary IO functions. You'll
> >need some MDA registers for the cursor position (that don't even clash with
> >EGA/VGA/CGA), 4K mapped memory at B000:0000 and a loop translating the
> >text.
> Right - all video cards provide these BIOS routines (including one the
> one being considered here). They aren't in the system BIOS. (Not that
> there are no broken BIOSes around, but strictly speaking, there is no
> need at all for the system BIOS to know anything about the display card
> being used)
Wrong - the CGA/MDA cards didn't come with any BIOS on them, and all the
support routines were (and most probably still are) located in the
system BIOS. The first card that replaced IRQ 10 with it's own set of
routines was the EGA and used its own BIOS ROM for that.
So there is no need to have a BIOS on the card to still see the system
BIOS boot messages.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-----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-----
In article <[email protected]> you wrote:
> I wonder what interest there might would be in an open source
> one-time-password secure id type card?
Yes, I would like to see that also. Maybe a USB Dongle with display. That
will require only small and simple components.
>
> Not sure how easy it would be to make reset/resync the card to
> the server random sequence via something - serial/usb/ethernet?
Better do it like RSA, keep resync records in the server and not allow any
electronical interaction with the tokens.
> Something like an rsa secureid card but open source server?
> I am sure community could help program the server side?
I think there are actually enough OTP Implementations out there, which can
be somewhat abused. Personally I would love to see a simple opie
entry/output device with no clocking at all.
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
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.
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.
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.
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
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.
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.
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).
Greg Buchholz wrote:
> Yeah, that's probably the catch, because I'd want to use gvs (GNU
> verilog/VHDL synthesis ;)
Sigh. It's quite sad that we don't even seem to have the complete
toolchain to program a 16V8 (although the information seems to be
available), let alone *any* CPLD. Of course, a 16V8 isn't very sexy
these days, so what might be happening is that people don't care to
solve the easy problem, and thus miss the opportunity to develop
the ability to reverse-engineer the more complex parts.
Regarding the viability of such a product: I wouldn't dismiss brand
name recognition as a factor. If people recognize Tech Source as a
company that has enabled them to do things previously hidden behind
barriers, they may recognize that it is in their own best interest
to help you to continue doing this. Not all will, but enough might.
Another item: it would be good to decide early on a fixed date for
releasing the Verilog source. Or, make this two dates: an internal
one, when you'll put it on your agenda for consideration, and a
hard one, maybe half a year later, which you'll publish. You won't
release on the first deadline, but at least you'll know that you
have to work on getting the thing out, and if you have people who
are still trying to milk the technology, they have time to switch.
Also, by making it clear that the design will be released, you'll
avoid getting trapped by sublicenses. ("Oh, but we just licensed
the design for $$$ - we can't possibly open it now !")
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
Baruch Even wrote:
> http://www.fpga4fun.com/PongGame.html
How excessively wasteful :-)
http://hyvatti.iki.fi/~jaakko/pic/pong/
(Ok, it's just TV, not VGA.)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
On Tue, 26 Oct 2004 12:36:52 +1000, Dave Airlie <[email protected]> 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
[email protected]
> 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.
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
Salut,
On Fri, Oct 22, 2004 at 10:50:43AM -0600, Chris Friesen wrote:
> Of course there's the other side of things where you write in prolog or
> lisp and are totally abstracted from the hardware--but I don't see too many
> people writing e.g. graphics drivers in those languages.
I remember the LispM's.. Oh, well.
Tonnerre
pbecke wrote:
> As a developer, who has been struggling with displaying HDTV using off
> the shelf cards, I am intrigued by an open source video card. Since my
> primary goal is to display HDTV, my primary need is 2D. Support for
> Nvidia and ATI exist, however I still run into problems. For example I
> have been totally unable to display 1080I using a digital interface with
> either vendors card. Even with an analog interface, it is next to
> impossible to reliable synchronize the top and bottom display field,
> with the top and bottom field of an interlace stream. I am sure the
> information must exists on the card somewhere to determine the field
> being displayed, but I am unable to access it because of lack of
> documentation.
We'll have to be sure to include a way to access that information.
>
> In general an open source video card is a great idea, however, I am a
> bit concerned about your plans to keep the FPGA code secret. I realize
> that your company wants to make a profit,
And that is the POINT here. The question isn't whether or not we can
become a charity and give away all of our IP. The question is whether
or not it's possible to sell open-source-friendly products. Designing
and manufacturing hardware is EXPENSIVE. Especially at the volumes I
expect.
> but in keeping with the spirit
> of open source, it seems that it would be a good idea to not only open
> up the driver development, but also to open up the FPGA code. The great
> power of open source is that it allows a developer to tweak the
> implementation.
What you're asking for is excessive. Even Stallman agrees that people
should be able to profit from their work. Opening the source to this
chip would be good for you and for every other company that wants to
copy it, but it would not be good for Tech Source. Tech Source is a
business with a profit motive. Will will not engage in something that
costs us more money than it makes or diverts us from something more
profitable.
You're allowing your lofty free software ideals to get in the way of
what is reasonable and practical. I believe in freedom, which is why I
started this project. But make no mistake in thinking that I'm trying
to waste the time and money of my employer.
The only thing you need to make this product work is the software
information necessary to communicate with it. Hardware is not free, and
it never will be. Software, on the other hand, is trivially easy to
copy. So let's let the software be free.
Also do not make the mistake of believing that software is free to
PRODUCE. If it were, then free software fans wouldn't love the GPL
which protects their investment of time from being ripped off by greedy
companies that would like to steal their work. Tech Source would have
to factor my time to develop software for this product into the final
price that you pay for the hardware. The advantage you have is that the
software, being open source, is guaranteed to outlive you, me, and
everyone else.
> Additionally for this reason, I also think it should be possible to
> dynamically load the FPGA without having to power down or reset. One
> could easily imagine a card where the boot loader loads a simple VGA
> interface, but then upon switching to X, a more sophisticated and
> powerful interface could be loaded. This takes advantage of the
> reprogram ability of an FPGA, while making the device useful to both the
> low end embedded needs as well as the high end gamers.
If you only have one FPGA on the board, then you have a chicken and egg
problem. It's programmed through JTAG which turns the entire chip into
a giant shift register. The moment you start programming it, all
variable logic stops working.
> In fact it may make the most sense for a company like Xilinx to provide
> support for such a development, since ultimately, Xilinx is the company
> that will profit the most by selling more chips. Does anyone know a
> contact at Xilinx who would be open to such a request?
Xilinx already supplies free tools, and they also supply instructions
for getting their tools to work with WINE.
> Perhaps, rather than a single company defining the functionality with
> input from the open source community, it makes more sense for the open
> source community to define the standard, and then any company could work
> from the standard created by the open source community.
As I've said before, if people want to give us a design, we'll
manufacture it!
> The problem isn't so much that the vendors don't provide proper data
> sheets, as it is that there is no open standard for extended registers
> and advanced interfaces on graphics cards. Imagine if USB and IEEE 1394
> and Ethernet where closed standards. We would all be trying to reverse
> engineer M$ drivers, or we would have to rely on the buggy closed source
> drivers that the vendors decide to throw our way, with the only
> alternative of using a slow open source RS232 interface. That is
> essentially what has happened in the realm of graphics cards.
Different chips do things in different ways. I guarantee you that my
video controller design will be quite alien to you. It'll also be one
of the most programmable you've ever encountered.
> If the open source community leads, others will follow.
If you participate in a project that produces something that I can put
into a chip, let me know.
On Tue, 26 Oct 2004, Timothy Miller wrote:
>
> pbecke wrote:
> > In general an open source video card is a great idea, however, I am a bit
> > concerned about your plans to keep the FPGA code secret. I realize that
> > your company wants to make a profit,
>
> And that is the POINT here. The question isn't whether or not we can become a
> charity and give away all of our IP. The question is whether or not it's
> possible to sell open-source-friendly products. Designing and manufacturing
> hardware is EXPENSIVE. Especially at the volumes I expect.
>
> > but in keeping with the spirit of open source, it seems that it would be a
> > good idea to not only open up the driver development, but also to open up
> > the FPGA code. The great power of open source is that it allows a developer
> > to tweak the implementation.
>
> What you're asking for is excessive. Even Stallman agrees that people should
> be able to profit from their work. Opening the source to this chip would be
> good for you and for every other company that wants to copy it, but it would
> not be good for Tech Source. Tech Source is a business with a profit motive.
> Will will not engage in something that costs us more money than it makes or
> diverts us from something more profitable.
>
> You're allowing your lofty free software ideals to get in the way of what is
> reasonable and practical. I believe in freedom, which is why I started this
> project. But make no mistake in thinking that I'm trying to waste the time
> and money of my employer.
>
I'd say a card with open source drivers and access to detailed
documentation from a company that's willing to work with the Open Source
Software community is a very big first step, and a massive improvement on
the current state of affairs. If we could just get that as a start, then I
for one would be thrilled.
> > Perhaps, rather than a single company defining the functionality with input
> > from the open source community, it makes more sense for the open source
> > community to define the standard, and then any company could work from the
> > standard created by the open source community.
>
> As I've said before, if people want to give us a design, we'll manufacture it!
>
I know very little about graphics card hardware so I have no idea if this
is interresting or not, but in case you haven't heard of Manticore I
thought I'd provide a link : http://icculus.org/manticore/
Jesper Juhl wrote:
> I'd say a card with open source drivers and access to detailed
> documentation from a company that's willing to work with the Open Source
> Software community is a very big first step, and a massive improvement on
> the current state of affairs. If we could just get that as a start, then I
> for one would be thrilled.
Well, as Alan mentioned, there are already five 3D chipsets out there
with docs going to anyone who is serious about implementing a 3D driver
for that particular piece of hardware. You need more than just
available docs and hardware.
You need...
* engineering resources to implement a complicated driver (3D h/w
drivers are complex beasts)
* a compelling design and/or [low] cost
* to avoid the problem where the h/w changes so often, the open source
driver maintainers simply cannot keep up.
Jeff
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. :)
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
On Tue, Oct 26, 2004 at 11:44:18AM -0400, Timothy Miller wrote:
>
> >In general an open source video card is a great idea, however, I am a
> >bit concerned about your plans to keep the FPGA code secret. I realize
> >that your company wants to make a profit,
>
> And that is the POINT here. The question isn't whether or not we can
> become a charity and give away all of our IP. The question is whether
> or not it's possible to sell open-source-friendly products. Designing
> and manufacturing hardware is EXPENSIVE. Especially at the volumes I
> expect.
>
No problem with this at all. Of course, those who really want
to try "open firmware" development can buy cards from you
and reprogram the FPGA with a totally different and open
firmware. They will then see how hard this is. And you
still sell the hardware - even if they succeed to some extent.
> Also do not make the mistake of believing that software is free to
> PRODUCE. If it were, then free software fans wouldn't love the GPL
> which protects their investment of time from being ripped off by greedy
> companies that would like to steal their work.
Well said.
Helge Hafting
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. :)
Helge Hafting wrote:
> On Tue, Oct 26, 2004 at 11:44:18AM -0400, Timothy Miller wrote:
>
>>>In general an open source video card is a great idea, however, I am a
>>>bit concerned about your plans to keep the FPGA code secret. I realize
>>>that your company wants to make a profit,
>>
>>And that is the POINT here. The question isn't whether or not we can
>>become a charity and give away all of our IP. The question is whether
>>or not it's possible to sell open-source-friendly products. Designing
>>and manufacturing hardware is EXPENSIVE. Especially at the volumes I
>>expect.
>>
>
> No problem with this at all. Of course, those who really want
> to try "open firmware" development can buy cards from you
> and reprogram the FPGA with a totally different and open
> firmware. They will then see how hard this is. And you
> still sell the hardware - even if they succeed to some extent.
There does appear to be some demand for variants which include things
like high-performance rendering, ray tracing, etc. I would enjoy
working with people who need this sort of thing.
It's "how can we make each other happy". You're happy with freedom in
your products, my employer is happy with profit, and I'm happy to spend
my time being a chip architect. :)
>
>
>>Also do not make the mistake of believing that software is free to
>>PRODUCE. If it were, then free software fans wouldn't love the GPL
>>which protects their investment of time from being ripped off by greedy
>>companies that would like to steal their work.
>
>
> Well said.
Thank you!
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
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
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 -- [email protected]
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
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
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.
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.
Looks like the prject suffered instant death by the responses. Apart
from Tech Source, perhaps other companies such as IBM, HP, OSDL, RedHat,
Novell, etc. could be tapped for funding the 3D side of the development,
just an idea.
Regards
Sid.
--
Sid Boyce .... Hamradio G3VBV and keen Flyer
=====LINUX ONLY USED HERE=====
On Wed, Nov 17, 2004 at 02:35:54PM +0000, Sid Boyce wrote:
> Looks like the prject suffered instant death by the responses.
It's excessively ambitious to get anywhere right now.
On Wed, Nov 17, 2004 at 02:35:54PM +0000, Sid Boyce wrote:
> Looks like the prject suffered instant death by the responses. Apart
> from Tech Source, perhaps other companies such as IBM, HP, OSDL, RedHat,
> Novell, etc. could be tapped for funding the 3D side of the development,
> just an idea.
The project is about a closed source hardware with open specs.
IMHO more interesting is open source hardware - a computer that can run Linux
exists and it's hardware is open source exists:
http://sbc.twibright.com
Cl<
--
Thanks to all free technology developers for the things they are making
available to general public. Free technology includes free software.
Sid Boyce wrote:
> Looks like the prject suffered instant death by the responses. Apart
> from Tech Source, perhaps other companies such as IBM, HP, OSDL, RedHat,
> Novell, etc. could be tapped for funding the 3D side of the development,
Instant death?
Actually, it moved to its own mailing list:
http://lists.duskglow.com/mailman/listinfo/open-graphics
Timothy Miller wrote:
> Sid Boyce wrote:
>
>> Looks like the prject suffered instant death by the responses. Apart
>> from Tech Source, perhaps other companies such as IBM, HP, OSDL,
>> RedHat, Novell, etc. could be tapped for funding the 3D side of the
>> development,
>
>
> Instant death?
>
> Actually, it moved to its own mailing list:
>
> http://lists.duskglow.com/mailman/listinfo/open-graphics
>
>
>
Thanks, I shall check there.
Regards
Sid.
--
Sid Boyce .... Hamradio G3VBV and keen Flyer
=====LINUX ONLY USED HERE=====