Training at low resolution is actually slower

[Northern-mountains]

Hello Author, thank you very much for your excellent work, but I encountered a problem while reproducing the code and would like to ask you about it.
In some other 3DGS acceleration work, using the same dataset, training with a lower resolution often results in faster training times.But I found something very interesting: when training on the train and truck datasets, using a lower resolution actually results in longer training time.
The parameters such as primitives all use the default parameters you provided. However, for other datasets like bicycle and counter, training at a lower resolution will take less time. I would like to ask you, what is the reason for this?
I have tested on RTX5060, RTX5090D, RTX Pro6000, RTX3090, and RTX4090, and the phenomenon is the same. The following results are what I trained on the RTX5060.

(litegs)@thinkbook:/Project/litegs$ python example_train.py -s dataset/truck -m output/truck_r1 -r 1
Train: 100%|██████████████████████████████████████████████████████████████████████████| 119/119 [04:34<00:00, 2.31s/it]
output/truck_r1 takes: 274.58419132232666
(litegs) @thinkbook:/Project/litegs$ python example_train.py -s dataset/truck -m output/truck_r2 -r 2
Train: 100%|██████████████████████████████████████████████████████████████████████████| 119/119 [04:56<00:00, 2.49s/it]
output/truck_r2 takes: 296.01036834716797
(litegs) @thinkbook:~/Project/litegs$ python example_train.py -s dataset/truck -m output/truck_r4 -r 4
Train: 100%|██████████████████████████████████████████████████████████████████████████| 119/119 [08:07<00:00, 4.10s/it]
output/truck_r4 takes: 487.35887384414673

(litegs) @thinkbook:/Project/litegs$ python example_train.py -s dataset/train -m output/train_r1 -r 1
Train: 100%|████████████████████████████████████████████████████████████████████████████| 99/99 [05:07<00:00, 3.10s/it]
output/train_r1 takes: 307.31695079803467
(litegs)@thinkbook:/Project/litegs$ python example_train.py -s dataset/train -m output/train_r2 -r 2
Train: 100%|████████████████████████████████████████████████████████████████████████████| 99/99 [06:17<00:00, 3.81s/it]
output/train_r2 takes: 377.34369564056396
(litegs) @thinkbook:~/Project/litegs$ python example_train.py -s dataset/train -m output/train_r4 -r 4
Train: 100%|████████████████████████████████████████████████████████████████████████████| 99/99 [11:23<00:00, 6.91s/it]
output/train_r4 takes: 683.7325015068054

[KaiminLiao]

That's an interesting problem. We hadn't noticed this before, but we've successfully reproduced the issue. We'll look into it and get back to you with an update soon.

[KaiminLiao]

Here is a detailed breakdown of what we found under the hood.

It turns out that with -r 4, the image resolution is very low (only 256x136). In standard error-threshold-based densification strategies (like the original 3DGS), the model would naturally generate fewer Gaussian points since the pixel error is much smaller at this resolution. However, LiteGS inherits its densify strategy from taming-3dgs, where the parameter budget is pre-determined. Under the default configuration, it will stubbornly generate around 1M Gaussian primitives.

This causes a massive over-allocation of Gaussians trying to fit pixel-level high-frequency details. As a result, a huge number of tiny primitives (only 1-5 pixels in size) are projected onto the screen space.

The core issue lies in the tile-based rendering framework. These tiny 1-5 pixel primitives still force the rasterizer to process the entire tile. Because the footprint of each primitive is so small, the alpha accumulation is extremely slow, meaning the early stopping (alpha cutoff) triggers very late.

Consequently, a single pixel might undergo tens of thousands of alpha blending iterations. Even worse, this leads to severe thread serialization (warp divergence) during computation—a few pixels get stuck in massive blending loops while the surrounding "normal" pixels finish early and just sit idle. (You can clearly see this in the per-pixel blending count stat image below).

Interestingly, we've encountered a very similar issue in Autonomous Driving scenarios with LiDAR-reconstructed 3DGS. We are planning to completely resolve this underlying architectural issue in the next release. For now, here are a few workarounds we suggest:
(1) Reduce the total number of Gaussian primitives in your configuration.
(2) Modify the densify strategy back to a error-threshold-based method.
(3) Implement screen-space culling to simply discard Gaussians that are too small on the screen (e.g., filtering them out based on inv_cov).

[KaiminLiao]

We just found another critical issue related to this. LiteGS uses int16 for the blend count, which the backward stage depends on. The excessive number of Gaussian primitives is directly causing an int16 overflow here (see the image below). We'll get this overflow issue fixed as soon as possible!

[Northern-mountains]

Understood, thank you very much for your explanation, and thanks again for open-sourcing such an excellent project.

[Northern-mountains]

Regarding your mention that too many Gaussian primitives directly lead to int16 overflow, it seems I have encountered a similar problem.
When the total sum of "the number of tiles covered by each Gauss" exceeds 2^-1 (about 2.1 billion), an integer overflow occurs, and the result becomes negative. If this is then passed to createtable to allocate a tensor, a "negative size" will appear.

[Northern-mountains]

Hello author, thank you for your reply. The per-pixel mixture count statistics chart in your response is very interesting. I would like to ask how it was created. Would it be possible for you to open-source this part of the code?I want to use your method to do some tests.

[KaiminLiao]

Thanks for your interest.

Regarding the per-pixel blending count (including those skipped due to small alpha values), you can find this information in LiteGS/litegs/render/init.py line:80

Specifically, it is obtained via the lst_contributor variable returned by GaussiansRasterFunc.

[Northern-mountains]

Thank you, looking forward to your even better works, and have a happy life~