- Inkscape Devel - Inkscape Mailman

i think i've got it.
by NASA Jeff 13 Nov '20

13 Nov '20

It looks like as I described, sorting the vertices and walking the inside edges. Except overlapping boundaries seem to follow a z-order based on the order in which the vertex appears on the path. So, it's basically a bucket fill with some level of z-order based on vertex creation order.

1 0

memory requirements and GPU CPU performance on older systems.
by NASA Jeff 13 Nov '20

13 Nov '20

A full 32bit 4k screen is 31mb There are approximately 70 full 4k screens in 2GB, which is about the memory of an ancient PC or graphics card. My PC performs unbuffered memory writes at 10GB/s according to a benchmark I just ran, and read performance is over 13GB/s That means my PC can write the full 2GB in 1/5 of a second and my PC is currently under a lot of load, I have loads of stuff open. More details including GPU to CPU and CPU to GPU memory performance can be found here: http://www.bealto.com/gpu-benchmarks_mem.html The devices listed are relatively old, a PCI Express V2 16 BUS is listed with a performance of 8GB/s It would take 1/25 of a second to transfer the full 2GB at theoretical maximum performance. That means you could sustain a transfer rate of 201MB at a speed of 40 frames per second, or about 6 and a half full 4k screens or 25 full-HD screens 40 times a second. A modern PCI Express bus can sustain 126 GB/s Having a vector with 32bit x and y coordinates for every pixel of a 4k screen shouldn't pose a performance issue. Old PCI Express 2 systems can achieve that at 120 fps. Masks and stencils won't be the whole screen and even if they were older systems without 4k screens (you need a modern graphics card to be able to operate one) could have roughly 350 full-HD screen stencils before filling up 2GB of RAM. So, the memory requirement of using masks and stencils and then texturing and filtering on the GPU shouldn't be an issue. Well, that's all the theory out of the way, and it certainly seems viable. Just to see if any of it works in practice.

1 0

whilst the user twiddles their fingers.
by NASA Jeff 13 Nov '20

13 Nov '20

Creating masks for filling may be slow, but it could just initially be done for clipped areas and then background areas can be calculated during user idle time, so they can be cashed so that they don't have to be recalculated if something on a layer above them changes.

1 0

worst case scenario
by NASA Jeff 13 Nov '20

13 Nov '20

worst-case scenario is that i have to load everything into bitmaps and do the calculations using shaders using the colour of the bit map for the coefficient values. That's basically what OpenCL does in the background for you, but it should work on machines that don't support OpenCL assuming they can operate on enough bitmaps at once to provide the number of coefficients needed.

1 0

i may do a little experiment sooner rather than later.
by NASA Jeff 13 Nov '20

13 Nov '20

What I'll do for feasibility is create some arrays for triangular strips for every pixel of the screen, perform the basic spline calculations on them combined with normal calculations so the triangular strip has a width in the direction of the normal of either side and see what the performance is like. I have quite a new PC with a fast GPU, my older PC will have a different performance profile I expect.

1 0

more on rendering usin g the GPU.
by NASA Jeff 13 Nov '20

13 Nov '20

it does if it's architectured right, see for instance how the Pathfinder library does it it doesn't if it needs back-and-forth stuff with cpu and gpu involved (anyway, 2am, going to bed) oliverthered 1:37 AM ok, I'll run a test soon of calculating all the line points an entire SVG file in one go to see how that performs. but you're correct, unless there's some way you can work with the line points when rendering an image on the GPU you have to shuttle the calculations between the GPU and CPU to do the drawing. that then leaves the question of how often do you actually have to recalculate all the drawing points. you could calculate the drawing points as a triangular strip maybe. Then it's just one trip to the GPU and back to calculate them and then you change the data type into vertices and send them off to the GPU again to be rendered. you should then be able to manipulate the line directly on the GPU you just can't break it or delete it without having to go from GPU to CPU again. Filling is a lot harder on any kind of scale. Here's one example of SVG filling on the GPU: http://matthieu.besson.pagesperso-orange.fr/2010.01.15/SVG Rendering using OpenGL.html matthieu.besson.pagesperso-orange.fr SVG Rendering using OpenGL line drawing is however fixed filling not dynamic filling, you know the width you don't have to do bounds checking for the fill boundary. and it's still possible to do that on the CPU as a mask and then have the GPU render the fill texture and style etc.. an array of drawing points need be no bigger than a few full screen 32bit depth textures to fill the whole screen with lines. If you can create an array of triangles at point separation using the tangents of the spline you should then be able to use a shader to do all the stroke drawing, feeding it the array of triangles you've calculated. anyhow, i'll have to do some benchmarking, but in theory at least everything apart from creating a mask for filling can be handled by the GPU. So to do all of that you need to know the length of the lines so you can precalculate the size of the array needed to hold the triangular stipes at one pixel spacing..

1 0

looks like opencl should be able to do it.
by NASA Jeff 13 Nov '20

13 Nov '20

So, long as you don't need to increase or change the number of elements in the vectors, basically no memory allocation, it looks like bulk vector operations are easy with OpenCL... here's an example where a vector id added: https://github.com/rsnemmen/OpenCL-examples/tree/master/sum_array But there's a wide variety of other possible functions... I'll have to port the path rendering into OpenCL code and see how well it performs when I give it a vector containing all the path data in an entire SVG file in one go. That should at least performance benchmark it and provide a proof of concept.

1 0

I just looked at Krita and they say...
by NASA Jeff 13 Nov '20

13 Nov '20

"Selecting this checkbox will enable the OpenGL / ANGLE canvas drawing mode. With a decent graphics card this should give faster feedback on brushes and tools. Also the canvas operations like Rotate, Zoom and Pan should be considerably faster." I think it should be possible to do way better than that assuming the bus isn't too much of a bottleneck because you have to pull any points that are calculated back on to the CPU so that they can be drawn on the canvas and send out to the GPU again for layering.

1 0

can we render vector graphics using the GPU to process everything in mass parallel.
by NASA Jeff 13 Nov '20

13 Nov '20

I got told off for this monologue, so I hope it's a good one... I didn't manage to draw a conclusion but I did come up with a way of testing if the vector drawing calculations can be offloaded to the GPU which would in theory make them blazingly fast. It would also be of interest to other open-source graphics projects, so I may get Intouch with the Krita guys https://krita.org/en/download/krita-desktop/ as I know they have some GPU optimizations and see what mileage they got out of it. At the very least SIMD on the CPU is capable of performing those four multiplications required for a spline in one cycle, it's just a case of what performance gains can be made rendering the other embroilment beyond basic line drawing. --------------------------- I've got my Béziers down to this... a * p[0] + b * p[2] + c * p[4] + d * p[6] etc.. The points are fixed for the segments and a,b,c,d are a function of the fraction t. that should vectorize nicely and do all four mul operations in one cycle. The number of fractions in t is really dependent on the length of the curve.. Which makes the performance bottleneck populating the arrays to do the vectorized calculations. It's always possible to have arrays with prefill numbers of fractional steps. That would prevent the over head of the CPU having to go out of catch to fetch data in an informally populated memory block... but just having a pre-allocated array to stick all the fractions in should overcome that. So, the only question remaining, assuming fractioned aren't precalculated. is what is the performance difference between populating a preallocated array of fractions and then doing one massive vector operation on the lot in batch, vs calculating the fractions on the fly and just doing a little vector operation. It should be possible to hold all the calculations of the fractions in the loop inside the registers, which should make on the fly faster than populating a vector as there're no worries about the CPU having to fetch data from odd places. GCC is supposed to auto vectorize but I think I'll have a crack at using the extensions to see what difference there is between GCC's auto vectorization and optimal irker203 12:52 AM [inkscape] Marc Jeanmougin pushed new commit to master: https://gitlab.com/inkscape/inkscape/-/compare/69dc1688...d2b75904 gitlab.com 69dc1688...d2b75904 · Inkscape / inkscape Inkscape vector image editor oliverthered 12:52 AM Looks like OpenCL should give the best bulk operation solution. I think it's only 32bit precision, that just means quadrupling up the data and scaling the fractional component into nice 32bit chunks. a standard loop would be quicker than calculating all the points in bulk into memory, but that's assuming you only want to draw a pixel line with no other operations performed upon it. if you have all the points of the line calculated and held in memory on the GPU you can then perform a load of other operations upon them in bulk like anti-aliasing. It is a shame the GPU can't just take the values stored in what is effectively a texture used for bulk parallel processing and turn them into pixel co-ordinates to draw on another texture or it would be possible to calculate and draw all the vector points on the GPU. If you calculate many lines all simultaneously on the GPU the overhead of transferring memory over the bus should be well mitigated against. ``` Anyhow, that was some interesting research. When i get around to taking a look at Inkscape code I should be able to frame some idea of just how much of the vector drawing operations can be calculated in bulk on the GPU. Certainly, all the operations requiring tangents and normals should be achievable given an array of line fractions and the spline control points. SVG drawing is complex so there's a lot of overhead in the actual drawing process compared to line drawing so holding an array of points to be drawn in memory may actually make performance sense.

1 0

The notes I used for todays meeting
by NASA Jeff 12 Nov '20

12 Nov '20

It's a bit marketing bumph laddered after I got some work and sponsorship based on the design work I posted to Inkscape's mailing list. The project in which my design was spotted was inkscape for which I not only designed the feature google was extremely interested in but reworked undo/redo and scripting to support macros, real time ECMA scripting as well as their current batch python scripting and additionally added the versatility to support older plugins that are currently unusable without being ported to Inkscape new python scripting API, although I also schemed a proposal for automated porting. On-top of ECMA scripting I designed a modular and secure API system that is extensible and reusable by other 'open source' projects. This enables the development of real-time drawing tool and utilities (such as real-time shape recognition, recording of macros based on user interaction, click-and lock user interface integration during design (the UI becomes integrated with the application API via wisywig script instead of hard-coding), SVG Animation using CSS, SIML (deprecated) or JavaScript, and finally interactive SVG for development of graphic rich web applications and games (think sopped up flash replacement). A radical, high performance, caching system was also designed, high-performance matrix operations for groups of a vector and bitmap objects, such as rotation, scaling, shearing and translation, along with implementing some industry standards that were missing such as deciles black boxed from Google Chrome. Graphics fidelity was also addressed and fidelity/performance trade-offs discussed with some key design pointers such as moving objects require less fidelity and feature scaling should be uniform possibly even dropping the current non-uniform scaling as even an optional feature. Backtracing methods for 'random' animation JavaScript/CSS allowing for wisywig editing and the ability to control and pre-empt the animation timeline were also worked into the project, this also enables high-performance animation through the ability to pre-empt caching and transformations. Another feature where I deltered and improved with existing API and radically extended the AI to enable clean matching of both straight and curved segments, more or less regardless of the angle that they are drawn with, though fixed angle snapping was implemented by default to make for easier drafting)

1 0