Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSE2 implementation of JPEG loader crashes on 32bit builds. #5

Closed
SpartanJ opened this issue Feb 5, 2015 · 17 comments
Closed

SSE2 implementation of JPEG loader crashes on 32bit builds. #5

SpartanJ opened this issue Feb 5, 2015 · 17 comments
Labels
bug Something isn't working major

Comments

@SpartanJ
Copy link
Owner

SpartanJ commented Feb 5, 2015

Original report by RoestVrijStaal (Bitbucket: RoestVrijStaal, GitHub: RoestVrijStaal).


Hello,

I try to compile SOIL2 but my attempts with standalone MinGW-w64 with its own command line and Code::Blocks inclusive MinGW-64 failed.

The most successful result was with Code::Blocks after adding -msse2 as extra compiler flag.

However, test_perf_SOIL2.cpp SIGSEGs in SSE2 instructions again.

Which compiler + flags (and IDE) do you use?

@SpartanJ
Copy link
Owner Author

SpartanJ commented Feb 5, 2015

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


I doesn't need any compiler flag in particular, it should work without problems with MingW-64 ( it's what i'm using by the way ).
May be you can share me your test project to see if i see something wrong, and also send me the image that's segfaulting.
You can also try to compile it generating the Makefiles with premake4. Just download premake4 and do premake4 gmake, it will generate the Makefile in make/windows subfolder.

@SpartanJ
Copy link
Owner Author

SpartanJ commented Feb 8, 2015

Original comment by RoestVrijStaal (Bitbucket: RoestVrijStaal, GitHub: RoestVrijStaal).


I tried to compile SOIL2 with premake4 in the beginning, but make / mingw32-make ignores environment variables so I gave up on trying to compile via command line.

After experimenting, I noticed it seem only to apply to jpeg loading. At other formats like bmp, png and tga loading and using goes fine.

I tried different jpgs, but it ends up in the same result.

The segmentation fault occurs in emmintrin.h, rule 670, initiated by rule 1508 in stb_image.c.

// emmintrin.h (r605)

return extension (__m128i)(__v8hi){
__q0, __q1, __q2, __q3, __q4, __q5, __q6, __q7 };

// stb_image.c (r1508)

__m128i rot0_0 = dct_const(stbi__f2f(0.5411961f), stbi__f2f(0.5411961f) + stbi__f2f(-1.847759065f));

ATM I'm using MinGW-w64 i686-4.9.2-posix-dwarf-rt_v3-rev1 on Win7 x84_64. The same occurs on a Win7 x86_32.

Here are the links to the test projects:

http://go4up.com/dl/d8ee78678e79/SpartanJ-soil2__test_perf_SOIL2.rar

http://go4up.com/dl/de0a9112f8fb/SpartanJ-soil2__test_SOIL2.rar

@SpartanJ
Copy link
Owner Author

SpartanJ commented Feb 8, 2015

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


It seems to be a compilation problem, since i compiled the project by myself and worked fine with jpgs, but your project crashes with the jpg files.
I pushed some minor fixes to the JPG SSE2 implementation in stb_image, but i don't think that was your problem.

I used TDM-GCC, i'm not using the same mingw as you, so, i recommend you to try it. You should not have the SDL2 include problem, just copy the files as they come in the SDL2 for mingw file and it'll work.

Before doing anything pull and update the SOIL2 repo with the new changes.

Please try to compile the project again updating the repository, creating the project width premake4 ( premake4 gmake or premake4 codeblocks ), and try to use TDC-GCC that it's working fine, copy the SDL2 stuff to the TDM-GCC folder ( copy the x86_64-w64-mingw32 directory, that's what you should be using for x64, otherwise i686-w64-mingw32 ), and that should be enough.

Regards

@SpartanJ
Copy link
Owner Author

Original comment by CHAOS-THEORY (Bitbucket: CHAOS-THEORY, GitHub: CHAOS-THEORY).


Yo ! wassup,
I can't believe i registered here and i don't even know what this website is up for lel.
Anyway, since i saw you had that issue into your website notification toolbar i decided to put ma noise in and tell you that it compiled fine under GNU GCC Compiler in a 32b architecture with the default settings, 0Warns 0Errors. So it shouldn't be an issue here, you might remove it as it faked me that this library is in alpha release and will be causing troubles for my future development and am sure it will fake other users as well;
Here i'll point you out a bit just to take out all the useless prethinking over the author's head.
< I couldn't know a good place to put this tiny tutorial in so i ll just post here >
< Please wait for the images if they are slow to load (the images i uploaded) >
In CODE::BLOCKS (am using the latest version and so should you).

  • Create a new 'Project'

Project - New.png

  • Then choose from 'Project', 'Static library'
    Project - Static lib.png

  • Then press 'Next', write the name you want and choose the folder you want.

  • Then 'Next' and 'Finish'

Now that you are here with a new Static Lib. project.

  • Go to your project in your management Bar on the left or wherever you have it.
  • Delete the 'main.cpp' file cause you wont need it, by right clicking it and then 'Remove file from project'.

delete from project.png

  • Now right click on your project, then press 'Add files recursively' then press 'Ok'.

add files recursively.png

  • Then choose the folder in which all the source files are located, in this case the 'SOIL2' folder which comes in the download repository under the main folder 'SpartanJ-soil2-eb2ea0ba2f61' and so on the 'src' folder.
    choose the soil folder.png

  • After pressing 'Ok', press 'Select all' to select all the files inside.

Select all and oke.png

  • Then choose both 'Debug' and 'Release' as you might be working with both.
    Then press 'Ok'...

  • As you can see all the files have been added recursively and successfully to your project.

files added.png

  • Now you can go ahead and compile your lib. If it's successful go ahead and change to release so you can use it.

build bytch.png

Else if you followed this tut correctly and failed, please report back with all the errors and warnings returned by your compiler.

succces nigga.png

And finally i have uploaded it for you, the whole project including the library compiled if you ever need it. And don't forget am using the 32b architecture under winxp, go ahead and use it compile it.

SOIL2 - LIB - AK' Download < Hosted by OneDrive >

< Updated, added the release Lib as well >

Good luck and Peace yo !

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


Wow, that's a lot of work, thanks for the comment.
But i must say that it wasn't necessary. The premake file that comes with the project it's exactly to avoid all that work, since you can just make premake4.exe codeblocks and it ill generate the projects ( the static lib and the demos ) in the sub-folder make\windows inside the project, and it works just fine, the only thing that you may want to change is the executable directory, since it's not detected correctly by premake.
I'll add this information in the project README to avoid confusion.

Regards!

@SpartanJ
Copy link
Owner Author

Original comment by CHAOS-THEORY (Bitbucket: CHAOS-THEORY, GitHub: CHAOS-THEORY).


An i actually didn't notice it till now, ma bad since i didn't read the whole post and skipped directly to compiling from codeblocks, thought it would be better to just give a graphical view on how to compile it to have a better understanding on the error.
Well peace yo !

@SpartanJ
Copy link
Owner Author

Original comment by RoestVrijStaal (Bitbucket: RoestVrijStaal, GitHub: RoestVrijStaal).


Hello,

I tried to reproduce the bug with TDM-GCC, but I couldn't set up the toolchain properly because TDM-GCC installs the 64-bit compiler and I'm using 32-bit Windows. The TDM-GCC docs tells using -m32 would work, but since other dlls are used, it doesn't.

Trying to the "old" MinGW environment installed by TDM-GCC doesn't play nice with SDL2 either.

The installation process of TDM-GCC makes me wonder if difference between things like SJLJ, SEH and DWARF2 and POSIX / Win32 threads could cause the jpg-view problem. I know they shouldn't, but it could be.

Are the used jpg-loading dll's the same? To compare, you'll find the one I use (libjpeg-9.dll) in the \bin\Debug directory of the uploaded projects I linked to in the previous post. It's the one shipped with SDL2_image-2.0.0.

Please notice I'm able to build SOIL2 in the beginning, but I felt something was wrong because I had to add -msse2 to get a successful build. I guess the title of this issue is somewhat misleading now, because it seems only jpg-view doesn't work. Sorry for your efforts CHAOS-THEORY, but likely someone else will find it a handy tutorial.

Since it seems only a problem with jpg. I guess working it around by using other file formats is my best option for the time being.

Best Regards,

RoestVrijStaal

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


OK, so now i understand the problem!

The new stb_image SSE2 jpeg decoder implementation is not working on 32bit builds.
Sadly i didn't see the problem before, but this is a new introduced bug because i updated the image loader library that SOIL2 uses and it's bugged. So i'll report the bug to the mantainer.

Meanwhile i disabled SSE2 in 32bit builds, that fixes the problem. I don't know if this is a Window only problem, i'll test it in some minutes so i can report the bug correctly in the stb_image repo.

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


Reopened until the SSE2 implementation is fixed.

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


Disabled SSE2 for 32bit builds since it's crashing the application!
See issue #5.

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


RoestVrijStaal, just to let you know:

To compile with TDM-GCC64 in 32bits, it's OK to use -m32, that should work.
SDL2 works OK, but you should know how to make it work, this is what you have to do ( otherwise it will not link against your 32bit build ):
Copy the files from the SDL2 mingw package that are inside i686-w64-mingw32\lib\ to TDM-GCC-64\x86_64-w64-mingw32\lib32. That's all, and of course, copy the include files, and put the SDL2.dll lib with your exe, but the 32 bit one, the one that is on \i686-w64-mingw32\bin\.

To generate the project with 32bit forced with premake you should do premake4 --platform=x32 gmake ( or codeblocks or whatever ).

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


More data:
Compiled with VC ( VS2013 ) in 32bits works just fine! So it must be a problem with the generated SSE2 code in mingw, totally weird. I'm going to test a little bit more.

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


Disable SSE2 jpeg decoding only for mingw32 32 bit builds.
See Issue #5.

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


Issue on github: nothings/stb#81

@SpartanJ
Copy link
Owner Author

Original comment by RoestVrijStaal (Bitbucket: RoestVrijStaal, GitHub: RoestVrijStaal).


It's kinda overwhelming for me. What should I do now?

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


Just pull and update the repo and recompile. It should work because i disabled SSE2 for 32bit mingw builds.

@SpartanJ
Copy link
Owner Author

Original comment by Martín Lucas Golini (Bitbucket: SpartanJ, GitHub: SpartanJ).


Fixed issue #5.

@SpartanJ SpartanJ added major bug Something isn't working labels Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working major
Projects
None yet
Development

No branches or pull requests

1 participant