On 8/22/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
Timothy Miller wrote:
> On 8/22/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
>
>>> We can use the drawing engine to do hardware scaling,
>>
>> Well then it wouldn't be hardware scaling, would it?
>
> Are you saying the drawing engine isn't hardware?
No, but if you are using a program to run a piece of hardware then you
are using software.
A hardware scan converter is all hardware (six 8 bit (but only 8 bits
out) multipliers, three adders some counters, comparator, modulo &
subtraction, and two 1-x functions. Or, if there are only certain
conversions allowed, much of this could be ROMed.
What, exactly, are you saying you're going to do with these
multipliers, adders, etc? What are you trying to scale here? I'm
really confused by your argument.
>>> and there will be colourspace conversion.
>>
>> We should have that in hardware. The method from the MS site can
>> be implemented with 12 8x8 (some 8x9) bit integer multipliers and a
>> bunch of adders (22 bits or so).
>
> We think we can do it with even less hardware.
Yes, I stated the worst case.
Didn't mention that we could probably pipeline it somehow to require
only three multipliers.
I had suggested to Lance (probably privately) that we could clock the
YUV/RGB converter at a higher rate than the host interface, so it
could do the math in multiple cycles without a performance hit.
That's not technically pipelining, but it would save hardware.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
