Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Gsdx Hardware Rendering problem
#1
What I'm seeing seems to be the same problem as mentioned here. But since I'm on Fedora with a different setup, I didn't want to further hijack the thread.

I'm using r5695 on Fedora 19 x86_64, compiled without the EGL flag. Software mode works fine, but slow in some situations. Hardware mode shows nothing but a black screen.

Console output:
Code:
Interface is initializing.  Entering Pcsx2App::OnInit!
Applying operating system default language...
Command line parsing...
Command line parsed!
(UserMode) Found portable install ini @ /home/klingac/Emulators/pcsx2_dbg/portable.ini
glX-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.0 NVIDIA 319.23 on GPU: GeForce 9600 GSO/PCIe/SSE2. Vendor: NVIDIA Corporation
DEBUG: check_gl_supported_extension
INFO: GL_ARB_gpu_shader5 is not supported
Override GL_ARB_copy_image detection
Override GL_NV_copy_image detection
ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm.c:2109:(snd_pcm_open_conf) type is not defined
ALSA lib pcm.c:2109:(snd_pcm_open_conf) type is not defined
ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
Cannot lock down 107335194 byte memory area (Cannot allocate memory)
* SPU2-X: Enumerating PortAudio devices:
*** Device 0: 'HDA ATI SB: ALC889 Digital (hw:0,1)' (ALSA)
*** Device 1: 'iec958' (ALSA)
*** Device 2: 'spdif' (ALSA)
*** Device 3: 'pulse' (ALSA)
*** Device 4: 'default' (ALSA)
*** Device 5: 'system' (JACK Audio Connection Kit)
Decommitting host memory for virtual systems...
Releasing host memory maps for virtual systems...
Unloading plugins...
Plugins unloaded successfully.
Segmentation fault (core dumped)

Debug.txt:
Code:
Type:Performance        ID:3    Severity:Med    Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance        ID:5    Severity:Med    Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.

The only thing I'm seeing is the GL_ARB_gpu_shader5 failure. I'm not using fxaa, so as mentioned in the other thread, Gsdx shouldn't need it. I also overrode copy_image, but that made no difference. The game I was using when this log was made was FFX NTSC.

Steel01

P.S. Yes, there's other problems shown in the log, like the seg fault on exit and alsa stuff when I'm using jack, but they're not impeding anything.
Reply

Sponsored links

#2
Could you try
1/ set all override* stuff to 0 => if it doesn't work reset them to -1
2/ try to play with the option. Scaling/native, 8bits textures ...
3/ try with the open source drviver.
Reply
#3
Tongue2

@Steel01, can you test an older GSdx like 5669?
Reply
#4
1. No change. My card only supports OGL 3.3.0 according to glxinfo and 2 of those extensions are OGL 4+. Log attached of the stdio when those were enabled (can't attach a .log??). I set shader_objects and the 420pack to -1 and re-ran. Still no difference and the logs are the same as in my OP. Then I reset the other 2 to -1 before the next point.

2. Checked native -> no change -> unchecked
Checked 'allow 8-bit textures' -> no change -> unchecked
I don't know enough about how the internal res is getting set. All three sets of options are available at the same time. What's the order of precedence for them?

3. I really don't want to try this, but I can if absolutely nothing else helps. IMHO, nouveau isn't up to par yet. When I reinstalled this system with F19 a few days ago and ran updates, nouveau wouldn't even display KDE correctly. Then I wasn't able to get the proprietary driver and it to peacefully coexist, so I had to completely remove nouveau.

I can get by with the software renderer, but since I saw the problem was already being looked at, I figured I'd throw in my test case and debug info.

Steel01

Edit: Just saw the new reply. Sure, I'll go fire that off on my buildbot and see what happens. Shouldn't be enough changes to keep that from working with the current bin, correct?
Reply
#5
Your card support those GL4 extensions. It is not a matter of hardware but drivers. Anyway, you got shader error when you disabled the features. I would need to fix them but I'm not sure I will do it. Those shaders are only a temporary solution for the free drivers.
2/ OK
3/ OK. I understand.
Reply
#6
Oh, would you looky there. glxinfo does list those extensions. Pardon me while I berate myself for misinterpretating that.

I did a full rebuild for r5669 debug and copied my settings from previous release folder. Hardware rendering does work there. About as broken as I remember it from way back when, but it displays. For FFX, the text doesn't render and once in-game, the character smears across the screen with no background drawing. Stdio showed a few things that seem problematic and may have already been fixed.

Code:
*snip*
DEBUG: check_gl_supported_extension
fxaa.fx (entry ps_main, prog 17) :
#define FXAA_GLSL_130 1
#extension GL_ARB_gpu_shader5 : enable
#define FXAA_GATHER4_ALPHA 1
0(8) : warning C7547: extension GL_ARB_gpu_shader5 not supported in profile gp4fp
0(871) : error C1115: unable to find compatible overloaded function "textureGather(sampler2D, vec2, int)"
0(872) : error C1115: unable to find compatible overloaded function "textureGatherOffset(sampler2D, vec2, ivec2, int)"
*snip

So, one of the recent rev's broke it completely. You want me to start building every GSdx update since 5669 and find out which one broke it or do you have an educated guess?

Steel01
Reply
#7
The warning are not important, it will only crash fxaa!

Honestly I don't know which version is bad (the one with the most modification is 5682). I introduce a new option on this one: ogl_vertex_subdata maybe you can try to set it to 0 to restore the old behavior.

Edit: however r5682 is broken on nvidia. You will need to edit res/tfx.glsl around line 130
"const float exp_min32 = exp2(-32.0f);\n"

Edit2: test also 5673, 5671 (those one must compile)
Reply
#8
No, that option didn't fix it. I'm starting to work my way through the revisions. Building r5672 release now.

Steel01

Edit: Gah, another edit. Okay, I'll finish 5672, then try 5682 after that with the patch.

Edit 2: 73 still works as expected. I didn't notice that the next commit had a compile fix. Building 82 with patch now.
Reply
#9
*facepalms*

Well, I found the problem. My build tree hadn't been cleaned out in a while. The *.glsl files that were generated with old builds were still in the bin/plugins directory. I deleted them out of my local copy and ran r5695 and it worked beautifully. Well, as well as the hardware renderer works atm, anyways. Should GSdx still be trying to use those files?

So, that problem down. If I want to pursue solving some of the other problems I've seen, should I open a new topic or can I hijack my own thread?

Steel01
Reply
#10
ah good news for me :-P Behavior is normal it was handy for debug. Anyway my future commit will disable it (only remains to test my change).

please continue on this one.
Reply




Users browsing this thread: 1 Guest(s)