Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - OS4User

Pages: 1 ... 14 15 [16] 17 18 ... 28
226
Applications / Re: OS/4 (technical details only)
« on: March 11, 2019, 07:07:13 am »
Dave, I am still getting traps.  This is with the FF sandybridge, OS/4 kernel SVN5452 and your latest libs

Dave,

It is because of wrong alignment  of   _ff_cos_32:
Code: [Select]
vmovaps ymm0, yword [_ff_cos_32]
fft.asm      Line 182

227
Applications / Re: OS/4 (technical details only)
« on: March 10, 2019, 11:20:22 am »
Code: [Select]
Segment                Class          Group          Address         Size
=======                =====          =====          =======         ====

TEXT32                 CODE           CGROUP         0001:00000000   009fe590
________TEXT           CODE           CGROUP         0001:009fe590   00000000
text                   CODE           AUTO           0002:00000000   000ca2cb
DATA32                 DATA           DGROUP         0003:00000000   0001d990

try this addition  to  x86inc.asm:
Code: [Select]
; NOTE: This section is out of sync with x264, in order to keep supporting OS/2
%ifidn __OUTPUT_FORMAT__,obj
    %define .text TEXT32
    SECTION .text align=4 public use32 FLAT class=CODE
%endif
it should avoid altering 118 .asm files and remove "text                   CODE           AUTO"
Better to keep this after  definition of SECTION_RODATA macro

228
Applications / Re: OS/4 (technical details only)
« on: March 10, 2019, 08:01:07 am »
It  looks  like there is  more straight way  -  select  win32 format for nasm output:  -f win32
No changes  to sources  will be necessary.

How to get the symbols to put in the def file? The assembler and compiler object files are mixed together. Currently use emxexp, which pukes on the win32 object files.

What .def ?  Do you need it for some purpose ?

I would like to see avcode57.map  if you give to nasm  -f win32 with this definition of macro:
Code: [Select]
%macro SECTION_RODATA 0-1 16
        SECTION .rodata align=%1
%endmacro

I did not understand if you try suggestion from https://www.os2world.com/forum/index.php/topic,1735.msg20846.html#msg20846  -  pls clarify

229
Applications / Re: OS/4 (technical details only)
« on: March 09, 2019, 07:53:29 am »
Here's the disassembly of fft.asm in nasm format. If I understand it correctly, the constants are at the bottom of the file in the rodata32 section and aligned to 32 bytes.
It appears the align directive aligns the whole section.

Better to see in  avcode57.map   at  0004:00000700  ps_cos16_1   - it is pretty good aligned 256 as expected

(I sent you private message - pls see)

Upd:

It  looks  like there is  more straight way  -  select  win32 format for nasm output:  -f win32
No changes  to sources  will be necessary.

230
Applications / Re: OS/4 (technical details only)
« on: March 09, 2019, 07:45:37 am »
Still have too many segments though, TEXT32, text and DATA32.

Wrong segments are:
text                   CODE           AUTO
rodata32               DATA           AUTO

These segments were generated from .asm  (by nasm)  -  I do not know how to tell to nasm that    text  has to be in CGROUP  and  rodata32 has to be in DGROUP

We can try to do this way:

after
Code: [Select]
SECTION .rodata32 align=256 public use32 FLAT class=DATA
add
Code: [Select]
group DGROUP rodata32

after
Code: [Select]
SECTION .text align=4 public use32 FLAT class=CODE
add
Code: [Select]
group CGROUP text

by the way, if we are going to change macro SECTION_RODATA  what  __OUTPUT_FORMAT__  it should  be ready for ?

231
Applications / Re: OS/4 (technical details only)
« on: March 09, 2019, 12:05:21 am »
Same error.

I am not very good in nasm macro  so for test  you can use  this variant:

Code: [Select]
%macro SECTION_RODATA 0-1 16
        SECTION .rdata align=256 public use32 FLAT class=DATA
%endmacro

hope you give to nasm  -f obj

Anyways there are bigger problems, still using 64kb segments

Did you add

Code: [Select]
%ifidn __OUTPUT_FORMAT__,obj
    SECTION .text align=4 public use32 FLAT class=CODE
%endif

as it was suggested ?

It looks like did not   - that is why you have:

"text                                  AUTO"

and "still using 64kb segments"

---------------

Error! E2028: ff_h264_cabac_tables is an undefined reference  but you have
0001:0010af60  _ff_h264_cabac_tables

it is another story  - may be suggestion from Lars will help https://www.os2world.com/forum/index.php/topic,1735.msg20825.html#msg20825

232
Applications / Re: OS/4 (technical details only)
« on: March 08, 2019, 10:33:56 pm »
Doesn't like the
Code: [Select]
if %1 = 16 part,

try
Code: [Select]
   if %1 == 16

233
Applications / Re: OS/4 (technical details only)
« on: March 08, 2019, 06:32:17 pm »
There's 81 instances of SECTION .text just in libavcodec which I assume aren't getting the use32 FLAT directive.

You may try the following modification:

Code: [Select]
; aout does not support align=
; NOTE: This section is out of sync with x264, in order to
; keep supporting OS/2.
%macro SECTION_RODATA 0-1 16
    %ifidn __OUTPUT_FORMAT__,aout
        SECTION .text
    %elifidn __OUTPUT_FORMAT__,coff
        SECTION .text
    %elifidn __OUTPUT_FORMAT__,obj
        if %1 = 16
            SECTION .rdata align=16  public use32 FLAT class=DATA
        %elif
            SECTION .rdata align=256 public use32 FLAT class=DATA
        %endif
    %elifidn __OUTPUT_FORMAT__,win32
        SECTION .rdata align=%1
    %elif WIN64
        SECTION .rdata align=%1
    %else
        SECTION .rodata align=%1
    %endif
%endmacro

after definition this macro in x86inc.asm  add:

Code: [Select]
%ifidn __OUTPUT_FORMAT__,obj
    SECTION .text align=4 public use32 FLAT class=CODE
%endif

AFAIK  no other changes  are necessary.

To check compilation and linking  add: 
Code: [Select]
global ps_cos16_1
before
Code: [Select]
ps_cos16_1: dd 1.0, M_COS_PI_1_8, M_SQRT1_2, M_COS_PI_3_8, 1.0, M_COS_PI_1_8, M_SQRT1_2, M_COS_PI_3_8
this way we could come to know if ps_cos16_1 is in proper segment with proper alignment

After compilation I would like to see avcode57.map too  :)

234
Applications / Re: OS/4 (technical details only)
« on: March 08, 2019, 08:50:34 am »
Dave

I have done some testing for -f flag for nasm command line:

1) coff: does not support align=:
"test1.nasm:1: error: standard COFF does not support section alignment specification"

2) win32:  seams does not support class=  and my test var comes  to code seg
but align=32 works ok

3) aout:  does not support align=  and other directives

4) obj:  what is most surprising OBJ  supports align=256 !!! and var comes to proper data seg

wlink and wl work with 1) 2) 4)

Variant 4 for me most preferable.

So macro should be like this:

Code: [Select]
; aout does not support align=
; NOTE: This section is out of sync with x264, in order to
; keep supporting OS/2.
%macro SECTION_RODATA 0-1 16
    %ifidn __OUTPUT_FORMAT__,aout
        SECTION .text
    %elifidn __OUTPUT_FORMAT__,coff
        SECTION .text align=%1
    %elifidn __OUTPUT_FORMAT__,obj
        SECTION .DATA32 align=%1 public use32 FLAT class=DATA
    %elifidn __OUTPUT_FORMAT__,win32
        SECTION .rdata align=%1
    %elif WIN64
        SECTION .rdata align=%1
    %else
        SECTION .rodata align=%1
    %endif
%endmacro

add to nasm command line:  -f obj  (instead of -f aout)

SECTION_RODATA 256    in   fft.asm line 54 ( if you do not like warning  "OBJ format does not support alignment of 32: rounding up to 256")

This way you will  get proper  fft.obj  which can be directly given to wl without any conversion.

235
Applications / Re: OS/4 (technical details only)
« on: March 08, 2019, 07:48:41 am »
Well, as I said, GCC actually puts out aout. Currently the nasm output is getting converted at link time to OMF as fewer changes were needed

Dave, AFAIK  OMF does not support 32 bit alignment.

For test purpose you can replace:

Code: [Select]
SECTION_RODATA 32     in   fft.asm line 54
with
Code: [Select]
SECTION .rdata align=32 public use32 FLAT class=DATA

Try to get from nasm   coff or win32  format,  but I am not sure if linker will accept this.
(What linker do you use ?)   -   may be wl  will be required.


236
Applications / Re: OS/4 (technical details only)
« on: March 07, 2019, 07:34:56 pm »
Problem is testing as I don't have AVX hardware.

As indirect way you can describe ps_cos16_1  as Public  and always check its address and segment in map file. And, of course, we can ask David to test AVX ver with proper alignment (at least I hope). 

For some reason  ps_cos16_1 comes to CODE seg (.text ?)  but not to .rdata with proper alignment.
 

237
Applications / Re: OS/4 (technical details only)
« on: March 07, 2019, 11:15:25 am »
Hi Dave,

The fallen instruction is (function fft8_avx):
Code: [Select]
mova       m4,  [ps_cos16_1] ; vmovaps

static variable ps_cos16_1 is 16 bit aligned only (0001:009AE730,  yes it is in code seg)

ref.: https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/x86/fft.asm line 346

AFAIK  the following variables have to be 32 bit aligned too:
Code: [Select]
ps_cos16_2
ps_root2
ps_root2mppm
ps_p1p1m1p1
perm1
perm2
ps_p1p1m1p1root2
ps_m1m1p1m1p1m1m1m1
ps_m1p1

238
Applications / Re: OS/4 (technical details only)
« on: March 06, 2019, 08:56:26 pm »
Dave:

So anyways need to redownload the libs package.

After redownload https://bitbucket.org/dryeo/mozilla-os2/downloads/ffmpeg-3.2.13-libs.zip and installation of  ALL the libs from it  youtube came back.

Theseus also confirms that  avcode57 is in use and avcode56 is no longer in use.

So we need to test new ffmpeg on AVX equipment.


David:

Looking forward to your test of updated  ffmpeg.


239
Applications / Re: OS/4 (technical details only)
« on: March 06, 2019, 06:33:23 pm »
Hi Dave

It seams I am missing your point with replacement of ffmpeg libs.
I understand you offer to replace avcode56.dll/avutil54.dll with avcode57.dll/avutil55.dll.
But how FF will come to know to use this new pair ?
For a sake of testing I did such replacement on my comp and youtube disappeared.
I am not sure but looks like FF has to be rebuilt against this new pair of libs.

(I do not have an AVX equipment to do a proper test.)

At the same time thanks a lot for building AVX  binaries - it's obvious that this technology has to be available for our community too.

240
Applications / Re: OS/4 (technical details only)
« on: March 05, 2019, 04:45:39 pm »
I just tried the SandyBridge version with the lastest OS/4 kernel and FF works now

try this http://hobbes.nmsu.edu/download/pub/incoming/freerdp-wpi-20190301.zip
it also requires AVX

Pages: 1 ... 14 15 [16] 17 18 ... 28