You cannot run altivec code on non altivec machines. Eevn though there maybe only certain sections explictly coded for altivec as soon as you enable altivec in the compiler it will optimise other sections of the code to use it where possible.
So stop waste LiveForIt's time by reporting that altivec crashing on a SAM!
You cannot run altivec code on non altivec machines
Well that's not very true Andy, MUI MPlayer (Altivec version) doesn't crash on non Altivc machines, another example is DvPlayer .. but i agree with you when you say that it isn't so important ..
Well that's not very true Andy, MUI MPlayer (Altivec version) doesn't crash on non Altivc machines, another example is DvPlayer ..
Andy is correct, altivec code won't run on non-altivec machines.
Programs with altivec code that also run on non-altivec machines are written carefully such that the altivec code never runs on non-altivec machines. This requires separating out all code that is altivec, and putting them into separate source files. That way, only those files are compiled with altivec enabled.
@Andy,Hans And mplayer writen in that good way with separated parts, and when build for altivec, some objects builds as for altivec, some are not. Probably liveforit just build all objects for altivec.
But that anyway make no big differences to run altivec based bins on non altivec machines of course.
And mplayer writen in that good way with separated parts, and when build for altivec, some objects builds as for altivec, some are not. Probably liveforit just build all objects for altivec.
But that anyway make no big differences to run altivec based bins on non altivec machines of course.
Yes, compiling all objects with altivec enabled does make a difference for non-altivec machines. When you enable altivec, you're giving the compiler permission to use altivec instructions whenever it feels that it's the optimal choice. You don't even have to enable autovectorization for that to happen.
There are some differences between cgx_wpa and comp output. First difference I use ARGB bitmap, not RGB bitmap, this does not effect the X1000 at all, at lest not on my computer. But it might effect computers whit slower RAM bus.
13% more data is need to be sent to the graphic card, your result show that the bus speed is the bottleneck.
I realise that this is from an old post, but using a 24-bit RGB bitmap won't save on bandwidth because the destination bitmap is 32-bit ARGB.** Writing 3 bytes and then skipping one across the PCI(e) bus would be hideously slow, so it has to be converted to ARGB first, and then copied.
Hans
** Graphics cards don't like 24-bit bitmaps, because the pixels aren't nicely aligned to 32-bit boundaries.
I did some calculations on Amigaworld, it steams the the PCI bus should be OK at peek load, it most be the way I'm rendering into the graphic memory instead of letting DMA handle it.
Quote:
Overlay: 640x480x2 = 614 400 bytes / per frame Composition (ARGB): 640x480x4 = 1 228 800 bytes / per frame.
Overlay: 768x576x2 = 884 736 bytes / per frame Composition (ARGB): 768x480x4 = 1 474 560 bytes / per frame.
Overlay: 800x600x2 = 960 000 bytes / per frame Composition (ARGB): 800x600x4 = 1 920 000 bytes / per frame.
The max bus speed on PCI 33Mhz is 133 MB/s ~ 2.66 Mb/frame The max bus speed on PCI 66Mhz is 266 MB/s ~ 5.32 Mb/frame
I'm guessing that max pci bus values are more of theoretical value then actual value, as the bus is shared between devices.
I'm just afraid If I changed it to buffered memory, it might effect the speed on X1000.
As PCIe is really fast and buffered copy might just be hindrance instead of a benefit. What do you think.
Edited by LiveForIt on 2014/4/5 11:57:39 Edited by LiveForIt on 2014/4/5 11:58:16 Edited by LiveForIt on 2014/4/5 12:01:33 Edited by LiveForIt on 2014/4/5 12:08:13
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I think your getting confused by the text output, there is no Re-size gadget on cgx_wpa. You will get the same kind text output on composition version, because its based on cgx_wpa, don't let it confuse you.
Pressing Resize gadget and F here, make the video looked zoomed in, I think it changes the image_width and image_height or some thing.
EDIT:
There is round of width to 32bit. (0 to 7) 8 * 4 (bpp). I will try to round it of by 64bit.
Edited by LiveForIt on 2014/4/5 15:14:25
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
The Cybergraphics screen mode detection code stucks so badly.
It try's to add 10 pixels to width and hight, in the hopes to find a resolution that is bigger then the video. It never stops trying, what to do about that....
I guess I need to replace it, my monitor just does not support 1080p
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
