SRec 2.x on github

	Bottom Previous Topic Next Topic
Register To Post

« 1 (2) 3 4 5 ... 10 »

mufa

Re: SRec 2.x on github

Posted on: 2016/9/29 18:14 #21

Not too shy to talk

I tested more accurately with the CPU Watcher. The results are the same 4% - 11%.

Resized Image

salass00

Re: SRec 2.x on github

Posted on: 2016/9/30 11:05 #22

Just can't stay away

@mufa

Can you try the same with this version?

https://www.dropbox.com/s/rgb1zgqqkiot ... c-2.1r38-prefetch.7z?dl=0

It should make use of altivec pre-fetching.

samo79

Re: SRec 2.x on github

Posted on: 2016/9/30 11:56 #23

Home away from home

@salass00

First italian translation for SRec 2.x ready to commit

http://s000.tinyupload.com/index.php?file_id=07658213279723688916

salass00

Re: SRec 2.x on github

Posted on: 2016/9/30 12:42 #24

Just can't stay away

@samo79

Thanks

. Already committed.

TSK

Re: SRec 2.x on github

Posted on: 2016/9/30 12:53 #25

Just can't stay away

@salass00

- It looks like Odyssey can't download from Dropbox. I had to use a Mac to download the file.

- r38 crashed on X1000

- Could you implement shorts for command line arguments like W=WIDTH and H=HEIGHT ?

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray

TearsOfMe

Re: SRec 2.x on github

Posted on: 2016/9/30 13:12 #26

Just popping in

@TSK

A hint for Dropbox links: Copy the url and change at the end
"dl=0" to "dl=1" then it should direct download the file.

mufa

Re: SRec 2.x on github

Posted on: 2016/9/30 13:42 #27

Not too shy to talk

@salass00

The latest version of the system freezes after a few seconds of recording.

salass00

Re: SRec 2.x on github

Posted on: 2016/9/30 14:35 #28

Just can't stay away

@mufa & TSK

Edit: I'm getting crashes here as well so it looks like it's related to some other code change and not to do with altivec. I will upload a new binary to test when I've fixed this.

Edited by salass00 on 2016/9/30 14:53:43

TSK

Re: SRec 2.x on github

Posted on: 2016/9/30 14:57 #29

Just can't stay away

@salass00

No problems with r41 prefetch version.

Using these: WIDTH=1920 HEIGHT=1080 FPS=60 the computer is fast to use while recording. But watching the resulting video plays like the recording skipped a lot of frames.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray

broadblues

Re: SRec 2.x on github

Posted on: 2016/9/30 14:58 #30

Home away from home

@mufa

I think the CPU watcher may be giving overly optimistic CPU results, monitoring with CPUInfo docky I see avarages of 95% tp 100% for the old version and 35 to 40 % for the new.

That's recording 1920x1080 at 10fps. Saving the result in RAM:

I also don't see much change in CPU usage when switching to NOALTIVEC.

@salas00

Still a good speed up well done!

Blender For OS4.x : Blues : Walker Broad

broadblues

Re: SRec 2.x on github

Posted on: 2016/9/30 15:03 #31

Home away from home

@TSK

Quote:

Using these: WIDTH=1920 HEIGHT=1080 FPS=60 the computer is fast to use while recording. But watching the resulting video plays like the recording skipped a lot of frames.

There's no way you could record at 60 fps, the SRec process is just gving way to the main activities, and effectivley skipping frames.

If you want that kind of performnce you will external hardware (or maybe on video card encoding via a shader of some kind).

Blender For OS4.x : Blues : Walker Broad

broadblues

Re: SRec 2.x on github

Posted on: 2016/9/30 15:07 #32

Home away from home

@TSK

Quote:

- Could you implement shorts for command line arguments like W=WIDTH and H=HEIGHT ?

The template doesn't use keywords so you can just type the args in order if you want to reduce typing ie

rram:SRec ram:out.avi 1920 1080 10

Blender For OS4.x : Blues : Walker Broad

salass00

Re: SRec 2.x on github

Posted on: 2016/9/30 15:45 #33

Just can't stay away

@mufa & TSK

Please try this version and do a comparison of with and without NOALTIVEC:
https://www.dropbox.com/s/yksdnjv4jbes4sw/srec-2.1r43.7z?dl=1

I disabled the incremental VRAM to RAM transfer code for now because it causes random crashes for me. Not sure why...

The code is in src/zmbv.c (lines 370-398) if anyone wants to look it over. If there is something wrong with it then I can't see it. The sched_yield() I added in between the calls to BltBitMapTags() just to see if it would help (it didn't).

Georg

Re: SRec 2.x on github

Posted on: 2016/9/30 16:19 #34

Just popping in

@salass00

Quote:

The code is in src/zmbv.c (lines 370-398)

The last blit after the while loop may have a 0 blit height.

salass00

Re: SRec 2.x on github

Posted on: 2016/9/30 16:37 #35

Just can't stay away

@Georg

It shouldn't because the loop is only run while rows_left is greater than max_rows and it only handles max_rows so there should always be at least one row that is handled outside of the loop.

Turns out that the incremental transfers change was just a placebo and the real cause of crashes was something else entirely:

https://github.com/salass00/srec/commi ... 9d62d414caa2d8b7f613d678f

Edit: I guess max_rows could theoretically be calculated as zero if width is high enough (bytes per row is higher than MAX_VRAM_TO_RAM_TRANSFER_SIZE). That is something I will have to fix, so thanks for the hint

salass00

Re: SRec 2.x on github

Posted on: 2016/9/30 16:40 #36

Just can't stay away

Quote:

@mufa & TSK

Please try this version and do a comparison of with and without NOALTIVEC:
https://www.dropbox.com/s/yksdnjv4jbes4sw/srec-2.1r43.7z?dl=1

I disabled the incremental VRAM to RAM transfer code for now because it causes random crashes for me. Not sure why...

The code is in src/zmbv.c (lines 370-398) if anyone wants to look it over. If there is something wrong with it then I can't see it. The sched_yield() I added in between the calls to BltBitMapTags() just to see if it would help (it didn't).

Forget the above version and use this one instead:
https://www.dropbox.com/s/nnuzvh6yi54tf6n/srec-2.1r46.7z?dl=1

TSK

Re: SRec 2.x on github

Posted on: 2016/9/30 17:34 #37

Just can't stay away

@salass00

After very quick test no problems with r46.

@Andy + salass00
I didn't mean it literally. It doesn't matter if FPS is 1-25 the result doesn't change. I thought people can choose themselves depending on how fast machines they have.

@salass00
I thought people comparing the old and the new versions if the speed up comes from new code or fixed fps.

Rock lobster bit me - so I'm here forever
X1000 + AmigaOS 4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray

salass00

Re: SRec 2.x on github

Posted on: 2016/9/30 18:26 #38

Just can't stay away

@TSK

I could add some code to measure how long encoding each frame takes and then when it's all over calculates an average from this.

This would probably be more accurate than using external CPU measurers so it's something I will add to my to do list.

salass00

Re: SRec 2.x on github

Posted on: 2016/10/1 14:29 #39

Just can't stay away

Recording from the GUI is now implemented:

https://www.dropbox.com/s/lx0yr7t6s0s935s/srec-2.1r61.7z?dl=1

Some things that are not yet implemented is recording/rendering the pointer and saving settings as default for the GUI.

The GUI works the same as in SRec 1.x in that it can be run in the background like a commodity and you can set special button combinations for starting and stopping recording through the icon tooltypes.

tommysammy

Re: SRec 2.x on github

Posted on: 2016/10/1 15:20 #40

Quite a regular

@salass00 i made screen recording, but no player can play the output file.
I could create german catalog if you like

Amiga600/Vampire2/PrismaMegaMix/32GB CF Card/2x Rys Mk2/A604n/IndivisionECS/Gotek

Register To Post	« 1 (2) 3 4 5 ... 10 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 3 ( 0 members and 3 Anonymous Users )