keeleysam / tenfourfox

Automatically exported from code.google.com/p/tenfourfox
0 stars 0 forks source link

Fx15: libvpx 1.0 breaks vmx accelerated idct #166

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
For libvpx 1.0 the vmx accelerated idct has to be extended to match the c 
version.

Original issue reported on code.google.com by Tobias.N...@gmail.com on 12 Jun 2012 at 10:19

GoogleCodeExporter commented 9 years ago

Original comment by Tobias.N...@gmail.com on 13 Jun 2012 at 7:11

GoogleCodeExporter commented 9 years ago
libvpx 1.1.0 came out on May 11, 2012. Better decoder speed (2.5% vs. 1.0.0) 
and a bug fix to the decoder in 1.0.0 are noted in the change log.

Original comment by jquino...@santaritaschools.org on 12 Jul 2012 at 7:05

GoogleCodeExporter commented 9 years ago
We're not going to take 1.1.0 before Mozilla does, though, and Mozilla is 
already using that bug fix in their own patches.

Original comment by classi...@floodgap.com on 12 Jul 2012 at 12:53

GoogleCodeExporter commented 9 years ago
This compiles now. I will test it fully when the build is done.

Original comment by classi...@floodgap.com on 12 Jul 2012 at 4:06

GoogleCodeExporter commented 9 years ago
And it works. I consider this fixed, unless there was something else you 
noticed about it. I didn't have to do anything to the IDCT, just tweak a couple 
of the header files.

Original comment by classi...@floodgap.com on 12 Jul 2012 at 11:27

GoogleCodeExporter commented 9 years ago
While your patch restores the postprocessing which I had disabled as a 
workaround it doesn't make the IDCT work again.

dequantize.c was moved to vp8/common/, the call to the IDCT has to be changed 
from "vp8_short_idct4x4llm_c(input, dest, stride, dest, stride)" into 
"IDCT_INVOKE(rtcd, idct16)(input, dest, stride, dest, stride)", but here we 
cannot use our altivec accelerated IDCT because the interface of that IDCT 
function was heavily changed.

Original comment by Tobias.N...@gmail.com on 14 Jul 2012 at 9:44

GoogleCodeExporter commented 9 years ago
Sounds like it's just a matter of inserting a shim, no? (I'm back in a debug 
build of 15 to deal with typed arrays.)

Original comment by classi...@floodgap.com on 14 Jul 2012 at 2:57

GoogleCodeExporter commented 9 years ago
The function call now passes an additional stride parameter to the IDCT which 
specifies input and output format. And the former pitch parameter doesn't exist 
anymore.

I  think we could also use the example IDCT routines provided by Apple:
https://developer.apple.com/hardwaredrivers/ve/examples.html
https://developer.apple.com/hardwaredrivers/ve/downloads/altivecPBExample.sit.hq
x

The attached file is from the download above and should contain exactly what we 
need: 8x8 IDCT for 16 bit integer values. Shouldn't be that difficult enhancing 
it to accept stride values for input and output format.

Original comment by Tobias.N...@gmail.com on 15 Jul 2012 at 12:03

Attachments:

GoogleCodeExporter commented 9 years ago
Attached comes a patch (libvpx_1.0_idctllm_altivec) that makes the Altivec IDCT 
work as is, by reincorporating some code from libvpx 0.9.7 .

The second patch (from my mercurial queue) makes sure that the Altivec IDCT 
can't be invoked anymore the normal way - which was only done in the encoder as 
far as I could find out.

Original comment by Tobias.N...@gmail.com on 18 Jul 2012 at 7:02

Attachments:

GoogleCodeExporter commented 9 years ago
Nice work. Apply the disable patch first, then the second one?

I'm still working on the widget issue, then I'll flip over to G5 opt and try 
this. Do you notice a speed improvement?

Original comment by classi...@floodgap.com on 18 Jul 2012 at 7:28

GoogleCodeExporter commented 9 years ago

Original comment by classi...@floodgap.com on 18 Jul 2012 at 7:28

GoogleCodeExporter commented 9 years ago
The disable patch isn't strictly necessary and the other one will work without 
it.
Maybe the disable patch is necessary if you want to use WebRTC (which is new in 
the tree) to host streams.

Original comment by Tobias.N...@gmail.com on 18 Jul 2012 at 7:34

GoogleCodeExporter commented 9 years ago
Then let's use the disable patch for now. We can always back it out later. I 
doubt, however, that WebRTC will perform well enough on most systems to be 
workable for us.

Original comment by classi...@floodgap.com on 18 Jul 2012 at 7:37

GoogleCodeExporter commented 9 years ago
With some small tweaks WebRTC did even build fine here.

Original comment by Tobias.N...@gmail.com on 18 Jul 2012 at 7:48

GoogleCodeExporter commented 9 years ago
What tweaks?

Original comment by classi...@floodgap.com on 18 Jul 2012 at 7:49

GoogleCodeExporter commented 9 years ago
They'll be available in the changeset I'll upload to the aurorafox project 
site. Two gcc-4.6 ObjC++ issues and a few things missing in the makefiles.

Original comment by Tobias.N...@gmail.com on 18 Jul 2012 at 7:52

GoogleCodeExporter commented 9 years ago
For libvpx IDCT I can't tell if there is a difference because playback speed is 
hardly reproducibly here.

Original comment by Tobias.N...@gmail.com on 18 Jul 2012 at 8:01

GoogleCodeExporter commented 9 years ago
On the AuroraFox download page 
(http://code.google.com/p/aurorafox/downloads/list) I now uploaded my latest 
mercurial patch queue which, among others, contains a patch with the changes 
necessary for building WebRTC (powerpc_build_fixes_misc.patch).

Original comment by Tobias.N...@gmail.com on 19 Jul 2012 at 10:17

GoogleCodeExporter commented 9 years ago

Original comment by classi...@floodgap.com on 23 Jul 2012 at 1:47

GoogleCodeExporter commented 9 years ago
shipp'd

Original comment by classi...@floodgap.com on 24 Aug 2012 at 12:11