Hi all,

I think it is too early to submit profiling information. We should first make some decisions such as:

- which version of x264 do we profile?
should we just pick the latest daily snapshot? should we pick up the latest stable release? should we pick a certain daily snapshot and stay with it?

- how to configure x264 for profiling before compilation?
I suggest the following:

I think we should disable what we can for simplicity of profiling. We should, of course enable gprof for profiling, but not the other options, since we do not debug the code, and we want to keep it simple.

- what parameters use when executing x264?
I suggest --profile baseline to be the only option, so we begin with the baseline profile. Maybe on a later stage of the project we can do main, and/or extended profiles as well.

- What platform to use for profiling?
I think that each one of us should use its own platform. since we do not use (yet) cpu enhancements, it shouldn't affect the profiling. There was a suggestion to use the openRisc emulator, but I think that at this stage, it might

let us discuss and decide these things. After we reach agreement, we should upload one executable (actually two, one for linux and one for windows) that everyone will use for profiling. Then I think we should upload the gmon.out file, and not text files, since It is important to have the executable and the gmon.out file for reading the profiling info with some tools such as kprof and gprof2dot.py.

- gil

Damn, I miss the EDIT and PREVIEW options on this board...
slow our advance. I'm also not sure how long it will take to encode a decent YUV file (say 2000 frames and more) on the emulator. I think we should leave this option for later stage. It also seems to me, from the profiles already uploaded and from profilings I did myself, that the choice for the functions to be implemented by HW will be straightforward.

- gil

As a request to help the S/W newbies, may I suggest

either a sticky in the .264 section OR a text file uploaded to the .264 repository
that describes the steps performed in order to go through the builds and an example to execute the profiling with a certain input file to be encoded to .264 ?


As Gil pointed out, this is described in bits and pieces,in this thread, which is what I used. However, I got stuck at one point where I had to specify an input file for encoding and the CIF files I downloaded seems to be already encoded into .264(based on the extension)

It is confusing.

I went through the Doom9 forums and felt that we need to spend too much time to search for compile and execute information. Everyone makes an assumption that developers/end users compiling source files know all the basic syntax and semantics of building and experimenting with various options.

Maybe, I am the only one here who is having problems:(

then, I agree with you,
1)we may stay with "x264-snapshot-20090901-2245.tar.bz2", snapshot of the first day of September, there is no need to pursue with the latest version.
2)./configure --disable-avis-input --disable-mp4-output --disable-pthread --disable-asm --enable-gprof
3)./x264 --profile=baseline -o test.264 test.yuv widthxheight, just use the simplest parameter
4)use our own platform, the time of running x264 on OpenRISC maybe too long to slow our process and there are lots of papers to instruct us which to be implemented by HW. then the time infomation provided by gprof may not be used because of different platform configuration, we can only use the calls info. but it's ok, because we need only the relative info.
5)we may have different person to do profiling with different source resolution, such as QCIF, CIF, D1, etc, each > 100 frames. then give a conclusion

Then, I think there is only one things to be decided, how can we get proper HW/SW patition by the the information provided by GPROF? hope am right^_^


Brian

Hi,
FYI there is some applications that makes analyzing gprof files easier.

http://code.google.com/p/jrfonseca/wiki/Gprof2Dot
http://code.google.com/p/jrfonseca/wiki/XDot

Br,

Hi,

I uploaded x264 file compiled on linux from x264-snapshot-20090901-2245.tar.bz2 to /oc-h264-encoder/trunk/doc/x264_profiling/bin/x264 using:
./configure --disable-avis-input --disable-mp4-output --disable-pthread --disable-asm --enable-gprof

let us use this executable for profiling for now. could someone update the x264_cygwin.exe to one compiled from the same snapshot?

-gil

I suggest the following procedure for profiling:

1. use the executable from the repository /oc-h264-encoder/trunk/doc/x264_profiling/bin/x264 for encoding the .yuv file, using the format:


2. Check that the output test.264 is correct. you can play it on vlc player and check that it looks like the original .yuv file.

3. upload the gmon.out file made by the execution of x264 to the repository:

name it as follows:


for example:


4. when commiting, let the comment include the following info:


for example:


I think it would be good to start with the files from:
http://trace.eas.asu.edu/yuv/

After we get enough gmon.out files, we can check their relative computation intensive functions and start debating which parts to implement in HW.

- gil

Important NOTE: gmon.out file will accumulate results of the executable (x264 in our case). Therefore, you must delete it before any execution of x264 that is used for profiling. gmon.out will even collect profiling info for executing x264 -h

- gil

Hi,
is there any point in doing any profiling on a 64 bit PC platform?

//Burra

There is no problem I can see with that (could anyone correct me if I'm wrong?), since we use a relative profiling data and not the absolute data. Please mention it in the comment when checking-in to the repository.

- gil

Hi,
have tried to run gprof2dot on the akiyo_cif_profile.data file from svn. Are these pics of any use?

To have a look at it on:
http://imagebin.org/62844

//Burra

hi, gil, I did the GCC profiling as you said, but result is a little stranger. I use
Red Hat Enterprise Linux Server release 5.1 (Tikanga)。

Is the step as following,

1 ./configure --disable-avis-input --disable-mp4-output --disable-pthread --disable-asm --enable-gprof

2 ./x264 --profile=baseline -o test.264 test.yuv widthxheight

3. gprof -b x264 gmon.out | less > result.txt

But my result seems wrong. Pls help me check the attached profiling file.

Seems like CPU extensions have been used. In the README file in SVN the --disable-asm parameter is not present.

I got a similar result when running without the --disable-asm parameter

//Burra

Hi Burra,

These pictures are useful for comprehending the code and the accumulated computing intensive path. These pictures are not so useful for singling-out the most computing intensive functions, seems it highlights accumulated data.
Anyway, I find it more useful to generate .dot files with gprof2dot.py and inspect those using xdot.py
I think one should upload its gmon.out files to the repository (with information about its source). In your case, you should upload your executable to the repository as well (/oc-h264-encoder/trunk/doc/x264_profiling/bin), and rename it to something like x264_64bit

Anyone having the executable and the gmon.out files can generate gprof info, .dot files, pictures such as the one you created, and inspect the profiling results with tools of his/her choice.

BTW, you can attach files to your posts.

Burra,

Could you please post the ./configure --... command you use and the output you get?
Could you also post the gmon.out file and the x264 executable you used, so I could open the results using xprof?

- gil


- gil