Re: [webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi, Since EFL supports cairo, we compared EFL-TyGL and EFL-Cairo * Canvas-performance: 1.7 times faster with TyGL (21 tests run correctly from 23 tests) Site: http://flashcanvas.net/examples/dl.dropbox.com/u/1865210/mindcat/canvas_perf.html * Asteroids-benchmark: 3.4 times faster with TyGL (4 tests run correctly from 6 tests) Site: http://www.kevs3d.co.uk/dev/asteroidsbench/ Regards, Zoltan How does TyGL perform compared to the other rasterizers? What benchmarks do you use to guide the performance work? On 11/12/14, 11:12 PM, Zoltan Herczeg wrote: Hi All, We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher. The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way. Key features: Batching pipeline: GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls. Automatic shader generator: TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU. Trapezoid based path rendering: TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze more performance out of it. No software fallback: The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available. TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project. Regards, U-Szeged's web browser team. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
This is quite interesting, but I have a bunch of questions regarding this. What makes the 2D drawing code WebKit-specific? Is it possible to package up the rendering code into a self-contained standalone library? Regarding text, do you have a strategy for instancing geometry or using a glyph atlas? Did you implement the Loop Blinn path algorithm? Did you experiment with attempting to re-order independent drawing commands to achieve high GPU occupancy? Are you measuring power use in addition to time-based performance? It sounds like OpenGL is doing the drawing itself; I would imagine there are many many draw calls per webpage. Does the OpenGL driver introduce significant overhead? Are you thinking of publishing your findings? I would be very interested to read about design decisions you encountered along the way. Thanks, Myles On Nov 13, 2014, at 12:40 AM, Benjamin Poulain benja...@webkit.org wrote: How does TyGL perform compared to the other rasterizers? What benchmarks do you use to guide the performance work? On 11/12/14, 11:12 PM, Zoltan Herczeg wrote: Hi All, We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher. The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way. Key features: Batching pipeline: GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls. Automatic shader generator: TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU. Trapezoid based path rendering: TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze more performance out of it. No software fallback: The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available. TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project. Regards, U-Szeged's web browser team. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi, we encountered some unexpected issues with Cairo-EFL on our board. When it works again, we will do some measurement. Regards, Zoltan How does TyGL perform compared to the other rasterizers? What benchmarks do you use to guide the performance work? On 11/12/14, 11:12 PM, Zoltan Herczeg wrote: Hi All, We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher. The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way. Key features: Batching pipeline: GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls. Automatic shader generator: TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU. Trapezoid based path rendering: TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze more performance out of it. No software fallback: The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available. TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project. Regards, U-Szeged's web browser team. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi, What makes the 2D drawing code WebKit-specific? Is it possible to package up the rendering code into a self-contained standalone library? It is possible to make it a standalone library in the future. But we are working on WebKit, we want to accelerate WebKit graphics, and WebKit has a nice low-level infrastructure we don't want to duplicate. At least for now. Regarding text, do you have a strategy for instancing geometry or using a glyph atlas? Did you implement the Loop Blinn path algorithm? For fonts, we use glyph atlas at the moment. We don't use Loop-Blinn, since it has some issues with self-intersecting paths. Instead we use fast trapezoid partitioning. To achieve high anti-aliasing quality, we need to draw the path onto an internal texture first, which is slow because of texture fbo binding. However, if multiple paths are drawn (which is a frequent case), we draw multiple paths onto a single texture, so no fbo rebinding is needed. We hope Pixel Local Storage extension will eliminate the need of temporary images at all. It provides the freedom we need for a 2D engine allowing since all temporary data can be kept on GPU. Did you experiment with attempting to re-order independent drawing commands to achieve high GPU occupancy? We know overdraw is costly, and we want to use opacity information to reorder / drop unnecessary draws in the future. But this wasn't the biggest issue we had so far. My personal experience is that GPUs are very fast, after the fbo rebinding cost is paid. I did not see much difference of drawing a hundred or a thousand triangles (at least not a linear increment), except if the shader is very costly. Copy data between CPU and GPU is also very costly (and glReadPixels runtime is not predictable), so it is very important to keep data on textures. For example, we use inter-process texture sharing to transmit Cooridnated Graphics updates between the UI and Web process. Are you measuring power use in addition to time-based performance? Not yet. It sounds like OpenGL is doing the drawing itself; I would imagine there are many many draw calls per webpage. Does the OpenGL driver introduce significant overhead? Yes, that is why we use batching. And we still want to improve that, since we see significant improvement with clever batching. Are you thinking of publishing your findings? I would be very interested to read about design decisions you encountered along the way. Well, it is true we found many surprising issues and had to redesign core algorithms several times. Tile based embedded GPUs has unique strengths and weaknesses. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU
Hi All, We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher. The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations. 2D graphics is traditionally software-based however, and 2D APIs are interfaces to these CPU-based algorithms. WebKit GraphicsContext API is no different, so the key challenge of our project was and is producing the expected output in a GPU friendly way. Key features: Batching pipeline: GPU provides the highest performance when a large number of triangles are drawn with a single draw command without any OpenGL state changes. The GraphicsContext API in WebKit provides draw operations for single shapes however, which can result frequent state changes if implemented naively. TyGL was designed to group these commands to reduce the number of draw calls. Automatic shader generator: TyGL can generate complex shaders from multiple shader fragments, which allows efficient batching but it also takes care to make them fit into the shader cache of the GPU. Trapezoid based path rendering: TyGL uses trapezoid-based tesselation of shapes and the GPU renders them with high anti-aliasing quality. We are continuously improving this part of the engine and look forward to make use of new GPU capabilities (like Pixel Local Storage) to squeeze more performance out of it. No software fallback: The whole engine is optimized for GPU without legacy software fallback. Hence we don't need to sacrifice optimizations for compatibility. There are enough software based 2D libraries which can be used when GPU is not available. TyGL is already capable of rendering many web-sites correctly, but some features have not been implemented yet. We continue this work and we are open to contributions from the community. Contact to us if you want more information about the project. Regards, U-Szeged's web browser team. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
