You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not expecting this to be fixed, but this is just for future reference and/or if anyone is curious why a lot of memory is allocated for any filter, no matter what image size.
There were 2 independent ports of a game (which uses libxbr) to original Xbox - and neither of them worked.
After investigating this as a potential toolchain issue in XboxDev/nxdk#324, we realized this is an issue in libxbr. On original Xbox, we only have 64MiB of RAM - so this code could never work.
Aside from being "stupid", the code probably causes performance issues, too:
For more than a decade, CPUs have been faster than memory, so random-index lookups in the LUT will probably trash the cache. If the CPU just did the math instead (or used smaller LUTs), it would likely be faster.
The same problem exists in ffmpeg but probably doesn't trigger on most modern machines, or people don't care for the performance.
I think this code is truly horrible and should be improved. Is this project still being maintained @Treeki ?
Not expecting this to be fixed, but this is just for future reference and/or if anyone is curious why a lot of memory is allocated for any filter, no matter what image size.
xbr_data
is allocated at:libxbr-standalone/test_app.c
Line 101 in 3835e97
due to a massive array size (64 mb):
libxbr-standalone/filters.h
Line 54 in 3835e97
The text was updated successfully, but these errors were encountered: