is open-vg related post allowed here?
- Thread starter nobond
- Start date
Certainly.since it is "2.5D"
As described by Khronos Group:
OpenVG™ is a royalty-free, cross-platform API that provides a low-level hardware acceleration interface for vector graphics libraries such as Flash and SVG. OpenVG is targeted primarily at handheld devices that require portable acceleration of high-quality vector graphics for compelling user interfaces and text on small screen devices - while enabling hardware acceleration to provide fluidly interactive performance at very low power levels.
More information, open specification and reference implementation can be found at:
http://www.khronos.org/openvg/
OpenVG™ is a royalty-free, cross-platform API that provides a low-level hardware acceleration interface for vector graphics libraries such as Flash and SVG. OpenVG is targeted primarily at handheld devices that require portable acceleration of high-quality vector graphics for compelling user interfaces and text on small screen devices - while enabling hardware acceleration to provide fluidly interactive performance at very low power levels.
More information, open specification and reference implementation can be found at:
http://www.khronos.org/openvg/
The bane of my life
Seriously though,as jpilon posted, it's a vector graphics API that aims to give HW rendering of SVG/Flash-like graphics.
Ya, but the extreme rarity of vector graphics hardware is leading to using the 3d graphics pipeline to get any kind of hardware acceleration. Generally an openvg implementation on top of opengl, or hooked directly into the 3d graphics driver are the most common implementations next to pure software of course.
Well, that's still hardware compared to a CPU implementation... Anyway, yes, discussions of OpenVG are very welcome here of course - if possible, it'd be nice to get those going in the appropriate forum depending on what they're about though (3D Architectures & Chips one for HW implementations; 3D Technology & Algorithms for discussion of OpenVG itself and possible algorithms; 3D Programming & Tools or Handheld Technology for a programming question).
Anyway, yes, discussions of OpenVG are very welcome here of course - if possible, it'd be nice to get those going in the appropriate forum depending on what they're about though (3D Architectures & Chips one for HW implementations; 3D Technology & Algorithms for discussion of OpenVG itself and possible algorithms; 3D Programming & Tools or Handheld Technology for a programming question).yeah, biggest reason of this is the availability of plain VG HW acceleration hardware. Just two of them has been made (please, feel free correct me if my info is outdated) and the maker is same. AMD owns technology now, but the chips/tech are/were called Acceleon G10 and G12.
G10 is outdated already and was basically done as request to NEC. It's completely different design than G12 by being discrete chip designed to replace Column / Row latch unit in LCD display itself. G12 again, is IP block, which can be embedded to various SOC systems.
G10 is/was used by NEC, but I don't have any figures or knowledge how much and where G12 has been used.
Acceleon G40 also has native OpenVG part integrated, but I have always expected it to be G12.
okies, I have spoken... I'll now fade back to photography forums. see you again in 6 months.
Well, the Bitboys OpenVG IP is now known as the "AMD Z180 Vector Graphics Core" (not sure if that's the same as G12 or not), and PowerVR is now also working on an OpenVG-only HW core: http://www.mitrax.de/?cont=comment&nid=80 (I wonder if Simon was thinking of that in his comment above, or just optimizing OpenVG on SGX... hmm! )
)Well, the Bitboys OpenVG IP is now known as the "AMD Z180 Vector Graphics Core" (not sure if that's the same as G12 or not), and PowerVR is now also working on an OpenVG-only HW core: http://www.mitrax.de/?cont=comment&nid=80 (I wonder if Simon was thinking of that in his comment above, or just optimizing OpenVG on SGX... hmm!
Indeed there is some, but this means 3 different possible rendering stacks for openvg. First, purely software rendered directly to the frame-buffer or back-buffer in video memory. Second, hardware accelerated via 3d pipeline with existing 3d graphics drivers/hardware. Third, hardware accelerated with vector graphics cores which would require new drivers.
Also the fact that the 3d pipeline and vector graphics pipelines are not compatible, (e.g. line/polygon tessellation, geometry generation, rasterization etc) makes implementing openvg to have intelligent 3d/VG/SW fall-backs and re-usable code difficult.
Well, the Bitboys OpenVG IP is now known as the "AMD Z180 Vector Graphics Core" (not sure if that's the same as G12 or not), and PowerVR is now also working on an OpenVG-only HW core: http://www.mitrax.de/?cont=comment&nid=80 (I wonder if Simon was thinking of that in his comment above, or just optimizing OpenVG on SGX... hmm!
Actually, Maybe I need to refresh my knowledge a bit...
Thanks for the hint about Z180, I did few searches and came out with this: http://www.amd.com/us-en/assets/con...ets/AMD_Z180_AMD_Z460_Graphics_Fact_Sheet.pdf
According to that, It is not G12, as G12 did not handle reflections, nor shadow effects. (texturing with perspective correction was supported, though it was not excatly 3D chip.) Z180 seems more like to be G40 or something that came after both. (G34 with G12 integrated perhaps? G34 did not have shaders, while G40 was full blown 2.0)
Z460 again seems to be first child of co-operation of original ATI handheld division and ex-BB. (last things I heard before dropping out totally was that the co-operation between divisions was started very well and there was few projects going on.)
Some optimisation/algorithms for SGX and MBX, but my comment was more to do with http://www.khronos.org/files/openvg_1_0_1.pdf (see 185), but I'm trying to spend more time on 3D again(I wonder if Simon was thinking of that i... or just optimizing OpenVG on SGX... hmm!
Not that I'm aware of. AFAIK, microsoft aren't contributing members to any Khronos specification. I suppose they do have Silverlight.
arjan de lumens
Veteran
Not really. The basic primitive that is drawn in OpenVG is the "path" - a sequence of lines and curves that define a region of the desired shape. This primitive is not very similar to the kinds of primitives that you would typically send to a GPU, so OpenVG implementations that run on GPUs will typically perform a software processing pass where the "path" is converted to a form that is suitable for the GPU. This processing will typically result in one or more vertex arrays, which may or may not have index arrays associated with them.
Such vertex arrays are NOT visible to the OpenVG programmer; they're strictly an implementation detail. There are many ways to construct them, and different OpenVG implementations will likely produce very dissimilar vertex arrays for the same input path, and also choose dissimilar ways to pass the arrays to the GPU.
G12 evolved to Z160 in the new line up, Z180 is the next generation part, still VG-only. The shadows and reflections part seem to be marketing's idea on how to use blur filtering, as the hardware supports Flash filters, which Z160 didn't. OpenVG requires perspective texturing so that has been supported from the beginning. Apart from Z-buffering and some other minor details you could implement most of OpenGL ES 1.1 on OpenVG anyway
Oh no! Don't open that can of worms here...Apart from Z-buffering and some other minor details you could implement most of OpenGL ES 1.1 on OpenVG anyway
Similar threads
