[cairo] What do we think about vkvg ?

Tue Jul 17 14:08:10 UTC 2018

> Would be interesting if you can get useful results.  The original code
> is posted here, fwiw:
>
>    https://github.com/bryceharrington/caskbench
>
> I can move that to https://gitlab.com/cairo if you plan to do work on
> it.
I've started with my own code, but I will not be very productive during 
the holidays.
I'll try to reuse the same tests as in caskbench, I'm not sure I will 
include skia. I will use
glfw3 for context creation and test drm/kms on linux if possible.
> I'll remark that it was notorously difficult to get reasonably
> apples-to-apples performance comparisons between cairo-gl and skia since
> there's so many idiosyncratic differences in assumptions.  The
> testsuite's handy for finding areas where performance work is needed,
> though.
>
> For instances, differences in antialiasing quality settings can have
> huge performance impact - for certain use cases.  Caching or image
> atlases can similarly have huge performance implications, that may
> suggest unnaturally large (factor of 10 or more) advantages when used by
> one lib but not the other.  Etc.
The api's being quiet the same, maybe results will be more consistent.
I'll try to make fine grained configs for tests.
> Drawings are always nice.  It might also be helpful to document your
> research and decision making processes, both for newbies reviewing your
> code, and future maintainers that may wonder why things are as they
> are.  :-)
You're right, with this new visibility on my work, documentation must
become a priority.
> I've been working on learning vulkan myself this year, but work
> situation appears to be changing a bit, and I'm unsure whether I'll be
> continuing or not; I should know better within a couple weeks either
> way.
>
> When I presented caskbench and the cairo-gles performance work, one
> concern raised that never really got resolved was a desire for state
> retention (e.g. so if you're doing animation or interactive drawing, can
> calculations from one frame be saved for reuse in subsequent frames).
> This seems important, but I'm unclear on what the architectural
> implications are, and whether it could be adequately supported within
> Cairo's current architecture or if that'd be more work than worth.
> I was interested in digging into the problem a bit more with vulkan; if
> you get a chance to experiment along these lines I'd be interested in
> hearing your findings.
I've faced the same concern. Introducing new objects to store
uploaded artifacts (on gpu) could be a solution. I've not yet explore
those possibilities.
> I did some investigation into fixed point math; Cairo uses this
> internally and I wanted to better understand the benefit, and how it
> might influence decisions about what to put on the GPU.  However, in
> playing around with it I couldn't find an advantage other than just that
> perhaps it's required by some of the rasterization algorithms.  I didn't
> see a good reason to investigate it further.
> On data types, I will mention that there has been some desire to see
> expanded range and precision of coordinates, as some users have tended
> to push the limits (usually unintentionally...)  Similarly, for color
> types there's been strong interest expressed in using deeper color
> formats than just straight RGB, mainly in support of doing proper CMYK
> with PDF generation.  Both of these would be hard to change in
> established code, and maybe easier to implement if starting fresh on a
> new graphics lib.  Indeed, if one were to go that direction there's a
> number of other things like that which are challenging to fix in Cairo
> due to stability concerns.
Float precision during color computations makes it sometimes difficult
to get coherent back and forth conversion results. On GPU, single float
is the norm, but several high end cards have good perf on double.
For normal 3d scene rendering, single float is sufficient, so middle end 
cards,
will not get optimized double rapidly I guess. (I'll recheck the market 
trends).

I've start vkvg with single floats everywhere (only 32bpp surface 
implemented),
I may try to make test with double if I implement 64bpp surfaces. I 
anticipate the
difficulty as moderate.

jp

>
>> On 02/07/18 13:01, Stefan Salewski wrote:
>>> On Sun, 2018-07-01 at 17:16 +0000, Bruyère Jean-Philippe wrote:
>>>> Intel is quiet a big company, alone I would hardly suffer
>>>> comparison.
>>>> Any help is welcome.
>>>>
>>> Have you done some basic performance tests yet?
>>>
>>> For fastuidraw it was reported that it can be 9 times faster than
>>> cairo, but I am not sure if that is the average case.
>>>
>>> I would be very interested in faster simple (lines) drawing for
>>> gtk/gnome widgets, i.e. like GTK DrawingArea.
>>>
>>> Currently CPU load is high and speed not that great, as proved by
>>>
>>> https://lists.cairographics.org/archives/cairo/2016-October/027791.html
>>>
>>> So creating CAD applications with cairo is demanding, I tried one
>>> myself some years ago:
>>>
>>> http://ssalewski.de/PetEd.html.en
>>>
>>> For that application Ruby language was the bottle neck, now I am
>>> considering porting it to a very fast compiled language like Nim, so
>>> cairo will become the bottle neck. I think it will be fast enough, but
>>> one has to restrict drawing operations to what is really necessary
>>> using RTrees and bounding boxes. Doing always a complete redraw would
>>> be much easier of course, I think CAD tools using GL directly are doing
>>>    complete redraws.
>> -- 
>> cairo mailing list
>> cairo at cairographics.org
>> https://lists.cairographics.org/mailman/listinfo/cairo