RiVA v0.52 Released

[Retrofan]

Let's see: With Picasso 24bit TRUECOLOR works, but just like I linked in post 26

It was the same with Riva 050

[matthey]

Originally Posted by buggs

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.

Originally Posted by buggs

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.

[buggs]

Originally Posted by AMIGASYSTEM

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]

Originally Posted by matthey

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.

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.

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).

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

[matthey]

Originally Posted by buggs

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

Originally Posted by buggs

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?

Originally Posted by buggs

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.

[wawa]

Originally Posted by buggs

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:

  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)

[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.

[ShK]

Originally Posted by 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.

It should works ok (WinUAE does not have PIP-support):

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

[Retrofan]

It should work ok with what? A Vampire? I say the 68k version using Picasso 24bits on WinUAE.

[matthey]

Originally Posted by wawa

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".

Originally Posted by 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.

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.

[ShK]

Originally Posted by Retrofan

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

[wawa]

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.

[bbond007]

I have an Amiga 1200/060/50mhz with Indivision

I have been using (my) registered version .050.

I Downloaded .052 to give it a try, but I notice it behaves very differently using AGA for me.

With the older version using the DISPLAY=DHAM8 the image quality looks very good with lots of colors and smooth shading.

Using .052 the image quality looks heavily dithered with a much reduced color palette. I got the same result with the .053 version. Any idea whats going on here?

Also in the older version the pressing the space bar would switch between HalfHeight and Normal modes which I understood allowed for faster playback (in AGA mode) while sacrificing some quality. Now the space bar seems to pause and resume video, which is fine, but is there a new key for the HalfHeight/Normal toggle?

Thanks!
nate