I'm still trying to digest all the feedback I've been getting. It's
overwhelming and gratifying, and I want to offer my gratitude for all
the discussion and ideas.
It's been pointed out that some of this discussion may be getting
off-topic for LKML. My addition to that is that soon, it will get very
specialized in graphics math, and it would be best to move to a list
where people actually talk about this on a regular basis.
To that end, I'd appreciate it people could point me to some other
appropriate mailing lists. Not just the names, but URL's to the FAQ's
which explain exactly how to subscribe, please.
Also, I'm thinking of starting my own yahoo groups list specifically for
this chip. Is that a good idea?
Next, I'm getting lots of ideas from people. Some of them are core to
the product, and some of them would be nice for follow-on products. For
instance, dual-video would not be on the first model released. However,
it is important that analog output always have crisp rise and fall times
and be free of noise in order to maximize display quality.
The reprogramability of the FPGA has many advantages, but
reprogramability is not its primary purpose. The primary reason to use
an FPGA is to minimize NRE for manufacturing. However, as a result,
users will be able to download updates. Additionally, those who are
dedicated enough to reprogram it completely will find the necessary
documentation to do so. Finally, it is my desire that we would release
the source code to the FPGA for obsoleted products, however, it's too
early to make promises.
Ok, now on to some design stuff:
The picture I have in my head at this time expands on the idea of the
setup engine seen in most GPU's. What I'm thinking is that the setup
engine will be general-purpose-ish CPU with special vector and matrix
instructions. This way, the transformation stage will occur in
"software" executed by a specialized processor. Additionally, the
lighting phase might be done here as well.
The setup engine would produce triangle parameters which are fed to a
rasterizer which does Gouraud shading and texture-mapping. That feeds
pixels into something that handles antialiasing and alpha blending, etc.
The advantages are:
- The community can customize the setup engine as they please, just by
writing code.
- This also includes the 2D emulation
- Anything "missing" can be emulated.
The disadvantages are:
- Triangle rate limited by speed of processor
- T&L is serialized, rather than being parallelized in dedicated hardware
- Phong shading and bump mapping may be impossible or too slow
It's been a while since I read about phong shading and bump mapping. As
I understand it, some of the lighting phase is pushed into the
rasterizer. With gouraud shading, colors are interpolated between the
virtexes. With phong shading, the surface normals are interpolated
across the triangle, and that's used to compute lighting. Bump mapping
is like phong shading where the normals are specified in a bitmap.
What I don't know is how important bump-mapping and phong shading are.
> It's been pointed out that some of this discussion may be getting
> off-topic for LKML. My addition to that is that soon, it will get
> very specialized in graphics math, and it would be best to move to a
> list where people actually talk about this on a regular basis.
>
> To that end, I'd appreciate it people could point me to some other
> appropriate mailing lists. Not just the names, but URL's to the FAQ's
> which explain exactly how to subscribe, please.
Something like this?
http://www.opencores.org/forums.cgi/video/
Timothy Miller wrote:
> Also, I'm thinking of starting my own yahoo groups list specifically for
> this chip. Is that a good idea?
In theory it's useful; in reality at you'll have to balance what's
public and what's not, and it's easy to allow yourself to get bogged
down into "digesting", so much so that the "doing" is put off.
My only request is that you (a) make the graphics interface as simple
and high level as feasible and (b) you publish the hardware interface
specification as soon as possible, so that driver work can occur in
parallel.
> Next, I'm getting lots of ideas from people. Some of them are core to
> the product, and some of them would be nice for follow-on products. For
> instance, dual-video would not be on the first model released. However,
> it is important that analog output always have crisp rise and fall times
> and be free of noise in order to maximize display quality.
Once you have a core design, it's easier to dicker about specific
features. I would put this stuff on the "worry about it later" list.
> The reprogramability of the FPGA has many advantages, but
> reprogramability is not its primary purpose. The primary reason to use
> an FPGA is to minimize NRE for manufacturing. However, as a result,
> users will be able to download updates. Additionally, those who are
Will the capability to apply these updates be included with the base card?
Will users need to purchase additional "update FPGA" hardware to do the
reprogramming?
> Ok, now on to some design stuff:
>
> The picture I have in my head at this time expands on the idea of the
> setup engine seen in most GPU's. What I'm thinking is that the setup
> engine will be general-purpose-ish CPU with special vector and matrix
> instructions. This way, the transformation stage will occur in
> "software" executed by a specialized processor. Additionally, the
> lighting phase might be done here as well.
>
> The setup engine would produce triangle parameters which are fed to a
> rasterizer which does Gouraud shading and texture-mapping. That feeds
> pixels into something that handles antialiasing and alpha blending, etc.
>
> The advantages are:
>
> - The community can customize the setup engine as they please, just by
> writing code.
> - This also includes the 2D emulation
> - Anything "missing" can be emulated.
>
> The disadvantages are:
>
> - Triangle rate limited by speed of processor
> - T&L is serialized, rather than being parallelized in dedicated hardware
> - Phong shading and bump mapping may be impossible or too slow
Well, I certainly like it :)
I think that a more generic approach allows you to recognize performance
bottlenecks, and update the IP core to support instructions specific to
(say) triangles.
Random closing notes:
* data movement will be an everpresent issue
* in graphics you really have a number of data types (16-bit float,
etc.) that are specific to graphics. Supporting these natively should
be quite helpful, if not an already-obvious prerequisite
Jeff
Jeff Garzik wrote:
> Timothy Miller wrote:
>
>> Also, I'm thinking of starting my own yahoo groups list specifically
>> for this chip. Is that a good idea?
>
>
> In theory it's useful; in reality at you'll have to balance what's
> public and what's not, and it's easy to allow yourself to get bogged
> down into "digesting", so much so that the "doing" is put off.
Right. I was just discussing this with the CEO, and he pointed out that
I would get bogged down with too much online discussion. At FIRST, I
might be able to handle an open list, but pretty quickly, I'd have to
create an invite-only list where a select group who reads the other list
would digest things for me.
Yeah, if I'm going to design a large chunk of the chip and write a large
chunk of the software, I can't spend all day reading a mailing list. :)
>
> My only request is that you (a) make the graphics interface as simple
> and high level as feasible and (b) you publish the hardware interface
> specification as soon as possible, so that driver work can occur in
> parallel.
Yes, and what I need to do is find the right developers to talk to so
that I can given them interfaces that they actually NEED, because right
now, I'm just guessing.
>
>
>> Next, I'm getting lots of ideas from people. Some of them are core to
>> the product, and some of them would be nice for follow-on products.
>> For instance, dual-video would not be on the first model released.
>> However, it is important that analog output always have crisp rise and
>> fall times and be free of noise in order to maximize display quality.
>
>
> Once you have a core design, it's easier to dicker about specific
> features. I would put this stuff on the "worry about it later" list.
Definately. There's loads of features that are NICE, but not useful to
most people. I need to make the lowest common demoninator first.
>
>> The reprogramability of the FPGA has many advantages, but
>> reprogramability is not its primary purpose. The primary reason to
>> use an FPGA is to minimize NRE for manufacturing. However, as a
>> result, users will be able to download updates. Additionally, those
>> who are
>
>
> Will the capability to apply these updates be included with the base card?
> Will users need to purchase additional "update FPGA" hardware to do the
> reprogramming?
My intention is to include a bit of logic in the FPGA which can be used
to reprogram the prom. You would then cycle power to get the FPGA to
load the new code. Only if it gets corrupted would you have to solder
on a header and reprogram it another way.
Also, if someone decides to reprogram it completely, and they haven't
included a host interface and prom programmer in their design, then,
well, they're on their own. :)
>
>> Ok, now on to some design stuff:
>>
>> The picture I have in my head at this time expands on the idea of the
>> setup engine seen in most GPU's. What I'm thinking is that the setup
>> engine will be general-purpose-ish CPU with special vector and matrix
>> instructions. This way, the transformation stage will occur in
>> "software" executed by a specialized processor. Additionally, the
>> lighting phase might be done here as well.
>>
>> The setup engine would produce triangle parameters which are fed to a
>> rasterizer which does Gouraud shading and texture-mapping. That feeds
>> pixels into something that handles antialiasing and alpha blending, etc.
>>
>> The advantages are:
>>
>> - The community can customize the setup engine as they please, just by
>> writing code.
>> - This also includes the 2D emulation
>> - Anything "missing" can be emulated.
>>
>> The disadvantages are:
>>
>> - Triangle rate limited by speed of processor
>> - T&L is serialized, rather than being parallelized in dedicated hardware
>> - Phong shading and bump mapping may be impossible or too slow
>
>
> Well, I certainly like it :)
>
> I think that a more generic approach allows you to recognize performance
> bottlenecks, and update the IP core to support instructions specific to
> (say) triangles.
>
> Random closing notes:
>
> * data movement will be an everpresent issue
>
> * in graphics you really have a number of data types (16-bit float,
> etc.) that are specific to graphics. Supporting these natively should
> be quite helpful, if not an already-obvious prerequisite
Yeah, for the transformation phase, you need 32-bit floating point.
After that, you can switch to 16.16 fixed point and get perfect results.
On Monday 25 October 2004 18:45, Timothy Miller wrote:
> My intention is to include a bit of logic in the FPGA which can be used
> to reprogram the prom. You would then cycle power to get the FPGA to
> load the new code.
Power cycle the whole machine, or software-reset the card?
Regards,
Daniel
On Monday 25 October 2004 11:54, Timothy Miller wrote:
> The reprogramability of the FPGA has many advantages, but
> reprogramability is not its primary purpose.
But it might turn out to be a reason for it turning into a geek trophy, if the
price is not enormously higher than closed-spec cards. You could for
example, program real-time sound effects processing into the FPGA and output
the samples through a standard sound card.
The enthusiast market is a big market these days.
> The picture I have in my head at this time expands on the idea of the
> setup engine seen in most GPU's. What I'm thinking is that the setup
> engine will be general-purpose-ish CPU with special vector and matrix
> instructions. This way, the transformation stage will occur in
> "software" executed by a specialized processor. Additionally, the
> lighting phase might be done here as well.
>
> The setup engine would produce triangle parameters which are fed to a
> rasterizer which does Gouraud shading and texture-mapping. That feeds
> pixels into something that handles antialiasing and alpha blending, etc.
I hope you're planning to have a divider available to the rasterizer for
perspective interpolation, particularly of textures.
Regards,
Daniel
On Wed, 27 Oct 2004, Daniel Phillips wrote:
> On Monday 25 October 2004 18:45, Timothy Miller wrote:
>> My intention is to include a bit of logic in the FPGA which can be used
>> to reprogram the prom. You would then cycle power to get the FPGA to
>> load the new code.
>
> Power cycle the whole machine, or software-reset the card?
>
> Regards,
>
> Daniel
The FPGA requires a physical reset-pin toggle to load new
bits into the gate-array. This could be software-toggled,
but that would require at least one external gate. This
is because the power-reset needs to reset the chip before
its bits are loaded plus some pin, after loading, needs to
be an output to its reset pin also. Therefore, you need
the external gate that is always present.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached and reviewed by John Ashcroft.
98.36% of all statistics are fiction.
linux-os wrote:
> On Wed, 27 Oct 2004, Daniel Phillips wrote:
>
>> On Monday 25 October 2004 18:45, Timothy Miller wrote:
>>
>>> My intention is to include a bit of logic in the FPGA which can be used
>>> to reprogram the prom. You would then cycle power to get the FPGA to
>>> load the new code.
>>
>>
>> Power cycle the whole machine, or software-reset the card?
>>
>> Regards,
>>
>> Daniel
>
>
> The FPGA requires a physical reset-pin toggle to load new
> bits into the gate-array. This could be software-toggled,
> but that would require at least one external gate. This
> is because the power-reset needs to reset the chip before
> its bits are loaded plus some pin, after loading, needs to
> be an output to its reset pin also. Therefore, you need
> the external gate that is always present.
Generally speaking, more chips == bad. If reprogramming the FPGA were a
regular event, I'd see the point, but I hope that MOST users would NEVER
have to reprogram it.
Daniel Phillips wrote:
> On Monday 25 October 2004 18:45, Timothy Miller wrote:
>
>>My intention is to include a bit of logic in the FPGA which can be used
>>to reprogram the prom. You would then cycle power to get the FPGA to
>>load the new code.
>
>
> Power cycle the whole machine, or software-reset the card?
I think you'll have to power-cycle the whole machine.
1) You have to get the FPGA's loader logic to reload the bitstream.
While there are external signals to get the FPGA to reload, there may be
a chicken&egg problem with getting soft logic in the FPGA to tell the
FPGA to reload.
2) When you have reloaded the FPGA, registers are in an unknown state.
One important thing that is lost if the PCI config space info. That
would have to be restored by software.
Is it impossible to soft-reset it? Maybe not. But so much is lost and
broken in the process that it may be highly impractical.
Nevertheless, if there's a way to do it, and the community wants to
develop it, I'm all in favor.
Daniel Phillips wrote:
> On Monday 25 October 2004 11:54, Timothy Miller wrote:
>
>>The reprogramability of the FPGA has many advantages, but
>>reprogramability is not its primary purpose.
>
>
> But it might turn out to be a reason for it turning into a geek trophy, if the
> price is not enormously higher than closed-spec cards. You could for
> example, program real-time sound effects processing into the FPGA and output
> the samples through a standard sound card.
>
> The enthusiast market is a big market these days.
>
>
>>The picture I have in my head at this time expands on the idea of the
>>setup engine seen in most GPU's. What I'm thinking is that the setup
>>engine will be general-purpose-ish CPU with special vector and matrix
>>instructions. This way, the transformation stage will occur in
>>"software" executed by a specialized processor. Additionally, the
>>lighting phase might be done here as well.
>>
>>The setup engine would produce triangle parameters which are fed to a
>>rasterizer which does Gouraud shading and texture-mapping. That feeds
>>pixels into something that handles antialiasing and alpha blending, etc.
>
>
> I hope you're planning to have a divider available to the rasterizer for
> perspective interpolation, particularly of textures.
My plans are not quite that specific at this time. For instance, I'm
not entirely sure, yet, how perspective correction is done.