Nvidia OpenGl doesn't work anymore with KiCad?

I use NVidia under Debian Buster without issue.

While it is possible that there is an incompatibility showing up in the shader compiler due to new KiCad code, we do not have a FreeBSD developer on the project at the moment who can look into this.

You can utilize one of the supported Linux distributions or, should you be inclined, dig into the source code and propose a patch that fixes your issue.

GeForce FX Quadro 4500 is a GPU from 2005. This means it's 14 years old now. The drivers you have (nvidia-driver-304) were relased in 2013, so they are 6 years old now.

The last change to the shader code happened in April 2019 and it doesn't require anything the FX 4500 can't do - so it's either an issue with your system or it's finally the time to get a new graphics card...

Tom

PS. Does it work under Windows on the same machine?

Yes, the 304 Driver may be released in 2013, but the last revision from this driver is from 2017 (304.137) and this is installed.

Besides of this, is it really neccessary to always use the last available Hardware for an job that can be done with older Hardware too? I have to buy a new System every 3 days, or what? It worked flawlessly until April as your say, April 2019 may similar to my experiences.
I'm using Unix systems since they are not that bloated as windows is.
I had running not the KiCad Release in the past, but some Git Revisions (FreeBSD Port kicad-devel) and assumed that my problems are related to this, but the problem exists in the release too.

>The last change to the shader code happened in April 2019 and it doesn't require anything the FX >4500 can't do - so it's either an issue with your system or it's finally the time to get a new >graphics card...

Tom.. if the changes on the code doing nothing that the FX4500 can't do..then this problem is clearly a bug in the code, isn't it?

Don't know if KiCad would run under windows on this machine, I don't use windows besides on some business related notebooks.

@Seth: It isn't relevant what you have an experiences on other hardware, I have 2nd FreeBSD System
with an simple GeForce GT730 and the 340.107 driver and there is OpenGL working with KiCad.
The Xserver Code from FreeBSD and the one that Debian is using shouldn't differ that much.

I can write, debug and compile some C-code and I'm a FreeBSD Sysop for almost 30 years, but I have no clue about OpenGL or Vertex Shaders. I have no idea where to start debugging here.
Do you have at least some (interesting) hints?

Regards,

Holm

Without knowing much about the opengl stuff either, but is the kicad-ogltest binary helpful in debugging this? I.e. does it fail with the same error?

..yes:

INFO: Instantiated GL window
INFO: Found OpenGL version 2.1
Vertex info
-----------
0(119) : warning C7050: "delta" might be used before being initialized
Internal error: assembly compile error for vertex shader at offset 15516:
-- error message --
line 602, column 1: error: too many instructions
-- internal assembly text --
!!ARBvp1.0
OPTION NV_vertex_program3;
# cgc version 3.1.0001, build date Sep 14 2017
# command line args:
#vendor NVIDIA Corporation
#version 3.1.0.1
#profile vp40
#program main
#semantic gl_ModelViewProjectionMatrix : state.matrix.mvp.transpose
#semantic gl_ModelViewProjectionMatrixTranspose : state.matrix.mvp
#semantic worldPixelSize
#semantic screenPixelSize
#semantic pixelSizeMultiplier
#semantic minLinePixelWidth
#var float4 gl_Position : $vout.POSITION : HPOS : -1 : 1
#var float4 gl_FrontColor : $vout.COLOR0 : COL0 : -1 : 1
#var float4 gl_Color : $vin.COLOR0 : COLOR0 : -1 : 1
#var float4 gl_Vertex : $vin.POSITION : POSITION : -1 : 1
#var float4x4 gl_ModelViewProjectionMatrix : state.matrix.mvp.transpose : c[0], 4 : -1 : 1
#var float4 gl_TexCoord[0] : $vout.TEX0 : TEX0 : -1 : 1
#var float4 gl_TexCoord[1] : : : -1 : 0
#var float4 gl_TexCoord[2] : : : -1 : 0
#var float4 gl_TexCoord[3] : : : -1 : 0
#var float4 gl_TexCoord[4] : : : -1 : 0
#var float4 gl_TexCoord[5] : : : -1 : 0
#var float4 gl_TexCoord[6] : : : -1 : 0
#var float4 gl_TexCoord[7] : : : -1 : 0
#var float4x4 gl_ModelViewProjectionMatrixTranspose : state.matrix.mvp : c[4], 4 : -1 : 1
#var float4 attrShaderParams : $vin.ATTR1 : ATTR1 : -1 : 1
#var float4 shaderParams : $vout.TEX1 : TEX1 : -1 : 1
#var float2 circleCoords : $vout.TEX2.xy : TEX2 : -1 : 1
#var float worldPixelSize : : c[8] : -1 : 1
#var float2 screenPixelSize : : c[9] : -1 : 1
#var float pixelSizeMultiplier : : c[10] : -1 : 1
#var float minLinePixelWidth : : : -1 : 0
#const c[11] = 5 1 0 0.5
#const c[12] = 2 0.89999998 -1 0
#const c[13] = 6 7 8 9
#const c[14] = 10 3 -1.7320509 -1
#const c[15] = 1.7320509 -1 4 0
#const c[16] = -1.7320509 0
PARAM c[17] = { state.matrix.mvp.transpose.row[0..3],
                state.matrix.mvp.row[0..3],
                program.local[8..10],
                { 5, 1, 0, 0.5 },
                { 2, 0.89999998, -1, 0 },
                { 6, 7, 8, 9 },
                { 10, 3, -1.7320509, -1 },
                { 1.7320509, -1, 4, 0 },
                { -1.7320509, 0 } };
TEMP R0;
TEMP R1;
TEMP R2;
TEMP R3;
TEMP R4;
TEMP R5;
TEMP RC, HC;
BB0:
SEQC HC.x, vertex.attrib[1], c[11];
MOV result.texcoord[1], vertex.attrib[1];
MOV R3.x, -vertex.attrib[1].w;
MOV R3.y, vertex.attrib[1].z;
SLT R1.x, |vertex.attrib[1].z|, |vertex.attrib[1].w|;
BRA BB5 (LE.x);
BB1:
MOV R1.z, c[11].y;
SGT R2.x, c[10], R1.z;
MOV R0.z, c[8].x;
SEQC HC.x, vertex.attrib[1].y, c[11].z;
MOV R0.z(EQ.x), vertex.attrib[1].y;
RCP R0.x, c[8].x;
MAD R0.x, R0.z, R0, c[11].w;
FLR R0.x, R0;
MOV R4.w, R0.x;
SLTC HC.x, R0, c[11].y;
MOV R4.w(NE.x), c[11].y;
MUL R0.xy, -vertex.attrib[1].zwzw, -vertex.attrib[1].zwzw;
ADD R0.x, R0, R0.y;
RSQ R0.x, R0.x;
.....

Regards,
Holm

BTW: I have mesa-demos-8.4.0_2 installed and tested some of the demos, they are all working flawlessly so far.

For the error message above:

Internal error: assembly compile error for vertex shader at offset 15516:
-- error message --
line 602, column 1: error: too many instructions
-- internal assembly text --

Which line 602 from which assembly text is meant here?

Regards,
Holm

The Error messages from gerbview and kicad-ogltest seems to be identical, at least they are complaining about the same line 602 and to many instructions...

Regards,
Holm

Hi Holm,

One thing you can try is to disable antialiasing. Apart from that, if you have some spare processor cycles, it would be great if you could perform a git bisect to see which commit introduced problematic code.

Judging from the error message, the problem appears to be inside the Nvidia's shader compiler (part of the driver package). Or one of its' countless system dependencies, which are a moving target, at least in all Linuxes.

If you feel like compiling KiCad from sources, try reverting the commit db0523626cbf9fdf012ac60079a4060ffb16c7db

Tom

@Tomasz:

Sorry, don't know much of git, do you mean that?
:
https://github.com/KiCad/kicad-source-mirror/commit/db0523626cbf9fdf012ac60079a4060ffb16c7db

Back out both of the changes displayed there?

....shouldn't be a problem to try since the from me prefered way to install "ports" on FreeBSD is compiling the sources anyway..

@Maciej:

regarding nvidia-settings Antialiasing should already be set to off.

Regards,

Holm

Holm, I meant antialiasing settings in pcbnew. Check Preferences menu->Preferences... then in 'Common' section there is 'Accelerated graphics', set it to 'No antialising'.

Ok Maciej, I'll look for that...when I have the binaries on the system again.
Currently 5.1.4 is recompiling with the suggested changes backed out...

Regards,
Holm

Ok..pcbnew starts up normally, then I've changed the settings to "No Aliasing", after that to "Modern Toolset Accellerated"...poff:

$ pcbnew 2>&1|less
13:56:14: Debug: Adding duplicate image handler for 'PNG file'
13:56:14: Debug: Adding duplicate image handler for 'JPEG file'
13:56:14: Debug: Adding duplicate image handler for 'TIFF file'
13:56:14: Debug: Adding duplicate image handler for 'GIF file'
13:56:14: Debug: Adding duplicate image handler for 'PNM file'
13:56:14: Debug: Adding duplicate image handler for 'PCX file'
13:56:14: Debug: Adding duplicate image handler for 'IFF file'
13:56:14: Debug: Adding duplicate image handler for 'Windows icon file'
13:56:14: Debug: Adding duplicate image handler for 'Windows cursor file'
13:56:14: Debug: Adding duplicate image handler for 'Windows animated cursor file'
13:56:14: Debug: Adding duplicate image handler for 'TGA file'
13:56:14: Debug: Adding duplicate image handler for 'XPM file'
/usr/local/lib/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py:16629: UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn("wxPython/wxWidgets release number mismatch")
13:56:15: Debug: window wxScrolledWindow(0x82cd8c400, ) lost focus even though it didn't have it
13:56:15: Debug: window wxScrolledWindow(0x82cd8c400, ) lost focus even though it didn't have it
Vertex info
-----------
0(119) : warning C7050: "delta" might be used before being initialized
Internal error: assembly compile error for vertex shader at offset 15516:
-- error message --
line 602, column 1: error: too many instructions
-- internal assembly text --
[..]

Gerbview and kicat-ogltest are crashing the very same way as before.
What to try next?

Regards,

Holm

Judging from the error " line 602, column 1: error: too many instructions", maybe the shader grew to big for the old GPU to support. Try compiling without the commit I showed you, I can bet it will make it work...

Tom

Tom I wish you where a lucky man, but you loose. :-|
(If I got the correct commit at github)

My Post above (#14) shows the results from the recompiled package with the mentioned patch reversed out. It makes now visible difference, even the Line 602 is the same.

Since that is an old machine, I've ordered another Graphics card yesterday evening at ebay
(NVidia Quadro 2000 1GB GDDR5 PCIe) and will tell you if the error goes away with that thing
when I've plugged in that card.
However, so far as I know the Nvidia Quadro FX devices where good and powerful cards, meant for the commercial cad market, not for desktop home use. The quadro 2000 uses another driver package (-390) and the date on Nvidias website is from 6/2019. I don't know how the GPU can go out of power horses
if the code doesn't get assembled at all.

Nevertheless I want to know what exactly is going on here, I've mailed the FreeBSDs Port maintainer for nvidia-driver-304 in the meantime, since it is unclear to me why Nvidia is suggesting 334 for FreeBSD and the FX4500 and I'm using 304 since only nvidia-driver-304, nvidia-driver-340 and nvidia-driver-390 are existing (additional a generic one w/o that 3xx) and it is unclear to me how I have to select the right one (simple tested this long time ago).

I'm don't get afraid to ask Nvidia why this doesn't work.. but I think I may still not know enough to trigger them to do anything. Unfortunalely Open-GL doesn't work remote so that I could check with
the KiCad on the other machine working with -340 over the network.

BTW: "too complex shader"..that kicad-ogltest doesn't look much complex..and is failing too.

Regards,

Holm

Well, I'm out of luck then :/

The error message suggests the vertex shader is too complex. The last really complex change to its code occured in commit bbee30671ae4da9aa215d55e116786c30bfca78e ("gal: pixel alignment hacks, works for Retina display too now."). Reverting this patch alone is not easy, but you can try at least compiling a KiCad version from before 21/01/2019.

Also there's a chance that something was changed in the FreeBSD port of nvidia-driver that broke its GLSL compiler for some reason...

Concerning your BTW - kicad-ogltest uses exactly the same shaders as Kicad itself, so you are getting the same errors.

Tom

You can also try using the attached patch. It makes graphics slightly uglier (no pixel alignment), but also reduces the shader complexity.

Apply against kicad master (without any other changes such as reverting previous opengl patches).

Thanks Tom, I'll try it tomorrow. (have to scan an ancient documentation at the moment to sent it back to its origin tomorrow).
Building master isn't a easy job on FreeBSD since it is an unsupported system, I'll try to use
the kicad-devel port which is fetching actual data from git but has the entire patch-framework for FreeBSD already build in.

I'll keep you posted ..and many thanks to you!

Regards,

Holm

Have build it in the meantime.. trying pcbnew stanalone doesn't crash, but I get a popup window "Could not use OpenGL, falling back to software Rendering" "Einzelheiten: (Details) Could not find Shader uniform: (and nothing more).

$ /usr/local/bin/kicad-ogltest
INFO: Instantiated GL window
INFO: Found OpenGL version 2.1
*** Caught unhandled unknown exception; terminating
$

Don't know if that's related to my Build process, will try again...

Regards,

Holm

Ok, build a 2nd time (with other steps) but the results are identical.

Regards,
Holm

Try the new patch attached to this post. Can't guarantee it will compile without errors (I have an intel GPU here).

..it is compiling...
Regards,
Holm

Good morning!

..at least pcbnew isn't crashing anymore but the results aren't that good:

Simple Board with accellerated Graphics:

https://www.tiffe.de/images/u884-corse.png

and with fallback

https://www.tiffe.de/images/u884-normal.png

Besides of the missing traces I don't think that this was looking like this before April 2019.

Regards,

Holm

...gerbview is running again, but the missing traces in pcbnew are missing in gerbview too.

$ /usr/local/bin/kicad-ogltest
INFO: Instantiated GL window
INFO: Found OpenGL version 2.1
INFO: Successfully called OPENGL_GAL::beginDrawing
PASS
$

Regards,
Holm

OK, let's try again... (new patch here).

...compiling...

Regards,
Holm

$ /usr/local/bin/kicad-ogltest
INFO: Instantiated GL window
INFO: Found OpenGL version 2.1
Vertex info
-----------
0(76) : warning C7050: "delta" might be used before being initialized

INFO: Successfully called OPENGL_GAL::beginDrawing
PASS
$

pcbnew looks good so far, besides of some missing lines (connector left bottom)

https://www.tiffe.de/images/u884-accel.png

vs

https://www.tiffe.de/images/u884-norm.png

Gerbview is running too:

ttps://www.tiffe.de/images/gerbview.png

What you are doing Tom? Decreasing Complexity?

Regards,

Holm

..oh..cut&paste error on the gerbview picture url..

Regards,
Holm

Yes, I decreased the complexity of the shader (removed pixel/line width alignment), so the board looks worse especially on low zoom level (missing lines). Consider this a temporary solution until you'll receive your new graphics card.

PS. Quadro series is expensive and advertised "for professionals" but doesn't bring any advantage to KiCad compared to consumer GPUs.

T.

I've got the Quadros (4000 and 4500FX) for free, the one from ebay cost me 19€ or so..
nothing to seriously talk about.

I'm not a gamer, watching a video from time to time, the daily programming work
on several MCUs and resonable KiCad Performance is enough for me.

Is it possible to get your changes in the future with a configuration switch?
At least the programs schouldn't dumping cores at all..

Many Thanks,

Holm

@Holm, please don't change the status of bug reports. There has been no fix release (or committed) for this.

:-)

Yes...I've simple looked what the knob is doing, someone confirmed the bug, wanted to know who..*pling* ..ups...

Regards,

Holm

I'm going to mark as invalid since this is not a supported OS.

Ahh..understand, OpenGL isn't a supported OS...

Regards,

Holm

Holm, the code is valid OpenGL and works on most of the platforms. If you say it does not work with a certain operating system, then it hints at an OS-related problem: video driver, configuration, etc.

In the past we had rendering problems that were specific to an OS or graphics card and we tried to fix them if we could reproduce the issue. Unfortunately we do not have any developers using FreeBSD, that is why we say it is not a supported OS. Currently the only option is to blindly throw patches without a possibility of real problem analysis, and I hope you agree it is not a very effective way of working.

Did you get a response from the FreeBSD port maintainer of nVidia driver? How is it going with the new card?

I haven't sayed that the code doesn't work with an certain operating system, I've sayed that it doesn't work with Nividia's OpenGL Implementation anymore.

It was you that sayed it where operating system specific, not me and not Tom.

The OpenGL Driver is an Nviada blob so is the shader compiler, FreeBSD or not
is changing nothing on that.

Reproduce? Simple get the same Quadro FX4500 and try yourself, I bet it is the same on Linux since the entire xorg infrastructure is the same as on FreeBSD.

Get me right, I'm 56 years old and in the Unix Business since times where Linux don't even existed
and you can trust me, this is not a FreeBSD problem.

The new card is here, but I had't time jet to install it, the weekend is near.
An I still have no answer from Alexey Dokuchaev.

I understand that flagging that bug "invalid" makes it easy to you the get it away from you table...

Regards,
Holm

Ok, I've mounted the "new" graphics Card, installed the new unified nvidia-390 driver, recompiled Kicad (master) w/o Toms Patches and Kicad worked (somewhat).
I've tried to open a Project from retrowbrew computers (Layout has bugs)

https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:protoboard_iii:protoboard_iii

KiCad couldn't find some symbols and remapped it, after closing the remapping-window, it dumps core.
Thereafter I deinstalled master and installed 5.1.5 which is working flawlessly so far, even gerbview ist working as expected.

So Maciej: You are wrong! Tom was right. The Problem isn't operating system related, it is coming from your growed to big shader software, so OpenGL 2.1 isn't the only restriction to get it working.

Regards,

Holm

Holm, for your information - we have switched from Launchpad to Gitlab. You can follow your bug report here: https://gitlab.com/kicad/code/kicad/issues/2612

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2612