Il giorno ven, 28/03/2008 alle 17.27 +0100, Denis Oliver Kropp ha
scritto:
> Claudio Ciccani wrote:
> > Il giorno gio, 27/03/2008 alle 17.01 +0100, Denis Oliver Kropp ha
> > scritto:
> >> Claudio Ciccani wrote:
> >>> Il giorno gio, 27/03/2008 alle 11.40 +0100, Denis Oliver Kropp ha
> >>> scritto:
> >>>> Guess it uses SetMatrix() and lots of SetSourceMask().
> >>> Actually I'm not using SetSourceMask().
> >>> The API specification is incomplete. For example, how should it behave
> >>> when mask size differs from source size? In the Radeon driver the mask
> >>> gets scaled, but OpenVG requires not scaling.
> >> In Water it can be chosen :)
> >>
> >> In IDirectFBSurface it's unscaled, I thought, unless you use StretchBlit().
> >>
> >> So source and mask are always pixel aligned.
> >>
> >>> Regarding SetMatrix(), the API needs to be changed. OpenVG requires
> >>> projective transformations too (3x3 matrix) and we need a way to
> >> Good to know :)
> >>
> >>> separate matrix transformation form coordinates scaling (i.e. adding a
> >> Scaling might be good to have separately. So far, in Water (again:) only
> >> the offset into the destination surface is a separate attribute.
> >>
> >> BTW, can we use any of the stream processors (?) on the Radeon with 
> >> DirectFB?
> > 
> > As far as I known, the Radeon has only one stream processor... or
> > probably I'm misunderstanding what you mean for "stream processor"...
> > are you talking about the vertex pipeline?
> 
> Not sure, I saw lots of (smaller) units somewhere. Anyhow, can multiple 
> shaders
> running in parallel be independently scheduled?
> 
> Where's the massive parallel execution for scene graph traversal (actually 
> saturation)
> with a duration proportional to the average depth of the tree? :)

AFAIK, you can upload only one vertex shader at once. 
I think parallel execution refers to the way shaders are processed
internally by the chip (i.e., by using multiple ALUs that do the
computations in parallel, just like an old IA32), but this is only a
supposition since the chip specification is closed.

> 
> >>> method to specify a scaling factor for each coordinate, something like
> >>> SetPixelZoom(16.16)).
> >> Or SetViewport( src_rect, dst_rect ) ?
> > 
> > But a SetPixelZoom() like function (with a single scale factor) requires
> > less computations if the viewport is not directly supported by the
> > hardware. 
> 
> I was just wondering about the accuracy of the fixed point scaling factor. 
> Having
> the nominator/denominator moves/limits rounding errors to the final 
> calculation,
> but maybe it could become too many divisions...

However SetMatrix already uses fixed point representation.
The difference is that, by using a single scale factor, the error
threshold is between [-1/(1<<16), +1/(1<<16)], which is acceptable given
that a pixel component ranges between 0-255.

-- 
Claudio Ciccani
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://directfb.org


_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev

Reply via email to