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? :) >>> 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... >> Translates and scales coordinates based on a rectangle in source and >> destination space. >> >>>> How many public API calls (roughly) are needed for this graphics? >>>> >>> Below is the number of drawing calls required to render the tiger. >>> >>> FillRectangle: 261 >>> FillTriangle: 6949 >> Wow, I thought about turning dfb_gfxcard_fill_triangle() into >> dfb_gfxcard_fill_triangles() >> a few days ago! > > If you mean FillTriangles(DFBTriangle *tris, int num), I already have it > in my local repo of DirectFB, but the performance improvement is not > significative. > I will test with FillTriangles(DFBPoint *vertices, int num > DFBTriangleFormation formation). > >> How many color or other changes do you have within these 6949 calls? >> >>> DrawLines: 78 >>> Blit: 261 >> Nothing else? And no Matrix or Mask? This could run well even on basic 2D >> chips :) >> > > This is the complete report: > > SetColor: 566 > SetPorterDuff: 339 > SetMatrix: 305 > SetDrawingFlags: 566 > SetBlittingFlags: 261 > SetRenderOptions: 827 > FillRectangle: 3654 > FillTriangle: 6949 > DrawLines: 78 > Blit: 261 > > However the impact of SetColor and co. is minimal, at least for my CPU > (which is an AMD64). Please check /proc/fusion/0/stat before and after one frame. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
