lkml.org 
[lkml]   [2004]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?


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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:1.164 / U:1.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site