Zofzpcb: Shader compilation failure?

xobs commented 10 months ago

I'm trying to use Zofzpcb on Linux and Mac, however they both fail to run. I'm able to replicate the same behaviour on WSL2 under Linux, so that's what I'm

Software information

Zofzpcb is a 3D PCB viewer. It may be downlaoded freely from https://www.zofzpcb.com/Gerber-Viewer-Download and has both a "Portable" and an "Installer-based" version.

Both versions fail to start. They open a window, but crash immediately.

System information

GPU: NVidia 1080
Driver: WSL2
Wine version: wine-8.19
DXVK version: 1.9.4+ds1-1ubuntu1

Apitrace file(s)

I suspect it didn't work, or at least crashed before drawing anything:

$ hexdump -C 3D_PCBA_Viewer.trace
00000000  61 74                                             |at|
00000002
$

However, here is a trace from Windows: 3D_PCBA_Viewer.zip -- I imagine the Linux version crashed before reaching even the first frame, which is why the trace there isn't very interesting.

Log files

The last few lines of the log output are attached below. There are many shaders that are compiled, as I get many instances of "Compling shader (x) / Input Signature for - (x) / Output Signature for - (x)", however the final shader only reports "Compiling shader (x)".

I do see output in the Windows trace, which I've attached here.

I also have the spir-v files, as well as the dxbc file that is generated.

Interestingly, the log below is from the terminal output. The logfile stops at Compiling shader VS_617bbc1c44063f34dba60db63a820c3a80106b92, which is what led me to believe this was a shader issue.

debug: Compiling shader VS_617bbc1c44063f34dba60db63a820c3a80106b92
debug: Input Signature for - VS_617bbc1c44063f34dba60db63a820c3a80106b92
debug: SGN Entry:
debug:  semanticName: POSITION
debug:  semanticIndex: 0
debug:  registerId: 0
debug:  componentMask: xyz
debug:  componentType: DxbcScalarType::Float32
debug:  systemValue: DxbcSystemValue::None
debug:  streamId: 0
debug:
debug: SGN Entry:
debug:  semanticName: TEXCOORD
debug:  semanticIndex: 0
debug:  registerId: 1
debug:  componentMask: xy
debug:  componentType: DxbcScalarType::Float32
debug:  systemValue: DxbcSystemValue::None
debug:  streamId: 0
debug:
debug: Output Signature for - VS_617bbc1c44063f34dba60db63a820c3a80106b92
debug: SGN Entry:
debug:  semanticName: SV_POSITION
debug:  semanticIndex: 0
debug:  registerId: 0
debug:  componentMask: xyzw
debug:  componentType: DxbcScalarType::Float32
debug:  systemValue: DxbcSystemValue::Position
debug:  streamId: 0
debug:
debug: SGN Entry:
debug:  semanticName: TEXCOORD
debug:  semanticIndex: 0
debug:  registerId: 1
debug:  componentMask: xy
debug:  componentType: DxbcScalarType::Float32
debug:  systemValue: DxbcSystemValue::None
debug:  streamId: 0
debug:

Blisto91 commented 10 months ago

Did you get it working with wined3d since you are suspecting a dxvk issue? I get the same no text error Window both with wined3d and dxvk. Also have you tried latest dxvk? Older versions aren't supported

mbriar commented 10 months ago

The log output doesn't indicate that there is a shader compilation issue in any way as far as I can tell. The app also fails in the same way with wined3d. To me this looks unrelated to DXVK.

xobs commented 10 months ago

It may be more subtle than that, but I'm generally in agreement. I'm going to try disassembling it and see what's going on, but given that it's not crashing or giving an error it may just be that the program is receiving some subtly different value than it's expecting, and may be a Wine bug.

Or perhaps DXVK is providing an incorrect value (maybe it doesn't like the vendor string? who knows!), but either way I'll close this since DXVK doesn't seem to be doing anything overtly incorrect.

xobs commented 10 months ago

It's definitely a Wine issue. Disassembly shows that the message box appears as a result of CheckMenuRadioItem() returning FALSE at a particular point, which I guess it returns TRUE on Wine? Either way, I was confused by the fact that the DXVK log cut off in the middle (i.e. it said that it started compiling but never finished), when I imagine it's just that DXVK logs are buffered and the program terminated before the buffers had a chance to get flushed.

doitsujin / dxvk