[webkit-dev] WebKit GPU rendering possibility
Yusuke SUZUKI
utatane.tea at gmail.com
Thu Nov 3 12:48:16 PDT 2016
I'm not sure it is directly helpful or not. And maybe, I think you already
know that.
But I remember that Cairo has some trace data to test the performance.
And it includes the traces on WebKit.
https://cgit.freedesktop.org/cairo-traces/
Best regards,
Yusuke Suzuki
On Thu, Nov 3, 2016 at 12:42 PM, Myles C. Maxfield <mmaxfield at apple.com>
wrote:
>
> On Nov 3, 2016, at 12:34 PM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
>
>
> 03.11.2016, 22:18, "Rogovin, Kevin" <kevin.rogovin at intel.com>:
>
> Hi,
>
> What are some good 2D UI graphics benchmarks that are cross-platform-ish?
> I'd think I need to port them to Fast UI Draw, but that is possible.
>
> I am very confident that Fast UI Draw will perform at the top by a large
> margin. The more complicated and heavier the load, the better it will do.
>
>
> I would suggest you to do prototype implementation of GraphicsContext
> (e.g. by replacing code in GraphicsContextCairo) and run those browser
> performance benchmarks. If there is substantial improvement, there will be
> community enthusiasm.
>
>
> As Konstantin says, browser-based benchmarks would be best, but I assumed
> you didn’t want to implement GraphicsContext before running benchmarks. If
> you do implement GraphicsContext in a branch of WebKit, there are a few
> browser-based performance tests which may be insightful:
>
> - CanvasMark http://www.kevs3d.co.uk/dev/canvasmark/
> - Mozilla has a list of benchmarks https://wiki.mozilla.org/Benchmarks
> - Canvas Performance Test http://www.smashcat.org/av/canvas_test/
>
> Perhaps some of these could even be ported to native code so you could get
> up and running sooner.
>
> —Myles
>
>
> -Kevin
>
> -----Original Message-----
> From: mmaxfield at apple.com [mailto:mmaxfield at apple.com
> <mmaxfield at apple.com>]
> Sent: Thursday, November 3, 2016 9:07 PM
> To: Rogovin, Kevin <kevin.rogovin at intel.com>
> Cc: Carlos Garcia Campos <carlosgc at webkit.org>;
> webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>
> It sounds like the primary focus of your work is improving performance. It
> also sounds like the only benchmark you’ve run is an artificial one that
> you constructed yourself.
>
> Given these two things, I would strongly hesitate to call our interest
> "significant community enthusiasm.”
>
> Why don’t you start by running some of the many existing graphics
> benchmarks with your library?
>
> Please correct me if my assumptions are mistaken.
>
> Thanks,
> Myles
>
> On Nov 3, 2016, at 12:50 AM, Rogovin, Kevin <kevin.rogovin at intel.com>
> wrote:
>
> Adding a new GraphicsContext is what I want to do as it seems the path of
> least pain and suffering. However, all the other things of a backend I do
> not need to do. I do not know how to add a GraphicsContext backend in terms
> of makefile magicks and configuration. I also do not know the plumbing for
> making it active. In theory, FastUIDraw's GraphicsContext will work on any
> platform that does OpenGL 3.3 or OpenGL ES 3.0. What is the plumbing to do
> this? Years ago I remember that the build configuration is what governed
> what backend was built... and I usually just piggy packed onto another...
> years ago I remember there was like an SDL style backend that did not
> require a large toolkit, just SDL.. is that still alive? where is it? I
> could piggy back the work there if it still is alive...
>
> Also, to get permission to do this work, I need significant community
> enthusiasm otherwise I will not be able to justify the large amount of work
> needed. This is another area where I need a great deal of help.
>
> Best Regards,
> -Kevin Rogovin
>
> -----Original Message-----
> From: Carlos Garcia Campos [mailto:carlosgc at webkit.org
> <carlosgc at webkit.org>]
> Sent: Thursday, November 3, 2016 9:43 AM
> To: Rogovin, Kevin <kevin.rogovin at intel.com>; Myles C. Maxfield
> <mmaxfield at apple.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>
> El jue, 03-11-2016 a las 07:35 +0000, Rogovin, Kevin escribió:
>
> Hi,
>
> The main issue of making a Cairo backend to FastUIDraw is clipping.
> Cairo tracks the clipping region in CPU and does things that are fine
> for CPU-based rendering (i.e. span based rendering) but are
> absolutely awful for GPU rendering (from my slides, one sees that GL
> backed QPainter and Cairo do much worse than CPU backed). FastUIDraw
> only supports clipIn and clipOut and pushes all the clipping work to
> the GPU with almost no CPU work. It does NOT track the clipping
> region at all. I can give more technical details how it works (and
> those details are why FastUIDraw cannot be used a backend for Cairo).
> For those interested in where the code is located for clipping in
> FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
> methods clipInRect, clipOutPath and clipInPath. Their implementations
> are very short and simple and are quite cheap on CPU.
>
>
> I see. Then I guess adding a new GraphicsContext for FastUIDraw is the
> easiest and best way to try this out in WebKit. Would it be possible to
> just add a new GraphicsContext implementation? or would you also need to
> change other parts of the graphics implementation or the GraphicsContext
> API itself?
>
> Best Regards,
> -Kevin
>
> -----Original Message-----
> From: Carlos Garcia Campos [mailto:carlosgc at webkit.org
> <carlosgc at webkit.org>]
> Sent: Thursday, November 3, 2016 9:27 AM
> To: Rogovin, Kevin <kevin.rogovin at intel.com>; Myles C. Maxfield <mmax
> field at apple.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>
> El jue, 03-11-2016 a las 06:58 +0000, Rogovin, Kevin escribió:
>
> Hi!
>
> Question answers:
> 1. Currently FastUIDraw has a backend to OpenGL 3.3 and OpenGL
> ES 3.0. One of its design goals is to make it not terribly awful to
> write a backend to different 3D API’s.
> 2. I think I was unclear in my video. I have NOT migrated ANY
> UI rendering library to use Fast UI Draw. What I have done is made a
> demo
> (painter-cells) and ported that demo to Fast UI Draw, Cairo, Qt’s
> QPainter and SKIA. The diffs between the ports is almost trivial (it
> really is just using those different rendering API’s).
>
>
> That makes me wonder, would it be possible to add a new cairo backend
> based on FastUIDraw? That would make very easy to try it out with the
> current GraphicsContext cairo backend.
>
> 3. There are a few areas:
> a. Reduce some render to offscreen buffers. When I worked with
> WebKit YEARS ago, I saw a few instances of rendering to texture that
> are unnecessary and even harm performance for GPU rendering. The
> first example was where a brush pattern with an image and/or
> gradient applied is to be drawn tiled across an area. WebKit (at
> that time) first drew a single instance of that pattern to an image,
> then drew that image tiled. For GPU renderers we can (very easily)
> just do the repeat pattern (of both original image and gradient)
> from a shader.
> Another instance happens at RenderLayer where a new GraphicsContext
> “layer” is started on a transformation that has rotation or
> perspective. For FastUIDraw, this is not necessary, though if a
> layer is transparent, then it is.
> b. In addition, FastUIDraw has an interface so that if “what”
> is
> drawn is unchanged but the “how” changes, then a caller can cache
> the “what” to send to the GPU. To be explicit, “what” to draw is
> essentially attributes and indices and those values do NOT depend on
> the state of “how” to draw. Examples of “how” to draw: current
> transformation, brush to apply, clipping applied, stroking
> parameters (including dash pattern) and blending mode. I admit that
> I am quite proud of being able to use the same attributes an indices
> even if stroking parameters (stroking width, miter limit and dash
> pattern) change. Text rendering “what” to draw does depend on what
> glyphs one wants to use. Specifically, if drawing coverage font
> glyphs, then attributes and indices values change if one wants to
> draw the glyph biffer, but for the GPU rendered glyphs they do not.
> 4. The renderer implements full 3x3 transformations. However,
> the renderer does NOT implement out-of-order transparency. For a
> GPU, a
> 3x3 transformation is cheap (naturally!). The renderer does handle,
> with a very little additional overhead changing clipping even
> between nasty rotations or perspective changes. The demo
> painter-cells deliberately pushes and does lots of nasty clipping
> and the performance impact of it on FastUIDraw is very small.
> 5. Drawing text is a right pain in the rear. Currently,
> FastUIDraw has 3 methods to draw text: coverage, distance field and
> an original GPU algorithm that I devised for another open sourced
> project years ago. Coverage is needed when glyphs are drawn small
> and hinting becomes important. The original GPU algorithm keeps
> corners sharps and does a computation in the fragment shader to
> compute a coverage value.
> Distance field is a fall back which has render quality issues
> (namely corners are rounded) but is very, very cheap.
> I want to write an additional glyph renderer that is much faster
> than the original GPU method and keeps corners sharp. This new one
> is to use the ideas found in https://github.com/Chlumsky/msdfgen but
> I have a way to make the distance field generation much, much faster
> and handle natively cubics (instead of breaking cubics into
> quadratics)
>
> For convenience, below is a list of features FastUIDraw implements:
> 1. 3x3 transformation matrix
> 2. path stroking with anti-aliasing a. dashed stroking too
> b. miter, rouned, bevel joins c. flat, square and rounded
> caps 3. path filling against an arbitrary fill rule 4.
> “brush”
> a. linear gradients
> b. two point conical gradients (I call these radial gradients)
> c.
> images
> i. nearest,
> bilinear and bicubic filtering 5. Clipping a. clipIn
> against rect or filled path (with arbitrary fill rule) b.
> clipOut against path (with arbitrary fill rule) 6. Glyph
> rendering a.
> coverage fonts b. 1-channel distance field c. curve-pair
> analytic (original algorithm) 7. all 12 Porter-Duff blend modes
>
> However, I still have work to do:
> 1. anti-alias path fills
> 2. anti-alias clipping
> 3. more glyph rendering work
> 4. some optimizations related to culling on path-fills 5.
> dash pattern adjustments from contour length as found in http
> s://www.w3.org/TR/svg-strokes/ 6. the analog of
> GraphicContext’s begin/endTransparencyLayer 7. The
> blend/combine/transfer modes of W3C that are not from Porter-Duff.
>
> At this point, I need to garner interest to be able to get time to
> work on this project at my employer. The stronger the enthusiasm I
> can get the better my chances for continuing the work.
>
>
> This looks really interesting, I think the GTK+ port could benefit
> from this if it eventually can be used as a cairo replacement.
>
> Best Regards,
> -Kevin Rogovin
>
> From: Myles C. Maxfield [mailto:mmaxfield at apple.com <mmaxfield at apple.com>
> ]
> Sent: Thursday, November 3, 2016 1:30 AM
> To: Rogovin, Kevin <kevin.rogovin at intel.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>
> Hello,
>
> This is certainly interesting work! I have a few questions about the
> approach of this renderer.
>
> 1. What API is this on top of? OpenGL? Metal? Vulkan? Raw GPU
> commands[1]?
> 2. You mention in your video that you have already migrated Cairo on
> top of your new tech. Traditionally, a web engine is divorced from a
> 2D rendering engine such as Cairo. Why can’t the ports of WebKit
> which use Cairo get this new tech without any change?
> 3. What sort of API changes do you have in mind to make
> GraphicsContext adopt?
> 4. Out of curiosity, does the renderer implement 3D transforms?
> Did
> you have to implement 3-D triangle subdivision along intersections
> (perhaps for order-independent transparency)?
> 5. Which algorithm did you choose to draw text?
>
> Historically, the WebKit team has hesitated to allow experiments in
> the OpenSource repository. Traditionally, this sort of exploratory
> work is done in a branch, and only after it has proved to be an
> improvement, the work is adopted on trunk.
>
> Thanks,
> Myles
>
> [1] https://01.org/linuxgraphics/documentation/hardware-specificati
> on
> -prms
>
> On Nov 2, 2016, at 9:35 AM, Rogovin, Kevin <kevin.rogovin at intel.com
>
>
> wrote:
>
> Hi,
>
> I was directed here by some colleagues as this is the place to post
> the following to get started on the following proposal.
>
> I have been working on an experimental 2D renderer that requires a
> GPU, the project is open sourced on github at https://github.com/01
> or g/fastuidraw. I gave a talk at the X Developers Conference this
> year which can be seen from
> https://www.x.org/wiki/Events/XDC2016/Progra
> m/
> rogovin_fast_ui_draw/ .
>
> I made a benchmark which makes heavy use of rotations and clipping
> and ported to SKIA, Qt’s QPainter and Cairo. The benchmark and its
> ports are in the git repo linked above under the branch
> with_ports_of_painter-cells. It's performance advantage of
> FastUIDraw against the other renderers was quite severe (against
> Cairo and Qt's QPainter over 9 times and against SKIA about 5 times
> faster).
>
> I would like to explore the option of using FastUIDraw to implement
> a WebCore::GraphicsContext backend for the purpose of making drawing
> faster and more efficient on Intel devices that are equipped with a
> GPU. I also think that some minor modifications to WebKit’s use of
> GraphicsContext will also give some benefits. I have worked on
> WebKit a few years ago and knew/know my way around the rendering
> code very well (atleast at that time).
>
> Looking forward to collaboration,
> -Kevin Rogovin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> --
> Regards,
> Konstantin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20161103/4de059fd/attachment.html>
More information about the webkit-dev
mailing list