Re: [E-devel] Blend2D - a gfx framework with dynamic pipelines support

[Vinícius dos Santos Oliveira]

2017-12-06 4:56 GMT-03:00 Carsten Haitzler :

> [...]


That was very informative. Thank you.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Blend2D - a gfx framework with dynamic pipelines support

[Carsten Haitzler]

On Tue, 5 Dec 2017 22:50:21 -0300 Vinícius dos Santos Oliveira
 said:

> 2017-12-03 10:19 GMT-03:00 Carsten Haitzler :
> 
> > also i dislike the idea of a jit. i would prefer something like
> > "pre-compile
> > all permutations into special case functions then runtime call the
> > right/matching one".
> >
> 
> I'm not familiar implementing gfx engines, but with my (small) background
> on compilers and the giant notes page[1], I assume there are optimizations
> that can't just be implemented otherwise.
> 
> The API is like:
> 
> ctx.draw_something1();
> ctx.draw_something2();
> ctx.draw_something3();
> ctx.end(); //< here the pipeline is compiled

generally (at least for us) there is very little to be gained optimizing the
"between something1/2/3". jits are good for this when you have realy small
operations like cpu commands (a = b + 1 for example) and having a continuation
of this where the same data stays in the same register etc. is a good idea and
going to yield good speedups.

for our graphics needs we generally do large batch operations like "do
operation X with param a=x, b=y, c=z from rectangle X to rectangle Y" and X and
Y rectangles are large regions of pixels (100's, 1000's or millions of them).
trying to optimize for tiny operations on single pixels is a long tail of work
that on average is going to yield very little in real life.

this leads to the ability to pre-compile these operations. most of the time for
params like a=0 you can special case 0, and 255 (or 1.0) and skip some muls or
turn the op into a NOP entirely depending on what you are doing, but for all
other values the generic math has to be done and you can do it with regular cpu
(sometimes with some tricks up your sleeve to do simd-like ops with a regular
cpu op as long as you don't need saturation math), or do some assembly version
to do it.

> In this API, the gfx engine can take info on cross-function information. If
> draw_something3 completely hides draw_something2, one call can be
> completely removed. It's actually boring, because you have to recompile the
> whole pipeline every value changed, but the plans to support shaders will
> change the situation[2][3].
> 
> There are drawbacks too. Evas already do interesting things and I just
> don't know if this blend2d would actually be helpful. Evas is pretty damn
> fast. And blend2d is whole CPU side, no GPU (but I still think it's
> interesting because Bézier curves).

sure. in some ways a jit is good. but pre-compiling is more generic and
portable. but in the end the lack of architecture support for major
architectures we support kind of puts it on the veto list. :( if it just
generated some c src for all permutations and then we compiled it in... we'd at
least have a portable one (without specialized assembly for mmx/sse, neon
etc.). but it doesn't do this. :(. it does do mmx/sse etc. in the jit .. but
only for intel and that is a problem.

yes - they make good points about alignment cleanups for simd asm ops due to
alignment needed and this expands library size. that is true. but it's not THAT
onerous. they also make a good point of eliminating tmp buffers. we actually
rarely use tmp buffers ourselves and have our operations already pre-coded, but
we could do better. i was mulling doing a new sw renderer with tiles so yes -
we'd have "temp buffers" but they'd all fit well inside l1 cache and that would
be a big win when blending/operating over the same region multiple times as the
destination at least will stay in cache for fast read-modify-write performance
for blends. to do all of this i was mulling making a code generator to generate
all the operations and functions from templates and so on... :) i have for a
long time been mulling the idea of "texture compression" (s3tc, etc1/2
etc.style) even for software. allow more interesting pixel formats that reduce
memory bandwidth needs significantly with constant storage cost. a sw engine
can even be super smart and switch storage format tile by tile depending on
what works best for that tile. often regions of an image are "empty" and thus
there is no need to even store any pixels for it - just a flag of "this is
transparent" or "this is a single ARGB color" and then when rendering these
regions can optimize their src fetches significantly... and save memory to boot.

> Oh, and thanks for replying to my email. It was just a different point of
> view, just as I wanted to have.
> 
> [1] https://blend2d.com/notes.html
> [2] https://blend2d.com/roadmap.html

yes. they say they want to support arm. but still there's ppc, mips, ... and
more... :) there is no way i'd want to maintain 2 rendering engine paths in the
long run and short term should be very short. i'd want a lot more architectures
already done and finished and supported before even considering...

> [3] https://gist.github.com/vinipsmaker/08349a74566df4c4a9bf82624c13a33b
> 
> -- 
> Vinícius dos Santos Oliveira
> 

Re: [E-devel] Blend2D - a gfx framework with dynamic pipelines support

[Vinícius dos Santos Oliveira]

2017-12-03 10:19 GMT-03:00 Carsten Haitzler :

> also i dislike the idea of a jit. i would prefer something like
> "pre-compile
> all permutations into special case functions then runtime call the
> right/matching one".
>

I'm not familiar implementing gfx engines, but with my (small) background
on compilers and the giant notes page[1], I assume there are optimizations
that can't just be implemented otherwise.

The API is like:

ctx.draw_something1();
ctx.draw_something2();
ctx.draw_something3();
ctx.end(); //< here the pipeline is compiled

In this API, the gfx engine can take info on cross-function information. If
draw_something3 completely hides draw_something2, one call can be
completely removed. It's actually boring, because you have to recompile the
whole pipeline every value changed, but the plans to support shaders will
change the situation[2][3].

There are drawbacks too. Evas already do interesting things and I just
don't know if this blend2d would actually be helpful. Evas is pretty damn
fast. And blend2d is whole CPU side, no GPU (but I still think it's
interesting because Bézier curves).

Oh, and thanks for replying to my email. It was just a different point of
view, just as I wanted to have.

[1] https://blend2d.com/notes.html
[2] https://blend2d.com/roadmap.html
[3] https://gist.github.com/vinipsmaker/08349a74566df4c4a9bf82624c13a33b

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Blend2D - a gfx framework with dynamic pipelines support

[Carsten Haitzler]

On Sun, 3 Dec 2017 01:23:22 -0300 Vinícius dos Santos Oliveira
 said:

> Hi all,
> 
> I'd like to ask what is your opinion on this library[1].
> 
> It's a library where you call all the draw operations that comprise the
> drawing pipeline, and, when you call `context_end`, the pipeline is
> compiled (yep, JIT). Somehow exciting because it allows very interesting
> optimizations.
> 
> But it's also boring, because you have to recompile the whole pipeline
> every time some value changes (i.e. probably every frame if you're writing
> a game).
> 
> But there is also plans to support a shader language (with a working
> experimental code for a useless math functions language). With this support
> added, you could compile the rendering pipeline only once and evaluate it
> for every frame.
> 
> The thing I like is support for Bézier curves. It's like OpenGL done for 2D
> rendering. The API seems a lot like cairo, so it's mostly transparent
> (except for the shaders).
> 
> Maybe EFL could add a backend forked from SDL2 using this library to
> generate the screen bits. Or maybe there is not enough info flowing the
> higher layers to the lower layers to make this idea actually useful.
> 
> Maybe some of these ideas could be stolen by the EFL project.
> 
> I'd like to hear opinion from you guys about this project. You guys are
> experienced with 2d gfx code and I'd love to hear anything you guys have to
> say about this project.
> 
> [1] https://blend2d.com/

Requiring c++ means then lower end systems will require libstd++ which will
bloat our our requirements. no? from that view, i don't like it much.

also i dislike the idea of a jit. i would prefer something like "pre-compile
all permutations into special case functions then runtime call the
right/matching one". the built-in jit is going to cause architecture support
issues for us on various platforms where we do work (maybe not with optimized
ASM but we work). a quick peruse of b2dpipe doesn't tell me what architectures
are or are not supported easily... a quick look seems it needs "../asmjit" in a
parent dir. this leads me to: https://github.com/asmjit/asmjit which says
"x86/x64" only in the arch support. and that right off the bat would veto this
as something we'd depend on. we'd need at least these architectures supported
for me to begin considering:

armv7,v8
x86,x64
ppc
mips

... pretty much what luajit supports.

i actually had been mulling writing such an "offline" code generator that
generated c (with snippets of asm/asm intrinsics or macros for simd), then did
like above.

if blend2d was more like this... then it'd be worth looking at even if it had a
c++ api.

> -- 
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Blend2D - a gfx framework with dynamic pipelines support

[Vinícius dos Santos Oliveira]

Hi all,

I'd like to ask what is your opinion on this library[1].

It's a library where you call all the draw operations that comprise the
drawing pipeline, and, when you call `context_end`, the pipeline is
compiled (yep, JIT). Somehow exciting because it allows very interesting
optimizations.

But it's also boring, because you have to recompile the whole pipeline
every time some value changes (i.e. probably every frame if you're writing
a game).

But there is also plans to support a shader language (with a working
experimental code for a useless math functions language). With this support
added, you could compile the rendering pipeline only once and evaluate it
for every frame.

The thing I like is support for Bézier curves. It's like OpenGL done for 2D
rendering. The API seems a lot like cairo, so it's mostly transparent
(except for the shaders).

Maybe EFL could add a backend forked from SDL2 using this library to
generate the screen bits. Or maybe there is not enough info flowing the
higher layers to the lower layers to make this idea actually useful.

Maybe some of these ideas could be stolen by the EFL project.

I'd like to hear opinion from you guys about this project. You guys are
experienced with 2d gfx code and I'd love to hear anything you guys have to
say about this project.

[1] https://blend2d.com/

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel