English Amiga Board Amiga Lore


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 03 November 2016, 13:15   #61
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 364
Quote:
Originally Posted by britelite View Post
Well, yes, the platform has stayed static for so long which is pretty much the whole idea and what makes it fun.
"Fun" is subjective. On a more objective side it keeps the demos and their technical level comparable. That's why I don't think that the demo categories for Amiga compos will change.


Quote:
And as I've said, why limit myself to the Vampire/Apollo-core if I only wanted more power
For me the reason would be that I want to do coding in 68k assembly on an OS that doesn't stack gigabytes of software layers on top of each other. On the other hand I'm tired of doing chunky-to-planar stuff and stacking static 2-bit planar gfx on top of 6-bit c2p'ed gfx, limited palettes and the impossibility of more computationally deep effects. I rather spend my time doing a precise sine approximation than using tables for everything a.s.o. Coding for the 080 is refreshing.
grond is offline  
AdSense AdSense  
Old 03 November 2016, 14:10   #62
Zetr0
Ya' like it Retr0?
Zetr0's Avatar
 
Join Date: Jul 2005
Location: United Kingdom
Age: 42
Posts: 9,769
I will put the cat amongst the pigeons here :

If an ASM coder codes for an 060 - but lets say shuns the V2 - doesn't this belay the point of programming on an 060?

After all, if speed isn't your thing surely an 020/030 is more applicable as more people have access to it.


Now I will probably answer my own question :

The 060 has a defined *static* ISA as well as an MMU and FPU where as the V2 is in state of flux (optimizing and additional register sets included) - in this regard until the V2 core is matured and finalized - it will make it diffcult to coders as it would be like playing a game of football with the goal posts changing position after every kick.

In the meantime :

How cool is it that I can watch Top Gun in 640x480 on my A600!!!!

As a developer - think of the possibilities of FMV used in conjunction in game or applications - freaking exciting if you ask me!
Zetr0 is offline  
Old 03 November 2016, 14:25   #63
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 242
Quote:
Originally Posted by Zetr0 View Post
After all, if speed isn't your thing surely an 020/030 is more applicable as more people have access to it.
Because when I don't want speed I actually code for the A500

When it comes to the demoscene 060/AGA has been the de facto accelerated Amiga platform for almost 20 years, which is why people stick to the 060. And in the past few years there's also been a renewed interest in going back to the basics and doing stuff for the A500, which I think is a good thing.
britelite is offline  
Old 03 November 2016, 17:06   #64
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 883
Quote:
Originally Posted by britelite View Post
which I think is a good thing.
it is a good thing to serve the lowest common denominator and widest possible audience where applicable, i agree. but i do not feel that apollo proposal availability must necessarily be in conflict with this especially as soon as we agree upon the above.

extra stuff like instruction set or api extensions may be sparely used where they are of notable importance for speed or functionality, similarly like asm inlines. the thing is not everybody is convinced that it would be most beneficial attitude. some folks insist on coding everything in 68k asm, others say 68k is too outdated, they need os4 interfaces.
wawa is offline  
Old 04 November 2016, 00:01   #65
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 482
Quote:
Originally Posted by buggs View Post
The team members are on a constant lookout for people who are willing to lend a bit of their spare time contributing something to the project. To underline a point here: there are members like for example Jim Drew (Fusion, PCx) who keep Gunnar and Chris on their toes concerning compatibility to existing software, irrespective how badly the code in question was abusing the 68k.
This is absolutely true. *My* focus is to keep Gunnar/Chris grounded so that software compatibility is the most important goal. It doesn't matter if you have the fastest car in the garage if you can't get traction!

The additional instructions (some of which have come as direct result of PCx), are a welcome addition to the core. The recent AMMX usage (I say recent, but AMMX has been in the core for awhile) gives a FREE boost in performance by using the instructions. Nobody is forcing you to use those instructions in your code, but I would say it is rather "clever" to use those if they are available.

I write only in assembly (no matter what CPU I am using), and have since 1979. The 68080 (a name I don't particularly care for really) is an excellent superscaler CPU core, with lots of flexibility from a programmer's stand point. It's also a breath of fresh air for Amiga enthusiasts who want the fastest possible CPU. I don't see anything wrong with the Vampire project - and if I did, I sure as hell would not be involved.

Last edited by JimDrew; 05 November 2016 at 06:55.
JimDrew is offline  
Old 09 November 2016, 07:24   #66
TuKo
Apollo Team

TuKo's Avatar
 
Join Date: May 2014
Location: Switzerland
Posts: 184
RiVA 0.50 sources have been released publicly on Aminet.

http://aminet.net/package/gfx/show/RiVA-src

Let's skilled ASM coders improve it now

Last edited by TuKo; 09 November 2016 at 08:38.
TuKo is offline  
Old 09 November 2016, 09:38   #67
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 364
Finally talking ends and coding begins.
grond is offline  
Old 10 November 2016, 19:13   #68
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,532
Is there any way to estimate hypothetical speed gain if instead YCbCr color space YCgCo color space will be used in video source (assumption it is easier to recode on PC video from YCbCr to YCgCo and at the same time some processing can be performed - for example resizing to match Amiga graphics HW capabilities).

https://en.wikipedia.org/wiki/YCgCo#YCbCr_color_model
pandy71 is offline  
Old 10 November 2016, 21:21   #69
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,379
Quote:
Originally Posted by pandy71 View Post
Is there any way to estimate hypothetical speed gain if instead YCbCr color space YCgCo color space will be used in video source (assumption it is easier to recode on PC video from YCbCr to YCgCo and at the same time some processing can be performed - for example resizing to match Amiga graphics HW capabilities).

https://en.wikipedia.org/wiki/YCgCo#YCbCr_color_model
There would be some speed gain but not very much because current YCbCr conversion is normally quite optimal and so this conversion doesn't really play a major role on overall decode time (i know for jpeg still images but for video it's just a guess, though). For a coarse estimate i'd say something like 10% gain.

I don't think it can be easily tested because YCgCo isn't supported in MPEG-1 (only format supported by Riva).
For this MPEG-4 support has to be added (but h.264 would be a lot more cpu intensive).
meynaf is online now  
Old 11 November 2016, 04:27   #70
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 890
Send a message via Yahoo to Samurai_Crow
There is one thing that is right about Meynaf's line of thinking. The Vampire version of RiVA uses a screenmode that implements the luminance and chrominance color space conversion to RGB thus AMMX is not the only optimization.
Samurai_Crow is offline  
Old 11 November 2016, 09:14   #71
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 364
Quote:
Originally Posted by Samurai_Crow View Post
There is one thing that is right about Meynaf's line of thinking. The Vampire version of RiVA uses a screenmode that implements the luminance and chrominance color space conversion to RGB thus AMMX is not the only optimization.
AFAIK at least some RTG cards also have such modes.
grond is offline  
Old 11 November 2016, 10:24   #72
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 890
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by grond View Post
AFAIK at least some RTG cards also have such modes.
True.
Samurai_Crow is offline  
Old 11 November 2016, 14:00   #73
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,532
Quote:
Originally Posted by meynaf View Post
There would be some speed gain but not very much because current YCbCr conversion is normally quite optimal and so this conversion doesn't really play a major role on overall decode time (i know for jpeg still images but for video it's just a guess, though). For a coarse estimate i'd say something like 10% gain.

I don't think it can be easily tested because YCgCo isn't supported in MPEG-1 (only format supported by Riva).
For this MPEG-4 support has to be added (but h.264 would be a lot more cpu intensive).

MPEG-1 fully support YCgCo (just set matrix coefficient as 8 - normally it is reserved for future use in MPEG-1 and MPEG-2 but it is fully specified for H.264 and H.265 - problem is that nobody use MPEG-1 so it is uncommon practice to use YCgCo as it is not popular even nowadays but Amiga have limited processing capabilities so any gain is valuable (as every pixel need to be converted from YCbCr to RGB and later to Amiga HW limitations).
Side to this Intra frame formats should be less intensive especially H.264 (without CABAC and deblocking loop which takes like 50 - 60% of decoder processing power).
I can made streams for testing if this is a problem.
pandy71 is offline  
Old 11 November 2016, 19:35   #74
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 44
Quote:
Originally Posted by pandy71 View Post
MPEG-1 fully support YCgCo (just set matrix coefficient as 8 - normally it is reserved for future use in MPEG-1 and MPEG-2 but it is fully specified for H.264 and H.265 - problem is that nobody use MPEG-1 so it is uncommon practice to use YCgCo as it is not popular even nowadays but Amiga have limited processing capabilities so any gain is valuable (as every pixel need to be converted from YCbCr to RGB and later to Amiga HW limitations).
Side to this Intra frame formats should be less intensive especially H.264 (without CABAC and deblocking loop which takes like 50 - 60% of decoder processing power).
I can made streams for testing if this is a problem.
Well, the YCgCo color space is certainly appealing, not only for the lossless properties but also decorrelation abilities along with simple computation.

In terms of H.264, I'm not sure whether it would really help to save cycles on a humble 68k. Correct me if I'm wrong and missed an amendment to AMD 1, but FRExt states that YCoCg is legal only with chroma_format_idc=3, i.e. 4:4:4 and at least 9 Bit for Chroma in H.264. So when the effective pixel count doubles and 8 BPP is no longer sufficient for storage, the resulting tradeoff might well swing in an unfortunate direction (when staying standards-compliant).
buggs is offline  
Old 12 November 2016, 07:04   #75
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 482
The player using AMMX instructions is more than twice as fast as the version that doesn't use these instructions, using the same Vampire setup. I am not sure how much clearer this needs to be.
JimDrew is offline  
Old 12 November 2016, 10:41   #76
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,379
Quote:
Originally Posted by JimDrew View Post
The player using AMMX instructions is more than twice as fast as the version that doesn't use these instructions, using the same Vampire setup. I am not sure how much clearer this needs to be.
This is valid only if the AMMX instructions are the only change between these two versions, which apparently isn't the case. Have you seen the actual code ?
meynaf is online now  
Old 12 November 2016, 13:57   #77
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,532
Quote:
Originally Posted by buggs View Post
Well, the YCgCo color space is certainly appealing, not only for the lossless properties but also decorrelation abilities along with simple computation.
It is not so popular but i see some benefits using it especially on systems without modern multimedia instructions and/or without HW processing capabilities. De-correlation chroma from luma is quite frequently noted when you read about YCgCo but somehow it is used rarely (mostly in modern desktop real time capture and compression - gaming recording etc).
Side to this i think about building OCS/ECS VIDIOT (aka Video DAC) to support HW YCgCo to RGB conversion (in AGA as external module) - it can operate on analog signal so it will be possible to remove YCgCo to RGB conversion step - maybe similar principle as Archos AVideo.

Quote:
Originally Posted by buggs View Post
In terms of H.264, I'm not sure whether it would really help to save cycles on a humble 68k. Correct me if I'm wrong and missed an amendment to AMD 1, but FRExt states that YCoCg is legal only with chroma_format_idc=3, i.e. 4:4:4 and at least 9 Bit for Chroma in H.264. So when the effective pixel count doubles and 8 BPP is no longer sufficient for storage, the resulting tradeoff might well swing in an unfortunate direction (when staying standards-compliant).
Benefits for H.264 is that it is fully integer codec - in available reports most of decoding power used for H.264 decode is: deblocking (can be turned off) and CABAC (arithmetic entropy coding) in total they can be responsible for more than 60% consumed CPU cycles - as CABAC can be replaced by CAVLC which is computationally less intense it may be case where H.264 decoder will be more efficient than MPEG-1 (offering same or better compression) and at the same time less computationally intense.

I don't see any YCgCo limitation mentioned by you - are you able to use latest official specification and confirm this?

https://www.itu.int/rec/T-REC-H.264-201602-S/en

Additionally - YCbCr is more lossy (RGB -> YCbCr -> RGB) than YCgCo -YCbCr require between 1 - 2 bits more than YCgCo to perform fully reversible RGB conversion.
Finally i would say that we should not stuck with perfect compliant decoder for Amiga - i see no problem to create Amiga optimal format based on widely accepted standards and if possible use those standards as much as possible but in Amiga every CPU cycle count so... we can anyway pre-code videos on PC (resizer quality will be always higher quality on modern CPU - Amiga probably can do real time bilinear or cubic at best without de-gamma when PC easily may precode linearized/de-gamma video with spline + something like MSAA/FXAA to reduce aliasing and improve visual quality on low res Amiga screen).

I agree - it should be standard as much as possible but to squeeze all possible cycles perhaps it is good to select subset of codec functionality to keep healthy balance between quality\speed\compatibility.
pandy71 is offline  
Old 12 November 2016, 15:02   #78
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,379
Quote:
Originally Posted by pandy71 View Post
Benefits for H.264 is that it is fully integer codec - in available reports most of decoding power used for H.264 decode is: deblocking (can be turned off) and CABAC (arithmetic entropy coding) in total they can be responsible for more than 60% consumed CPU cycles - as CABAC can be replaced by CAVLC which is computationally less intense it may be case where H.264 decoder will be more efficient than MPEG-1 (offering same or better compression) and at the same time less computationally intense.
That sounds very interesting, I'd like to attempt coding something in this area.
As ISO specs are difficult to find and not exactly straightforward to read, is it possible to find some reference code that would compile on Amiga ?
meynaf is online now  
Old 12 November 2016, 18:22   #79
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 44
Quote:
Originally Posted by pandy71 View Post
It is not so popular but i see some benefits using it especially on systems without modern multimedia instructions and/or without HW processing capabilities. De-correlation chroma from luma is quite frequently noted when you read about YCgCo but somehow it is used rarely (mostly in modern desktop real time capture and compression - gaming recording etc).
Side to this i think about building OCS/ECS VIDIOT (aka Video DAC) to support HW YCgCo to RGB conversion (in AGA as external module) - it can operate on analog signal so it will be possible to remove YCgCo to RGB conversion step - maybe similar principle as Archos AVideo.
Frankly, I see the most prominent use for YCgCo in lossless applications. At least, that was the rationale behind it's inclusion into JPEG2000, IIRC.

The idea of putting an external conversion HW to the RGB port is very nerdy, if I may say so (if not pls accept my apologies). As a side note that doesn't necessarily coincide with your particular interests, YCbCr output would work with the same approach, even leading back to the good old YUV. I'd expect some artifacts having to be addressed cleverly when thinking of colorful images by means of HAM. I'd be interested to hear about such projects going forward.

Quote:
Benefits for H.264 is that it is fully integer codec - in available reports most of decoding power used for H.264 decode is: deblocking (can be turned off) and CABAC (arithmetic entropy coding) in total they can be responsible for more than 60% consumed CPU cycles - as CABAC can be replaced by CAVLC which is computationally less intense it may be case where H.264 decoder will be more efficient than MPEG-1 (offering same or better compression) and at the same time less computationally intense.
I happen to have a functional High Profile (=100) H.264 decoder on my Amiga. Please mind my wording, though. In it's current state, it's not of much use as FMV on the classic Amiga platform. It works flawlessly (bit accurate decoding) with my test suite but as of now not in the desired time frame.

Quote:
I don't see any YCgCo limitation mentioned by you - are you able to use latest official specification and confirm this?
https://www.itu.int/rec/T-REC-H.264-201602-S/en
Additionally - YCbCr is more lossy (RGB -> YCbCr -> RGB) than YCgCo -YCbCr require between 1 - 2 bits more than YCgCo to perform fully reversible RGB conversion.
P.396 "matrix_coefficients equal to 8". Still unchanged in comparison to the 2004/2005 spec I had around.

The consideration towards bit depth boils down to the question whether one is able to handle the necessary bit rate where such details become truly relevant. The sheer abundance of computing power and storage capacity on the usual platforms these days allow that for interested parties, for sure. The classic Amiga is "a little" handicapped in this department (see below fo an example, please).

Quote:
Finally i would say that we should not stuck with perfect compliant decoder for Amiga - i see no problem to create Amiga optimal format based on widely accepted standards and if possible use those standards as much as possible but in Amiga every CPU cycle count so... we can anyway pre-code videos on PC (resizer quality will be always higher quality on modern CPU - Amiga probably can do real time bilinear or cubic at best without de-gamma when PC easily may precode linearized/de-gamma video with spline + something like MSAA/FXAA to reduce aliasing and improve visual quality on low res Amiga screen).

I agree - it should be standard as much as possible but to squeeze all possible cycles perhaps it is good to select subset of codec functionality to keep healthy balance between quality\speed\compatibility.
The subset I'm personally aiming for (in the long run, read: not this year) is Baseline+B-Frames. This is coincidentally the same subset used by a certain popular VOD platform. In terms of H.264, I don't see much room for compromising on the algorithms. As you of course well know, H.264 was the first standard allowing (and per se demanding) bit-accurate reproduction of the bit streams and I very much honor that as IMHO the best feature of it.

At this point, my experience on a constrained platform like 68k (even the modernized interpretation that caused some stir in Amiga-land) is that you can ill afford algorithms that have become "usual" on the modern platforms.

Just today I had to step back a bit and re-calculate on performance figures. An algorithm that just takes an average 5 cycles per pixel amounts to quite some numbers when it comes to video. So when you run video in a by current standards modest resolution of 640x360, this amounts to 1152000 cycles per frame or 28.8 MHz at a desired rate of 25 FPS. Oops. My poor A500.
buggs is offline  
Old 12 November 2016, 18:42   #80
meynaf
68k wisdom
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon (France)
Age: 44
Posts: 2,379
Quote:
Originally Posted by buggs View Post
I happen to have a functional High Profile (=100) H.264 decoder on my Amiga. Please mind my wording, though. In it's current state, it's not of much use as FMV on the classic Amiga platform. It works flawlessly (bit accurate decoding) with my test suite but as of now not in the desired time frame.
That's very interesting. Could you please make it available somewhere ?
meynaf is online now  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
RiVA mpeg player amiga request.Apps 18 25 February 2014 10:32
ACA1231 vs M-Tec 1230 vs A630 benchmarks alenppc support.Hardware 4 11 July 2012 18:39
Some benchmarks, and a request Damion support.Hardware 29 14 March 2011 16:10
riva amiga request.Apps 6 12 May 2008 18:56
Benchmarks. ECA support.Hardware 4 14 June 2002 15:14

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:35.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.27029 seconds with 11 queries