Assessment of the difficulty in porting CPU architecture for tigerVNC

[yuxuan wang]

 Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting. In fact, the tool may have an average estimate of various architecture porting efforts.My focus is on the overall workload and difficulty of transplantation in the past and future,even if a project has already been ported.As part of my dataset, I have collected the **tigerVNC** project. **I would like to gather community opinions to support my assessment. I appreciate your help and response!** Based on scanning tools, the porting complexity is determined to be  simple, with a small amount of code related to the CPU architecture in the project.  Is this assessment accurate?Do you have any opinions on personnel allocation and consumption time？ I look forward to your help and response.

[Pierre Ossman]

I don't think we have anything architecture specific at all in TigerVNC.
We do rely on a number of libraries that have architecture-specific code
for acceleration, though. E.g. libjpeg-turbo, nettle, ffmpeg.

Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[DRC]

On 11/20/23 3:06 AM, 'Pierre Ossman' via TigerVNC Developer Discussion
wrote:

> On 11/20/23 08:06, yuxuan wang wrote:
>>   Hello everyone! I am working on implementing a tool to assess the
>> complexity of CPU architecture porting. It primarily focuses on RISC-V
>> architecture porting. In fact, the tool may have an average estimate of
>> various architecture porting efforts.My focus is on the overall workload
>> and difficulty of transplantation in the past and future,even if a
>> project
>> has already been ported.As part of my dataset, I have collected the
>> **tigerVNC** project. **I would like to gather community opinions to
>> support my assessment. I appreciate your help and response!** Based on
>> scanning tools, the porting complexity is determined to be simple,
>> with a
>> small amount of code related to the CPU architecture in the project.  Is
>> this assessment accurate?Do you have any opinions on personnel
>> allocation
>> and consumption time？ I look forward to your help and response.
>>
>
> I don't think we have anything architecture specific at all in
> TigerVNC. We do rely on a number of libraries that have
> architecture-specific code for acceleration, though. E.g.
> libjpeg-turbo, nettle, ffmpeg.

There is an open issue for adding RISC-V SIMD extensions to libjpeg-turbo:

https://github.com/libjpeg-turbo/libjpeg-turbo/issues/620

As the sole maintainer and principal developer of libjpeg-turbo, I have
developed SIMD extensions from scratch as well as integrated SIMD
extensions developed by others.  The PowerPC AltiVec extensions, for
example, were developed from scratch by me and took hundreds of hours. 
The Intel AVX2 extensions were contributed but implemented somewhat
problematically, so it still took hundreds of hours to clean up,
optimize, test (which involves benchmarking each algorithm in isolation
to ensure that it contributes a significant speedup to the overall
implementation), document, and integrate the contributed code.  The
intrinsics implementation of the Arm Neon extensions was contributed and
well implemented, but it still took hundreds of hours to isolate the
algorithms that regressed in performance due to GCC's sub-optimal Neon
intrinsics implementation and use the legacy GAS implementations of
those algorithms when building with GCC. (Thankfully, GCC 12 and later
no longer suffers from that problem, so there is hope for eventually
eliminating the legacy GAS implementations.)

The story arc of major new features in libjpeg-turbo has traditionally
been that a company is only willing to fund a fixed amount of
implementation/integration labor, unexpected problems arise, and I have
to eat the overage or solicit outside funding to cover it.  Assembly
code is hard, and unforeseen problems always arise when implementing a
new set of SIMD extensions.  I am thus reluctant to implement or
integrate a full set of SIMD extensions for a new architecture unless I
am working closely with an organization that is willing to fund 100% of
my implementation and/or integration labor, as well as my maintenance
labor, over the long term.  I don't earn a living wage developing
libjpeg-turbo.  VirtualGL and TurboVNC account for most of my (still
meager) income and are the reason I am able to develop open source
software independently and full-time.  Thus, I can't speculate on new
libjpeg-turbo features ("speculate" = develop something for free in
order to attract more users and potentially more funded development.) 
Even if I were able to speculate on new libjpeg-turbo features, I could
only speculate on features that are in high demand, and so far, all of
the demand for RISC-V SIMD extensions has come from companies that have
a vested interested in the RISC-V architecture.  I am academically
interested in RISC-V, but at the moment, there hasn't been enough
interest in it from the libjpeg-turbo community to produce the funding
needed to implement RISC-V SIMD extensions or even integrate someone
else's implementation.  I cannot justify using our very limited General
Fund for such efforts, since it is always exhausted by more mundane
things like security fixes.