Re: Logging Library-GSOC

[Werner LEMBERG]

> During the exploration phase, I have seen several libraries and
> according to me *dlg* is best suited for the requirements:

OK, then let's try this library!

> In previous mails, Armin suggested to move some of the FreeType's
> logging functionality to the external logger but according to my
> analysis, none of the external logging libraries that I have
> explored exactly matches the logging architecture of FreeType
> (i.e. logging based on debug level of components and debug levels of
> trace calls).  According to me, this is not possible with dlg
> library [...]

This is not a problem at all.


Werner

Re: intel compiler support interest?

[Werner LEMBERG]

> I think it makes sense to first disable the vectorized code path to
> get the source to build properly with the Intel compiler.  A second
> patch could try to optimize the code using Intel intrinsics on x86
> and x86_64, this would probably be portable to more compilers.  Not
> sure this is worth it though.

I've applied the original patch now.  Further improvements are
welcomed :-)


Werner

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

 > *Ok. This means that square-distance might need [...]*

I agree that 181 is enough in a typical SDF grid, and anyway
if we generate a 8bit SDF bitmap it won't be able to represent
more than 127 signed values.
And I also agree that closer distances are more important than
distant distances if the user is simple using the SDF from simple
reconstruction. But, if we want to generate something like this:
( https://www.ronja-tutorials.com/2018/11/17/2d-sdf-combination.html )
then I think both types of distances are equally important.
By truncating do you mean normalizing in a range of [0, 181] or clamping
the values? In both cases I don't see any problem.

> *As I said above, the distant grid points contain [...]*

So, basically we subdivide the curve into small lines and use them to
generate the SDF, so as to make the process faster.
I will try to implement this tomorrow and see how it looks. And if it
works here is what I propose:

First for the squared distances. While generating SDF, I am using a `spread'
parameter which defines the max distance which will be present in the final
output (basically the output will have a range [-spread, spread]). So, In
case
the spread is small (< 181), we can use the squared distance to generate
the SDF.
And in case it is greater than 181 we simply use `FT_Vector_Length'.

Second if the subdivision method works and is both faster and doesn't
differ much from
the method I am currently using, then we will use it to generate SDF if the
glyph size
is small, because I think if the glyph size is large then there might be
too many
subdivisions and it will make the whole process slow. And if the glyph if
large then
we will use the current method. (of course this will depend if the
subdivision method
doesn't differ much from the actual SDF)

So we use separate implementations depending on the spread and the size of
the glyph.
How does it sound?

>
*Looks alright, including modules.mk . Have you checked
if it compiles? *

Thanks for checking it out. Yes, it does compile,
Anuj

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Alexei Podtelezhnikov]

On Thu, Jun 18, 2020 at 8:01 AM Anuj Verma  wrote:
>
> Hello Alexei,
>
> First, about using squared distances instead of `FT_Vector_Length', it
> is much faster to use squared distance. I tested it with a linear case and
> it comes around 0.114 microseconds, which is almost 65% faster than the
> original time of ~0.32 microsecond. It isn't 90% faster because there is
> one vector normalization which can't be avoided.
> Moving on, I think it's not possible to store squared distance  using 16.16
> fixed point because it can store a maximum of 32668 which is a square of ~181,
> so if the glyph is more than that, then there is a problem of overflow. If I
> am allowed to use decimal representation instead of binary fixed-point for
> internal computation then It might be possible.

Ok. This means that square-distance might need to be represented as
26.6, for example, but this also means that short distances will lose
accuracy. Hence the question, which distances contain more important
information? I would argue that it is the short distances to proximal
grid points because those contain the information on how to thread the
boundary through the grid. The distant grid points contain very little
additional information as they might even be closer to a different
segment. So, 16.16 is still better and truncating at 181 should not be
a problem. Also 181 is far considering a typical distance field grid
size. Is there a way you can test if truncated distance fields work
(TSDF)?

>
> > So each curve is sampled a large number of times [...]
>
> I'm not sure I understand it correctly, here is what I understood:
> You want to divide the curve in a large number of flat segments. Then
> calculate the distance of the pixels very near to the curve (the pixels
> will have a unique projection on the flat segments and no two will be
> the same). Now using these pixels (which have a unique projection),
> calculate the distances of the rest of the pixels/grid. Is that correct?

As I said above, the distant grid points contain very little
additional information or even "belong" to a different segment. All
grid points should be calculated and truncated alike. The idea is to
use a coarse *slightly* jagged representation of all curves and grid
points. FreeType smooth renderer walks along the outline (using
FT_Outline_Decompose) and generates small linear segments along the
curves.

>
> And finally I have a small request, I have added a new `sdf' module in
> my branch 
> (https://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=anuj-distance-field)
> Can you verify if everything is correct?

Looks alright, including modules.mk. Have you checked if it compiles?

Best,
Alexei

Re: intel compiler support interest?

[David Turner]

Le dim. 14 juin 2020 à 07:06, Stephen McDowell  a
écrit :

> Hi Alexei,
>
> It's only __builtin_shuffle that's a problem.  I'm a simd novice at best
> hehe.  I played around for a good long while trying to find an equivalent
> shuffle intrinsic, for now I was just working off of the GCC examples for
> __builtin_shuffle: https://godbolt.org/z/gPiZQL
>
> It's technically successful, but with a big caveat that in order for me to
> try and translate this to the freetype code I need help understanding how
> the mask={0,1,1,3} gets transformed into 212 in emitted `pshufd xmm0, xmm0,
> 212` from the gcc __builtin_shuffle call.  Look for `#define MAGIC` in the
> example, anything stick out as to how that value is created?  If we know
> how that is done, I can begin looking into shorts (v82 type used in
> freetype code) rather than int in the example code.
>
> 212 decimal is 0xD4 hex, which is binary for 11010100, or 11_01_01_00 when
separating 2-bit values, which corresponds to the {0, 1, 1, 3} mask in
little-endian order.
For more details, see
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#cats=Swizzle=shuffle_epi32=5144
which explains how the second argument to __mm_shuffle_epi32 is interpreted
by the CPU.


> I'm game to push a little further on it, but to be honest adding in
> conditional trickery for intel will make this code more confusing.  It's
> going to have to convert between v82 and one of the _mXXXi vector types and
> shuffle splitting (can't call _mm_shuffle* with v82 type).  In other words,
> while intel users may not get the fastest possible code, previously none of
> this code was vectorized anyway so it's kind of a wash.  That said, I
> totally understand the desire to vectorize it if we can :)
>
> I think it makes sense to first disable the vectorized code path to get
the source to build properly with the Intel compiler.
A second patch could try to optimize the code using Intel intrinsics on x86
and x86_64, this would probably be portable to more compilers. Not sure
this is worth it though.

>
>
> Let me know your thoughts!
>
> -Stephen
>
>
> On Sat, Jun 13, 2020 at 2:36 PM Alexei Podtelezhnikov 
> wrote:
>
>> On Fri, Jun 12, 2020 at 8:07 AM Stephen McDowell 
>> wrote:
>> > I help maintain the spack package manager when I can, currently users
>> with intel compilers cannot build / install any version after 2.7.1 due to
>> the usage of __builtin_shuffle (for some reason Intel still doesn't support
>> this).
>>
>> Is there by any chance an equivalent intrinsic?
>>
>> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#cats=Bit%20Manipulation
>> What about __builtin_clz that FreeType also uses?
>>
>

Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

First, about using squared distances instead of `FT_Vector_Length', it
is much faster to use squared distance. I tested it with linear case and
it comes around 0.114 microseconds, which is almost 65% faster than the
original time of ~0.32 microsecond. It isn't 90% faster because there is
one vector normalization which can't be avoided.
Moving on, I think it's not possible to store squared distance  using 16.16
fixed point because it can store a maximum of 32668 which is a square of
~181,
so if the glyph is more than that, then there is a problem of overflow. If I
am allowed to use decimal representation instead of binary fixed-point for
internal computation then It might be possible.

> *So each curve is sampled a large number of times [...]*

I'm not sure I understand it correctly, here is what I understood:
You want to divide the curve in a large number of flat segments. Then
calculate the distance of the pixels very near to the curve (the pixels
will have a unique projection on the flat segments and no two will be
the same). Now using these pixels (which have a unique projection),
calculate the distances of the rest of the pixels/grid. Is that correct?

And finally I have a small request, I have added a new `sdf' module in
my branch (
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=anuj-distance-field
)
Can you verify if everything is correct?

Thanks,
Anuj

Re: Logging Library-GSOC

[Priyesh kumar]

Hi guys,

During the exploration phase, I have seen several libraries and according
to me *dlg* is best suited for the requirements:
1. Printing logs to file
2. Dynamically change log levels and redirect logs to the desired output
through the use of callback functions
3. Windows support
Other than dlg, I think zlog and log4c are also powerful logging libraries
but they are not properly supported on windows...

Also, I have some concerns regarding Armin's previous mails:-
In previous mails, Armin suggested to move some of the FreeType's logging
functionality to the external logger but according to my analysis, none of
the external logging libraries that I have explored exactly matches the
logging architecture of FreeType (i.e. logging based on debug level of
components and debug levels of trace calls). According to me, this is not
possible with dlg library but we could leverage the zlog or log4c for this
requirement and we might have to make some changes in FreeType's current
logging architecture. I am not sure if this will suit to Freetype clients.
Requesting guidance from your side.
Please correct me if I am not understanding this requirement correctly :-)

Thanks,
Priyesh

On Wed, Jun 17, 2020 at 2:18 PM Priyesh kumar 
wrote:

> Hi Werner,
> > *I think you did a great job with your exploration.*
>
> Thanks...
>
> > *Do you think that** you already can suggest a library that fits best?*
>
> I think I need some time to analyze the already explored logging libraries
> (mainly dlg and log4c) w.r.t to FreeType, and how to leverage these within
> FreeType...
> I will update you on this by this weekend...
>
> Thanks,
> Priyesh
>
>
> On Wed, Jun 17, 2020 at 12:54 PM Werner LEMBERG  wrote:
>
>>
>> > After going through log4c, I don't think I have any more options to
>> > look onto...  If you guys know any more logging libraries, please
>> > let me know...
>>
>> I think you did a great job with your exploration.  Do you think that
>> you already can suggest a library that fits best?
>>
>>
>> Werner
>>
>