English Amiga Board Amiga Lore


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 03 March 2017, 10:56   #41
Retrofan
Ruler of the Universe

Retrofan's Avatar
 
Join Date: Mar 2010
Location: Lanzarote/Spain
Posts: 5,594
Send a message via Skype™ to Retrofan
Let's see: With Picasso 24bit TRUECOLOR works, but just like I linked in post 26

It was the same with Riva 050
Retrofan is offline  
AdSense AdSense  
Old 03 March 2017, 17:41   #42
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by buggs View Post
My apologies for not getting back into EAB earlier. I've got an idea why the windowed mode does not work in some configurations. Please try a test build: http://bax.comlab.uni-rostock.de/fil...iVA-0.53a0-68k (changed WRENDER_DIRECT to 0) I've experimented with direct drawing to the window and while it worked on my setups as intended, undesired side effects sure are a possibility. Sadly, the much needed PIP is not widely available to Amiga users.
The DISPLAY=PIP with or without FULLPIP is still only showing a grey render area with your test version. I see now that the window mode DISPLAY=PIP is also likely a YUV mode even though it is on a 16 bit BGR workbench screen. The interface seems backward to me as DISPLAY=PIP gives a window while other options open a screen (but with FULLPIP it is like opening a screen). I'm surprised there is no non-PIP window mode too. The PIP window mode is friendly and can be moved around like any other intuition window with less than 1 fps difference in performance. Would it be possible to add a non-PIP window setting?

While testing I discovered another problem with RIVA v0.50 which is still present in the new version. Sometimes the rendered screen shows a garbled screen of diagonal banding with DISPLAY=HICOLOR. I looked at the screen modes being used.

320x256x16PC screen mode to display a 352x256 mpeg (not working)
320x240x16PC screen mode to display a 352x240 mpeg (not working)
320x240x16PC screen mode to display a 320x240 mpeg (working)

The video works here only when I have a P96 resolution which exactly matches the video resolution. P96 users are not guaranteed to have any particular screen resolution or display format. It may be worthwhile to look into the choice of best mode id and have centering or scaling if the video is narrower than the display (or clipping if the video resolution is larger than the display resolution). A non-PIP window mode and the ability to force a screen mode id and/or resolution could be helpful here for testing even though the switches may have to be changed.

Quote:
Originally Posted by buggs View Post
RiVA as released on Aminet does work on 68020/30. Originally, I aligned the framebuffers and re-implemented the zero vector Motion Compensation (16x16 block copy) by Move16, which is 68040+. This got changed back at some point (not by me). As a consequence, it's a small bit slower on 040+ but still supports the older CPUs.
The performance advantage of MOVE16 depends greatly on whether the 16 byte block should be in the DCache afterward or not. If the block is going to be used from the DCache soon then there is little advantage to using MOVE16 as writes from it bypasses the DCache. On the other hand, it could be useful for large and/or streaming data which would otherwise flush the DCache.

I have heard there is a MOVE16 bug in some early versions of the 68040 as well but I have never heard anyone complain that MOVE16 was not working on their CPU.

Last edited by matthey; 03 March 2017 at 18:22.
matthey is offline  
Old 03 March 2017, 22:44   #43
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 44
Quote:
Originally Posted by AMIGASYSTEM View Post
The screenshot was not done on AROS but on AFA OS
My AFA OS
[ Show youtube player ]
With Graphic Card With Picasso IV (32 or 24 Bit) noticed that the window can be resized? Picasso IV 8-bit video can be seen in full screen! UAE Zorro III 32, 24, 16 no resized?
I stand corrected. In the meantime, I was able to convince ShK doing some testing on my behalf. The default PicassoIV PIP mode should be working again. Also, I was reported that "display=accupak" was still operating.

There is a reason why PIP is the only mode where a resizable window is offered. In this mode, the Picasso IV performs the scaling such that it basically comes for free in terms of CPU usage.
buggs is offline  
Old 03 March 2017, 23:12   #44
buggs
Registered User

 
Join Date: May 2016
Location: Rostock/Germany
Posts: 44
Quote:
Originally Posted by matthey View Post
The DISPLAY=PIP with or without FULLPIP is still only showing a grey render area with your test version. I see now that the window mode DISPLAY=PIP is also likely a YUV mode even though it is on a 16 bit BGR workbench screen. The interface seems backward to me as DISPLAY=PIP gives a window while other options open a screen (but with FULLPIP it is like opening a screen). I'm surprised there is no non-PIP window mode too. The PIP window mode is friendly and can be moved around like any other intuition window with less than 1 fps difference in performance. Would it be possible to add a non-PIP window setting?
Please see my previous post. PIP support was inoperable when not used in conjunction with the PIVPLANARASSIST option.

Quote:
Originally Posted by matthey
While testing I discovered another problem with RIVA v0.50 which is still present in the new version. Sometimes the rendered screen shows a garbled screen of diagonal banding with DISPLAY=HICOLOR. I looked at the screen modes being used.
320x256x16PC screen mode to display a 352x256 mpeg (not working)
320x240x16PC screen mode to display a 352x240 mpeg (not working)
320x240x16PC screen mode to display a 320x240 mpeg (working)
This is actually a curious bug. (Told you there were real bugs in RiVA to be found, no pun intended ). It works with UAEGFX, it works on my A4k but it doesn't work on Apollo when using TrueColor (and your setup). I ported my cropping/centering code from SAGA YUV to the other P96 modes. This way, no video beyond the displayed area is rendered and sizes/offsets are implicitly corrected.

Quote:
Originally Posted by matthey
It may be worthwhile to look into the choice of best mode id and have centering or scaling if the video is narrower than the display (or clipping if the video resolution is larger than the display resolution). A non-PIP window mode and the ability to force a screen mode id and/or resolution could be helpful here for testing even though the switches may have to be changed.
Best Mode ID choice is actually a sad topic with P96. Instead of returning a screenmode that fits the requested dimensions, you get a screen that is quite often smaller than what you asked for. A workaround would be to enumerate all screen modes and re-implement the BestModeID in a custom routine (on the TODO list without "urgency" marker).

Quote:
Originally Posted by matthey
The performance advantage of MOVE16 depends greatly on whether the 16 byte block should be in the DCache afterward or not. If the block is going to be used from the DCache soon then there is little advantage to using MOVE16 as writes from it bypasses the DCache. On the other hand, it could be useful for large and/or streaming data which would otherwise flush the DCache.
True. In this particular case, the data is of the forgetful kind. As there is no way to fit a video frame into the DCache of available 68k CPUs, Move16 really helps a little with performance.

It must be pointed out, however that the loop in question is the "best case" scenario where previous blocks are just cloned for picture areas where nothing changed between frames. Tech side note: MPEG-1 and -2 don't have the inherent "Macroblock skip" abilities of later standards. Current encoders emulate the skip mode by ending a slice when a number of skip Macroblock candidates are present and continue with the next "coded" Macroblock after the skipped blocks by starting a new bitstream fragment.

Updated 68k binary that should hopefully fix a number of the reported issues: http://bax.comlab.uni-rostock.de/fil...A-0.53a0-m68k3

Last edited by buggs; 03 March 2017 at 23:14. Reason: amendment to 3rd paragraph
buggs is offline  
Old 04 March 2017, 02:19   #45
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by buggs View Post
This is actually a curious bug. (Told you there were real bugs in RiVA to be found, no pun intended ). It works with UAEGFX, it works on my A4k but it doesn't work on Apollo when using TrueColor (and your setup). I ported my cropping/centering code from SAGA YUV to the other P96 modes. This way, no video beyond the displayed area is rendered and sizes/offsets are implicitly corrected.
PIP, PIP with FULLPIP, HICOLOR and TRUECOLOR are all displaying correctly here with the new update (despite some resolutions being mildly clipped). Good job and thanks!

The performance is significantly better than RiVA v0.50 too. 320x240 mpegs went from 18-22fps to 21-29fps (NOSKIP, NOAUDIO, PIP FULLPIP) on my 68060@75MHz. Many 320x240 videos are recorded at 25fps giving full speed (no skip) playback. Audio only costs about 1fps more. I updated my post at the following link with the amazing 68060 performance results.

http://eab.abime.net/showpost.php?p=...8&postcount=22

Quote:
Originally Posted by buggs View Post
Best Mode ID choice is actually a sad topic with P96. Instead of returning a screenmode that fits the requested dimensions, you get a screen that is quite often smaller than what you asked for. A workaround would be to enumerate all screen modes and re-implement the BestModeID in a custom routine (on the TODO list without "urgency" marker).
I wonder if this smaller screen size than requested is a bug in the P96 BestModeIDA() patch on some P96 installations?

Quote:
Originally Posted by buggs View Post
True. In this particular case, the data is of the forgetful kind. As there is no way to fit a video frame into the DCache of available 68k CPUs, Move16 really helps a little with performance.
Maybe you could add a MOVE16 CLI switch to turn on a function using the MOVE16 instruction if there is enough difference. It is not difficult to detect for a 68040 or 68060 either. I imagine it is very low priority though.
matthey is offline  
Old 04 March 2017, 14:55   #46
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 883
Quote:
Originally Posted by buggs View Post
Nice screenshot. I actually never tested on AROS.
i actually did, however it simply only displays the first frame. also i have not been able to make it act according to tooltypes. i need to look if the latter is a more general issue, however im not sure how to debug the previous one without some debug output, especially that debug builds are currently broken on aros68k. unfortunatelly im even less familiar with asm and winuae debugger than with c. all i ve been able to catch was strangely that:

Code:
  D0 00000000   D1 07030014   D2 003F0000   D3 00000000 
  D4 0703B970   D5 0703B740   D6 0703B930   D7 00000000 
  A0 070005A4   A1 07034BF0   A2 001FFFB8   A3 00000000 
  A4 00FE8A66   A5 0700056E   A6 070005A4   A7 001FFF9C 
USP  0703B33C ISP  001FFF9C SFC  00000000 DFC  00000000 
CACR 80008000 TC   00008000 ITT0 00000000 ITT1 00000000 
DTT0 00000000 DTT1 00000000 VBR  00C7E000 MSP  00000000 
MMUS 00000000 URP  0701B000 SRP  0701B000 
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=1
00FE6C3C 60d6                     BT .B #$ffffffd6 == $00fe6c14 (T)
Next PC: 00fe6c3e
 H 200
-1 00FE6C3C 60d6                     BT .B #$ffffffd6 == $00fe6c14 (T)
wawa is offline  
Old 04 March 2017, 23:02   #47
Retrofan
Ruler of the Universe

Retrofan's Avatar
 
Join Date: Mar 2010
Location: Lanzarote/Spain
Posts: 5,594
Send a message via Skype™ to Retrofan
Is there any setting I could try to run RiVa with RTG and Picasso in windowed mode?

I say so because the update doesn't work here.
Retrofan is offline  
Old 04 March 2017, 23:52   #48
ShK
Apollo Team
ShK's Avatar
 
Join Date: Mar 2013
Location: Lahti / Finland
Age: 46
Posts: 257
Quote:
Originally Posted by Retrofan View Post
Is there any setting I could try to run RiVa with RTG and Picasso in windowed mode?

I say so because the update doesn't work here.
It should works ok (WinUAE does not have PIP-support):

http://apollo-accelerators.com/files...53a0-m68k3.mp4
ShK is offline  
Old 04 March 2017, 23:58   #49
Retrofan
Ruler of the Universe

Retrofan's Avatar
 
Join Date: Mar 2010
Location: Lanzarote/Spain
Posts: 5,594
Send a message via Skype™ to Retrofan
It should work ok with what? A Vampire? I say the 68k version using Picasso 24bits on WinUAE.
Retrofan is offline  
Old 05 March 2017, 00:04   #50
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by wawa View Post
i actually did, however it simply only displays the first frame. also i have not been able to make it act according to tooltypes. i need to look if the latter is a more general issue, however im not sure how to debug the previous one without some debug output, especially that debug builds are currently broken on aros68k. unfortunatelly im even less familiar with asm and winuae debugger than with c. all i ve been able to catch was strangely that:
I don't see where your debug output gives a reason for the exception/trap. The current PC is 0x00fe6c3c and current instruction looks like 0x60d6 which is showing as a BT.B (B<cc> with Branch True?). The 0x60d6 in binary is 0110000011010110. The first 0110 tells us this is a branch. The next 0000 tells us the condition for the branch which is a BRA (BRanch Always). The last 11010110 is the displacement which looks valid. This looks like a valid and common BRA.B to me. I don't know what is going on with the exception and instruction disassembly. I heard a famous UAE quote once which went something like "turn JIT off and try it".

Quote:
Originally Posted by Retrofan View Post
Is there any setting I could try to run RiVa with RTG and Picasso in windowed mode?

I say so because the update doesn't work here.
There is only one current way I know of to get a window instead of screen and that is with DISPLAY=PIP and FULLPIP settings. This requires your gfx card to have PIP support (Picasso IV, Voodoo 3 and Voodoo 4 but maybe more). PIP provides fast hardware scaling of the display meaning RiVA does not have to. RiVA could probably be enhanced to open a window the size of the video resolution but resizing it would not work without adding some kind of software size scaling (not scaling or fast double/half scaling would be fast and better than no window mode). A window mode would likely be slower to begin with and any kind of scaling would be slower yet but it would be a nice feature on faster Amigas.
matthey is offline  
Old 05 March 2017, 00:13   #51
ShK
Apollo Team
ShK's Avatar
 
Join Date: Mar 2013
Location: Lahti / Finland
Age: 46
Posts: 257
Quote:
Originally Posted by Retrofan View Post
It should work ok with what? A Vampire? I say the 68k version using Picasso 24bits on WinUAE.
It works also on WinUAE (16-bit screenmode is needed):

http://apollo-accelerators.com/files...53a0-m68k3.mp4

Last edited by ShK; 05 March 2017 at 00:21. Reason: e. 16-bit screenmode is needed
ShK is offline  
Old 05 March 2017, 15:18   #52
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 883
with winuae and 3.9 its working without that i set 16bit screen. i still have not got it to work with aros for now.
wawa is offline  
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 AMMX Benchmarks TuKo Amiga scene 82 26 January 2017 20:59
RIVA (68k MPEG Player) is now free NovaCoder News 7 14 March 2016 11:25
RiVA mpeg player amiga request.Apps 18 25 February 2014 10:32
Never released??? tomcat666 project.aGTW 18 18 January 2010 14:44
riva amiga request.Apps 6 12 May 2008 18:56

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 00:26.


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