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

Jeanne D'Arc is crashing with 'Hardware Transform' option off #5699

Closed
i30817 opened this issue Mar 23, 2014 · 9 comments
Closed

Jeanne D'Arc is crashing with 'Hardware Transform' option off #5699

i30817 opened this issue Mar 23, 2014 · 9 comments

Comments

@i30817
Copy link

i30817 commented Mar 23, 2014

At the boot of the game. Although it doesn't really 'work' correctly before at least it doesn't crash. And with the option on i have the terrible font problem, where are we supposed to drop the official fonts again?

bisected commit is:

4772852 is the first bad commit
commit 4772852
Author: Unknown W. Brackets [email protected]
Date: Sun Mar 16 17:56:34 2014 -0700

softgpu: Use SSE in Vec?::Length().

Minor perf boost but if I do everything in Vec things get slower.

:040000 040000 43a087b28f52023e3b222771d2f238e762997fba f2a706b1b0d6dbaa36a2b562d1cdb1c2e4111180 M GPU

@unknownbrackets
Copy link
Collaborator

Where? Intro and battle both work fine, 32 and 64 bit, for me, with hardware transform off.

-[Unknown]

@i30817
Copy link
Author

i30817 commented Mar 23, 2014

just boot the game here. This is linux 64 bits (ubuntu-gnome)

@i30817
Copy link
Author

i30817 commented Mar 23, 2014

gdb says:
08:52:932 Movie File T I[ME]: HW/MediaEngine.cpp:79 FF: deprecated pixel format used, make sure you did set range correctly
08:52:956 user_main E[G3D]: GLES/Spline.cpp:786 Something went really wrong, vertex size: 36 vs 48

Program received signal SIGSEGV, Segmentation fault.
0x0000000000a67a74 in _mm_store_ps (__A=..., __P=0x7fffffffbe44)
at /usr/lib/gcc/x86_64-linux-gnu/4.8/include/xmmintrin.h:947
947 *(__v4sf *)__P = (__v4sf)__A;
(gdb) br
Breakpoint 1 at 0xa67a74: file /usr/lib/gcc/x86_64-linux-gnu/4.8/include/xmmintrin.h, line 947.

@i30817
Copy link
Author

i30817 commented Mar 23, 2014

err, it wasn't br:

(gdb) backtrace
#0  0x0000000000a67a74 in _mm_store_ps (__A=..., __P=0x7fffffffbe44)
    at /usr/lib/gcc/x86_64-linux-gnu/4.8/include/xmmintrin.h:947
#1  Math3D::Vec3<float>::Length (this=0x7fffffffc140)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/Math3D.cpp:106
#2  0x0000000000a67be4 in Math3D::Vec3<float>::Normalized (this=0x7fffffffc140)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/Math3D.cpp:134
#3  0x0000000000a5941f in TransformDrawEngine::SoftwareTransformAndDraw (
    this=0x21fcdc0, prim=3, decoded=0x7fffdc7fe000 "", program=0x367a230, 
    vertexCount=810, vertType=4607, inds=0x7fffdc6be000, indexType=4096, 
    decVtxFormat=..., maxIndex=540)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GLES/SoftwareTransform.cpp:362
#4  0x0000000000a53d13 in TransformDrawEngine::DoFlush (this=0x21fcdc0)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GLES/TransformPipeline.cpp:724
#5  0x0000000000a20a20 in TransformDrawEngine::Flush (this=0x21fcdc0)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GLES/TransformPipeline.h:128
#6  0x0000000000a37238 in TransformDrawEngine::SubmitBezier (this=0x21fcdc0, 
    control_points=0x230891e15c, indices=0x0, count_u=4, count_v=4, 
    prim_type=GE_PATCHPRIM_TRIANGLES, vertType=511)
---Type <return> to continue, or q <return> to quit---
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GLES/Spline.cpp:843
#7  0x0000000000a1dbed in GLES_GPU::ExecuteOpInternal (this=0x21f5950, 
    op=83887108, diff=1028)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GLES/GLES_GPU.cpp:806
#8  0x0000000000a1d40b in GLES_GPU::FastRunLoop (this=0x21f5950, list=...)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GLES/GLES_GPU.cpp:626
#9  0x0000000000a62876 in GPUCommon::InterpretList (this=0x21f5950, list=...)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GPUCommon.cpp:497
#10 0x0000000000a63140 in GPUCommon::ProcessDLQueueInternal (this=0x21f5950)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GPUCommon.cpp:663
#11 0x0000000000a62e9b in GPUCommon::ProcessEvent (this=0x21f5950, ev=...)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GPUCommon.cpp:619
#12 0x0000000000a1d4da in GLES_GPU::ProcessEvent (this=0x21f5950, ev=...)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/GPU/GLES/GLES_GPU.cpp:651
#13 0x000000000098cc20 in ThreadEventQueue<GPUInterface, GPUEvent, GPUEventType, (GPUEventType)0, (GPUEventType)8, (GPUEventType)7>::RunEventsUntil (
    this=0x21f5950, globalticks=0)
    at /home/i30817/Documents/Netbeans_projects/ppsspp/Core/ThreadEventQueue.h:9---Type <return> to continue, or q <return> to quit---

@i30817
Copy link
Author

i30817 commented Mar 23, 2014

oh goddamn i'm always forgetting github links cardinals.

@i30817
Copy link
Author

i30817 commented Mar 23, 2014

There are a few more errors before that GLES error:
08:52:906 user_main E[ME]: HLE/sceMpeg.cpp:1459 UNIMPL sceMpegAvcInitYCbCr(09051f38, 1, 480, 272, 092092f0)
08:52:906 user_main E[ME]: HLE/sceMpeg.cpp:1459 UNIMPL sceMpegAvcInitYCbCr(09051f38, 1, 480, 272, 09239090)
08:52:906 user_main E[ME]: HLE/sceMpeg.cpp:1459 UNIMPL sceMpegAvcInitYCbCr(09051f38, 1, 480, 272, 09268e30)
08:52:906 user_main E[ME]: HLE/sceMpeg.cpp:1459 UNIMPL sceMpegAvcInitYCbCr(09051f38, 1, 480, 272, 09298bd0)

@hrydgard
Copy link
Owner

Those are irrelevant, but looks like you are getting a crash due to us using SSE instructions without taking care of alignment properly.

@unknownbrackets , it's crashing in Vec3::Length , probably because it's not using _mm_loadu_ps properly, instead just accessing the variable directly. If the variable has ended up at a non-aligned address, that _mm_mul_ps may crash on pre-Ivy Bridge (which loosened up aligment requirements for arithmetic operands)....

unknownbrackets added a commit that referenced this issue Mar 23, 2014
I'm wanting things to stay in registers, but that's not realistic for
arguments.  Force inline the others.  May help #5699.
@unknownbrackets
Copy link
Collaborator

Well, I did not think about 32 bit enough, but I was hoping it would pass the arguments in xmm regs on 64 bit at least.

-[Unknown]

@i30817
Copy link
Author

i30817 commented Mar 24, 2014

this was fixed

@i30817 i30817 closed this as completed Mar 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants