Hi, I'm going to present the talk from book court to tricks in upgrading the Raspberry Pi
Graphic Start.
I would like to at the beginning thanks to the organisers for making possible this year the
Graphic The Prime, we are back again.
Well, I'm Chema Casanova, people know me by this name.
Also my real name is Chosemaria Casanova.
I'm an open source developer at Gallion, the Graphic Sting.
I've been collaborating with the Mesa Community since almost power more than nine years
contributing to the interior driver at the beginning and last, I don't know, five six
years working on the broad control drivers for the Raspberry Pi Foundation.
And I'm also one of the founders of the Egalia in the South San Juan.
So if anybody's interesting about how to create a company working on free open source,
you can ask questions to me.
So what are we going to talk about?
It has been two years since last time we presented it.
And recently we have launched the new version of the operatic system that runs in the Raspberry Pi
devices.
They imagine that usually people tend to use it.
And it's the moment when we are getting the updates to the users.
So we are going to present what sense in that we are going to do a small hardware overview
to understand what we are going to focus.
It's mainly on the work on the graphics in the Mesa side and the kernel side.
I will focus while the more important changes that is related to performance.
We have improved in some benchmarks, the performance of the driver.
So while Raspberry Pi is a segmented system that usually are used by the users.
When we land some new feature of a new Mesa version,
it's the moment we receive the feedback from users.
Because power users usually like to have the last version of the drivers,
the last version of the camera, and tend to get updated.
So we should unfair in that case.
This was the previous version.
They took one.
You can see the desktop.
It has been almost the same since the previous version is on both sides.
It contains, but under the hood, there have been a lot of changes.
We were using materials compositor.
In both sides we started having the first using well and by default.
But in Booker we launched the desktop using Wi-Fi.
That and we went make it used by default for every users.
After one year, more or less we changed the laptop you see.
Because there were several uses in the older generation of the hardware.
Firstly, pi1 and 3 have some problems because how the GPU minus the memory.
So it was better to use software rendering for the compositor.
Because if you run out of memory and run in the composition, it crashed.
But it doesn't happen if you're doing the software rendering.
But applications now can run hardware accelerated in the desktop.
And we make an update in October 2024, including a new release on NASA.
So now the desktop is almost the same.
We had used in LWC as we agreed it in the previous cycle.
And there are some upgrades related to, we have a new.
This was a request from users to improve the control center application.
It was to have a reset together.
How do you change the resolution of the screen?
How do you set up when you have the different outputs?
There are some improvements on the operative system.
How we manage the desktop.
That is easier to come from a light.
You must do a desktop image.
It's the other way around.
It's just installing some packets and removing that.
In the past we were quite tight to move from one of the versions of the image to the other.
That is for free.
Start with a headless display.
Moving to the desktop one is easy.
The path was installing several packets and modifying several files that were already in the image.
So, well, my presentation is going to focus all the best mass of them.
And the analysis and the features that are enabled are going to be about the display.
Almost all the features are available in the Raspberry Pi for the generation also.
So, one, two, three.
I'm going to touch the mass them because they are quite stable and we haven't updated the drivers to mass.
It's that solving some issues that came from pervasive mass.
The prototype was launched with the previous version of Google once was launched in 2003.
Well, this is the graphic stuff for Raspberry Pi.
We have the first generations that are using in the kernel driver is the BC4 model under DRAM.
And the message driver is called BCDN.
It has support for OpenGL.
It really is 2.0.
When we get to the new generation of Raspberry Pi 4 and 5, in the kernel side, the driver is still BC4.
But now it doesn't handle the render.
The rendering is by DRAM is 100 in the BCDN kernel model.
And in the case of the user space drivers, we have BCDN that is the OpenGLES OpenGL driver.
And we have now a board driver that is BCDB.
So, well, what sense?
Well, mainly we are maintaining the same version of OpenGL from Google to electricity.
But we have implemented a lot of instances.
There are several ones related to supporting whether option for death clamping.
A lot of time was investing in proven things to manage to get better performance for the users.
So now we have timer queries so you can check the time it has to launch a draw.
Even there is has issues in the case of Tyler because if you get the time between two draws, you can have.
You could be split in the ad job that we were going to be together.
So, but in Sanchez is really useful.
The next thing we have been working also was making the implementation of texture barriers.
That was a big performance improvement because we realized that driver was doing test drive by default.
And it was not needed.
So, December, I am being less conservative about how to handle the rates of the textures.
Imply that as a big performance in case that with it was not needed.
And one of the main features that we were working during this cycle was the implementation of dual social landing.
That is not supported by the hardware.
So, it is a kind of emulated but we are taking advantage of that.
We have a lot of emulators that to implement the sound of the effects that they are doing.
And we take advantage of that also because one of the requirements of OpenGL 3.1 was supporting render targets with do not 16 bits.
And that was not supported by the hardware.
So, with this we managed to implement that and we are more 3.1 OpenGL desktop conformers.
We only have one thing pending to solve that conformers on this.
And while another world was also related to sound requests from people using web GPU with hardware.
That is improved the robustness because it was running after the application and just set in shaders.
And the running that in a browser is a good place to put some incorrect access to a buffer and modify things that you are not especially.
But browsers used to have robustness of requirement to support that.
And another interesting feature was the framework buffer fits that allows you to get in your shader.
The data from the frame buffer that I use that instead of taking and use a sample to get information from the text to that you have time to the frame buffer.
And while there were also some shaders to group operation that we already implemented.
Well, on the Vulcan size, the big change really was that now we are currently discussing Vulcan 1.3 that is conformant.
It is conformant since 2024, but it is now supposed to reduce it because of the time life of when the best I was updating in the previous cycle.
It was just a couple of commits before.
So, within a day to the moment.
So, well, the more important of having a new core feature is that it allows us to avoid the check of I have that extension enable.
So, you assume that everything is already available.
It is implementing with a two-class to implement dynamic renderings and synchronizations.
API operations, the standard dynamic runs also.
And some improvement that are usually this maintenance extension that we have a lot of them that mix several improvements for the.
We already implemented 24 extensions in this complex cycle.
I including all of them to me because there are only three since the version that we are currently using in book work.
So, well, ready to dynamic state.
The same for death control.
So, in this case, we are taking advantage of some some cases that some stations that are already implemented by other drivers.
That they are happening for us because there are general call for some of these ones where.
Actually, these are developed by Indonesia's multidisciplinary support.
A lot of bands of the Windows system integration extension that are already part of the.
Mesa infrastructure.
And different extensions that are related to well access to.
The storage operations.
The accessibility the visual that was already interesting for for us.
And in order to get in the timing that the word.
Developed for Bob and call what I was participating on them.
And well, the other thing that users are going to notice in some cases is the.
If they are interesting run investments.
GFS events is going to pass faster nowadays.
Generative more frames.
I'm going to show some of the more interesting improvements that we have in.
The period from Bungor to two tricks and run on the Raspberry Pi five.
So, this have the.
The different.
Demos that has guest events.
And this is the in the blue we have the original at book or running the benchmark.
Jala was the day that we did in the middle of the cycle in October.
And in the red.
Red gram one is the.
The.
The green person that we have already intrigued see.
So we see that this policy.
Now the performance improving.
Some of the benchmarks in the.
But Manhattan was more than an increase of more than 200%.
That is good.
I go to show.
The video of this is not.
Days is was a.
We did.
60% of the final.
A number of the government works.
I have been my kids in Wa'ah.
So these are the.
Yeah, and we have got.
I have the year, the 들어 thing.
Yes we have.
Uh 그.
Uh, we.
예 Yeah, uh, trying to.
So we need.
We need this content, when people pressman.
We know that the people.
days, we'll see each of are in.
All superdaunts.
the performance increase now we are even a little bit better in May.
But what is it's hard when you get the low-handing roof,
low-handy protein in performance to get better on this.
So well, most of the optimizations need to be focused on that we are currently
at a tile buses render in our case.
We need a lot of performance investment on improving the compiler,
but we get a round of three, four percent of performance improvement in this case.
But most of the performance we got was an avoid in the load
and store operations from the tile, because every time that you are, for example,
I have a job with multiple draw calls.
And because I'm starting a reason, I need to flash it and create
for the same frame buffer, another job, and plus it.
And I'm sending it to this GPU.
For the first one, I need to load every tile and store every tile.
And the same for the second one.
If I can merge all of them in the same job, I'm avoiding them,
one load and one store.
And this is happening.
For example, you can force a driver to make every little call,
you flash and it's really, really slow.
And you see that the most of the time,
it's not just running the driver.
It's just loading, I'm unloading.
Because you put two protocols together, and it's the same time,
then one, a little bit more.
What were the main improvements?
The first one was reducing the number of your flashes.
We have some, as I commented, when we implemented texture barrier.
There were, we were too conservative,
flashing jobs.
That were using previous use buffers up, or textures.
The second one was a lot of compiler optimization,
reducing maybe 10% of the instructions.
At the end, we are waiting in this demo,
around 2.5 of performance improvement in execution.
The other one was related to sorting some,
enabling the early-fermented testing,
in the case of this corporation.
By default, the driver was completely disabling early-fermented.
But even the case that you are in your series,
doesn't update the default or extensive,
you can enable that.
So you need to check that condition,
and enable this optimization that the hardware can do,
and just avoid doing the rendering for the pictures
that are behind the recommended buffer.
The last one was 11% in average,
but it's 60% in the case of Manhattan.
That is, avoid lost some stores
in the case of your draw calls,
have the same resturization.
This is usually happening when you have transfer feedback.
In that case, you are usually only interested,
in the case of executing the geometry states.
So if you remove completely the resturization,
because the application points to that,
you are saving a lot of time.
In the case of Manhattan,
they are losing a lot of transfer feedback,
only without resturization.
We can see the different points I was commented
because it implies,
and we can see that in some benchmark,
the performance is huge,
because that's something that the event is not doing,
and in other cases,
well, it doesn't affect,
because they are not using discounts,
for example, or they are using transfer feedback in the same way.
So we are seeing that, in other cases,
although we have seen here,
200% in some demos,
when we run the general traces that we already have,
that are not part of the benchmark,
we are seeing like 10% of performance improvement
for the general case.
We already did some instrumentization
to make a possible to ramp effect,
that is,
honestly, to know where you are losing the time of your GPU,
when you are waiting for fences,
and know that this CPU is stored,
because you are still waiting for the jobs
we've been rendering in the GPU,
so that helps a lot,
and to understand,
was the problem in your application,
so this is running on the facility,
and the other part that we are growing
than the improvements,
which showcases this last year in the Mavader room,
it was the superpaces support.
Our hardware from Raspberry Pi 4 and 5
has support for the memory management unit,
of big pages that there are 64 kilobytes
and superpaces.
There are one megabyte,
this has some implications,
because you have one megabyte,
and using four pages,
there are a lot of interesting memory management,
but you need,
and in that case,
you need to use the cache for that memory,
and using for example superpaces,
you are only getting one pointer to the physical address,
and all of them,
you are saving the cache and makes things faster.
We are using transparent GPU pages for this,
for the implementation of the kernel,
and with that,
we have a lot of benefits in some particular case,
and in our case,
we are getting at 1% running the sensors,
but in the case of some emulators,
I remember we showcases last year
the sample PlayStation games running in emulator,
and you see that it's from not being able to play the game,
to just being able to play the game,
because there are a lot of resources.
That's all,
summary,
we now they are having a better test of,
because we have an stable running with that user,
compositor,
and it's working quite fine.
There are some investors to do the data about it,
about here.
The mayor upgrades,
was the having pull can 1.3 available to the user,
not building Mesa source code.
That is also nice,
we have a lot of different extensions that we can,
already used as developers for OpenGL and Vulcan,
and in the cases of the performance,
we identify several interesting points that provide
a huge performance jam.
There were a lot of things,
but I didn't include anything that was under the 3%
but there are other things that make things faster also.
For example,
the kernel improvements that we did for superpages,
and in particular cases are really nice to have.
That's all, thank you very much.
I hope you have some questions.
Thank you.
This might be a few questions,
but maybe because I haven't talked to Mesa since 2020,
and in Nokia,
we implemented a body allocated for anything smaller than 4K,
so that smaller allocations,
or not waste loss,
based on a lot of time,
and we say 10% performance on the power of the art.
Yes, it was commented that he was in Nokia times,
they were implementing an allocator to manage the small,
tiny chunks.
There's small tiny chunks of memory,
instead of spending the paste size for each of them,
they were like doing so publication for that,
and then stand up,
yes,
of the,
yet that improved a 10% performance.
No, Mesa is not doing that for you.
No,
this,
this is just being an option for example,
when you are creating,
I imagine,
in some cases,
we are creating a command list,
but distributed to the GPU.
You can put probably more information there,
to only do one submission.
For example,
put in the uniforms there at the end of the buffer,
and there are a lot of optimization that could improve that.
The only thing we are doing mainly is,
we have been buffer up,
cash,
in order to allocate one buffer,
and you were used to avoid the overhead of calling the kernel,
this is the main,
the optimization of the sales.
Yes, that,
that,
you remember the cash from the obvious,
you see that there is a performance,
you say, well, this could,
do you have an issue,
maybe is the,
never it is,
but you see the performance drop there.
Are you using the level 5 source of ideas for optimization,
or is it distributed?
We are not using the level 5 for,
the question is,
are we using the level 5 for new optimizations?
Not in particular,
the level 5,
but we are,
you saw the following is the development of the command framework,
for example,
it is a new,
a new input that is doing some optimization,
we saw the,
certain,
see,
we can apply then,
and we have a true list of things to check to,
if they are both,
for example,
last month,
there was,
I don't remember,
was a law-winning that was taking advantage of,
you see,
the,
24 operations.
And we implemented that,
and we were getting,
in some of the events,
like,
a 2% improvement.
So, you are,
also always seeing what all the drivers are doing,
where they are,
or they're in,
in the compiler,
different,
or just checking if,
can move in some things,
makes things better,
because,
in some cases,
are you seeing,
lower is that,
where is the,
the beginning,
and now,
nobody is using that.
Hmm.
Can you speak to,
or maybe explain why,
the script,
do you think it's not for both yet?
Why?
I think,
does dynamic connecting
of arrays of the script,
or one of the things?
Yes.
The question is,
why do we,
don't we have the script,
or indexing implemented?
I think that,
we need to work,
work how the script of
Sarmana's currently in the driver,
no,
so that implies,
no,
my colleague,
I love to ask a comment,
well,
for this,
it was maybe we need to implement that,
but then we managed to do it that yet.
It's something that we are,
interesting,
for example,
we are,
currently working on dynamic array indexing,
right,
that is requested for WebGL,
because a lot of people are interesting
in playing the WebGPU,
and we are looking on that.
If one of the solutions is,
yes,
when you to reply to this part of the driver,
to implement that,
or maybe we use a different approach to manage that,
you know,
it's an extension that is required by a lot.
So, we have,
we have that in the queue.
Thank you.
Thank you very much.