08:06 <jasuarez> in case you didn't know, if you want to netboot a RPI3 you don't need to do anything special, as the rpi3 already is configured to be able to boot through network

08:06 <jasuarez> that's because it lacks an eeprom, and thus it is "hardcoded"

08:06 <jasuarez> for rpi4 though, it has an eeprom that must be configured

08:07 <jasuarez> googling there, it is suggested to update the firmware to be able to do it

08:07 <jasuarez> I think all those links are a bit outdated

08:07 <jasuarez> the easiest way is to boot it normally, and from terminal execute `sudo -E rpi-eeprom-config --edit`

08:08 <jasuarez> a configuration file will be opened; you need to add (or modify) the following line `BOOT_ORDER=0x21`

08:08 <jasuarez> which means _"boot from SD card if it is present (code 2) and if not boot from netboot (code 1)"_

08:09 <jasuarez> if you switch the numbers you switch the order, and there are more numbers for other options

08:09 <jasuarez> just save and exit, reboot and voilá!

08:09 <jasuarez> if you remove the SD card and have a configured tftp/nfs server, it will boot from there

08:10 <jasuarez> if you want to check current configuration, just using `vcgencmd bootloader_config` and check for the `BOOT_ORDER` line if it is present and if so the value

09:33 <chema[m]> thanks for the explanation jasuarez

09:42 <nikolay_> interesting, I was not aware that rpi3 supports network boot

09:54 <jasuarez> yeah, actually network boot is the first one to try iirc

12:01 <itoral> apinheiro: finished the ldvary pipelining work, it leads to some nice improvements in generatd fragment shader code:

12:01 <itoral> instructions in affected programs: 7809692 -> 7558791 (-3.21%)

12:01 <itoral> helped: 41209

12:01 <itoral> HURT: 4528

12:01 <itoral> And:

12:02 <itoral> max-temps in affected programs: 84302 -> 74953 (-11.09%)

12:02 <itoral> apinheiro[m]1 ^

12:03 <apinheiro[m]1> oh nice

12:03 <apinheiro[m]1> do you plan to send to to review today, or you are still tidying the code?

12:04 <itoral> apinheiro[m]1: I already created the MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9304

12:04 <apinheiro[m]1> ok, will take a look later, I guess that it can wait till next week?

12:05 <itoral> sure, there is no rush

12:06 <apinheiro[m]1> ok, I will like to try to finish what I was doing this week

12:07 <apinheiro[m]1> I was basically "playing ping pong" with the solution to implement

12:10 <itoral> been there :)

12:12 <apinheiro[m]1> itoral: btw, in addition to the nice shader-db numbers, did you get any perf improvement on any of our usual testing apps?

12:13 <itoral> didn't test much, I presume there is some but it is not something huge

12:13 <apinheiro[m]1> k

12:18 <itoral> apinheiro[m]1: just tested with sponza and I see a 1% improvement (sponza is easy because it has a very stable framerate)

12:18 <itoral> I think a 1% improvement is more difficult to spot in something like the UE4 Shooter demo

12:19 <itoral> because of the wildly varying framerate

12:19 <apinheiro[m]1> yeah, probably

12:20 <itoral> but everything I managed to improve for the UE4 demo it led to gains in Sponza, so it is very likely this improvement translates to it

12:24 <itoral> man, the Shooter demo loads so much faster now after we started using nir_opt_sink due to the reduced spilling in the histogram compute shader

12:38 <itoral> apinheiro[m]1: did some quick tests with the UE4 Shooter demo and it seems the gains there are somewhere between 1% and 2% for max fps

12:39 <apinheiro[m]1> ok,

12:39 <apinheiro[m]1> <itoral "man, the Shooter demo loads so m"> oh, I was wondering that

12:39 <apinheiro[m]1> it is nice indeed

12:45 <apinheiro[m]1> will test with the gfx traces, in case it shows something