@Rob
According to its wikibook, AROS PowerPC currently doesn't even run on any PowerPC system natively, which supports Altivec. Hosted mode is of course available on Darwin and Linux, but because of the above, I seriously doubt any significant effort was done in AROS for any kind of Altivec enhancements. (AROS fans should feel free to fix me on this.)

--
OK, it was nice to feed the trolls for a while, but I was - of course - talking about MorphOS, which has Altivec accelerated JPEG support bundled since 2.0 (mid-2008).

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

@Chain-Q

Gosh I never would have guessed

Seriously though that's interesting, given that MorphOS is Amiga like, does it give the kind of speed ups reported in the info about the library Deniil is talking about?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
To be honest, I never tried or benchmarked... It's just "there" for so long... But everyone can try: get a CPU with Altivec, test whatever you want, then boot the MorphOS kernel (boot.img) with NOALTIVEC (if I remember correctly...) argument. That turns off Altivec support in the kernel, and it also prevents advertising Altivec support to the userland. Then every well behaved application or component should fall back to non-Altivec codepaths. Then run your benchmarks again.

Please note that MorphOS' Altivec implementation for JPEGs is a custom one, and predates libjpeg-turbo or similar efforts, so your results may or may not be relevant with a different implementation.

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

Any registered WarpDT users here who would be able to test the Altivec enabled WarpJPEG on MorphOS? I have the OS4 version covered, but have no hardware to test if the Altivec code on MorphOS is working

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@Futaura

Hi,
on os4 was real performance increase?

Last edited by Tuxedo on 29-Apr-2015 at 07:59 PM.

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Yes

Obviously, it is already pretty fast without Altivec, so the speed increase is more apparent with larger images. I've yet to get properly into benchmarking, but with my initial test image I'm seeing that it is twice as fast on that image. It is also possible that I need to make some adjustments to the WarpDT engine to get the most out of the decoders now being so much faster - so far, I've just bolted the Altivec code on to check it really was worthwhile pursing.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@Futaura

REALLY interesting!
For large images what do you mean exactly?

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Chain-Q

Quote:

OK, it was nice to feed the trolls for a while, but I was - of course - talking about MorphOS, which has Altivec accelerated JPEG support bundled since 2.0 (mid-2008).

Sorry, couldn't help have a little light hearted fun.

@Tuxedo

I tried the simple JpegTools based on the same code and the difference was impressive. 2x minimum up to 2.7x faster IIRC. Can't remember if decoding or encoding got the biggest gain but I think it was decoding that benefitted most...

I'm working on the jpeg.library now, but since I've never made a library before I have some hurdles to get over, like crashes in jpeg_mem_init. (Yes I replaced malloc() with an exec memory pool...)

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

It might be worth looking at the awebjfif.awebplugin src (in the AWeb archive on os4depot) there a couple of mods in the jpeglib in that that makes it work in a library. Memeory handler is one, but also error reporting via stder would cause crashes IIRC. So you may need to override that part of the library.

And, just in case, you did remeber to initialise INewLib in your library startup code?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Yeah, I'm building without stdlib so I've already implemented the needed parts of stdlib.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Tuxedo

I don't know what I mean by large images, yet - I will after some extensive benchmarking. Obviously, if you have a tiny 128x128 background image tile, for example, as it already loads so quickly without Altivec, the speed difference is not going to be noticeable until an image hits a certain limit. Of course, the number of pixels in an image is going to be a factor, but equally probably the level of compression used by the image will too. I've yet to establish how the Altivec optimisations benefit large pixel counts and/or large files.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@Futaura

I mean for example 10 mpx or larger image...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

It's on large images I got my test results. It was hard to measure on smaller images since they load so fast anyway.

I had a 6000x4200px pic to test with. That's like 25Mpx?

I have not tested the WarpDT yet though.

Last edited by Deniil715 on 02-May-2015 at 12:34 AM.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Tuxedo

Having now tested many types of image, big, small, and different levels of compression quality, the performance increase is pretty consistent across all images, but it does vary presumably on the image content (due to the nature of JPEG compression). Given that WarpJPEG is currently running my modified standard jpeg-9a code with only the Altivec code from libjpeg-turbo, I'm seeing a speed boost of 40-90% across all images. On average, most images will load at least 1.5x faster than before, even with tiny images.

My next step is to evaluate whether any of the general non-Altivec changes in libjpeg-turbo, such as the Huffman decoder, bring any performance benefit over jpeg-9a, which might explain why Deniil715 is seeing a bigger speed boost.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@All involved

If it can be of help, I can provide a 70 MP megapixels 7000x10000 JPEG file (used to test my HottiesView image viewer), so in case send me a PM with your email address.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

You'll be able to test it yourself soon enough - I plan to release the new WarpJPEG on Friday, with AltiVec for both OS4 and MorphOS. Extensive testing has revealed that even though the speed boost is very good on a G4, it is even more impressive on a PA6T. Even without AltiVec, WarpJPEG will be the fastest JPEG datatype on OS4.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@Futaura

Does the WarpDT jpeg.datatype handle saving as RAW (ie Jpeg) format?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

No. I've never really seen the point of adding write support in datatypes partly because the current API is ultra restrictive in that it is impossible for the calling application (and therefore the user) to set the encoding/compression parameters (e.g. JPEG quality, progressive, lossless etc). As a developer it is a feature I would never use - in terms of speed, control and efficiency, it is best to use jpeglib or libpng directly. As a user I would prefer to have control of the encoding parameters.

That said, if you install WarpJPEG on OS4, it can coexist with the vanilla jpeg.datatype - no extra effort required . WarpJPEG will be used for reading, and jpeg.datatype for writing, should anyone really need this feature.

Last edited by Futaura on 15-May-2015 at 03:55 PM.
Last edited by Futaura on 15-May-2015 at 03:55 PM.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@Futaura

Quote:

No. I've never really seen the point of adding write support in datatypes partly because the current API is ultra restrictive in that it is impossible for the calling application (and therefore the user) to set the encoding/compression parameters (e.g. JPEG quality, progressive, lossless etc). As a developer it is a feature I would never use - in terms of speed, control and efficiency, it is best to use jpeglib or libpng directly. As a user I would prefer to have control of the encoding parameters.

I understand you point about API limitations, although actually there no reaon why addiational parametrs can't be passed , provisision for that is in place in the API in the form on a taglist option to the writemethod. It's just that no ones fleshed out the taglist for any imge types...

The saving is quite nice now that OS4 has support for it in that MultiView now saves image in the same type you loaded them as.

Quote:

That said, if you install WarpJPEG on OS4, it can coexist with the vanilla jpeg.datatype - no extra effort required . WarpJPEG will be used for reading, and jpeg.datatype for writing, should anyone really need this feature.

Hmmm, does that require any develper intervention or is it transparent?

If I create an object with basename 'jpeg' and save with the RAW method wil it automagicallcy use the os datatype?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad