kicad-developers team mailing list archive

[Andrew Lutsenko <anlutsenko@xxxxxxxxx>]

Is it possible to determine openGL hardware support at runtime and use
advanced API on newer machines while switching to fallback for older ones?
I believe that solution would be best of both worlds.
Otherwise the only reasonable cut-off date would be when officially
supported OS versions will not support hardware with given OpenGL version.
(For hypothetical example if kernel 7.0 will drop driver support for HD2000
and the likes there is no sense in clinging to old api but graphics drivers
live very long time).

Regards,
Andrew

On Sat, May 11, 2019 at 7:33 AM jp charras <jp.charras@xxxxxxxxxx> wrote:

> Le 11/05/2019 à 16:18, Jon Evans a écrit :
> > Hi JP,
> >
> > Thanks for the input, it's a good point. It sounds like in this case
> > there may be a technical solution that works fine in GL2.1 so I agree it
> > makes sense to avoid raising requirements if at all possible.
> >
> > Do you have any thoughts about how we should handle this in the future,
> > if for some reason there is a technical challenge that cannot be solved
> > as easily without moving to a higher OpenGL version? (or some other
> > similar hardware support issue) Should we always design for 2.1, or is
> > there some time in the future when it becomes appropriate to expect
> > users to have something newer?
> >
> > Best,
> > Jon
>
> Of course, if OpenGL 2.1 cannot solve a technical challenge, we can move
> to 3.0.
>
> Moreover, in the future, more PCs will support 3.0.
>
> However, generally speaking, I prefer better algorithms to more powerful
> PCs.
>
> >
> >
> > On Sat, May 11, 2019, 07:27 jp charras <jp.charras@xxxxxxxxxx
> > <mailto:jp.charras@xxxxxxxxxx>> wrote:
> >
> >     Le 10/05/2019 à 18:43, Jon Evans a écrit :
> >     > Does anyone have a good sense of which hardware / software
> platforms
> >     > would be impacted by a switch to OpenGL 3.0 as baseline
> requirement?
> >     >
> >     > As far as I am aware, all commercial tools in the space have more
> >     > advanced / modern system requirements than KiCad, with the possible
> >     > exception of Eagle.  We have to consider whether supporting old
> >     > graphics cards goes counter to the desire to have KiCad handle more
> >     > professional use cases (including large designs).
> >     >
> >     > The integrated Intel GPUs that are old enough to not have OpenGL
> >     3.0 are
> >     > no longer supported by Intel (everything since HD2000 series has
> >     it, as
> >     > far as I know)
> >     >
> >     > -Jon
> >
> >     Hi Jon,
> >
> >     To be honest, I do not share your opinion, and I am not especially
> >     thrilled by switching to OpenGL 3.0 as baseline requirement as long
> as
> >     we can avoid it.
> >
> >     OpenGL 2.1 is a reasonable requirement.
> >
> >     What is a professional use case?
> >     I know at least 2 opposite cases:
> >     - A advanced user who designs very complex boards: he needs a recent
> and
> >     fast computer with 2 (or enev 3) monitors.
> >     - Classroom "users"
> >     They are also professional users who do not design very complex
> boards.
> >     But force updating the computers just to use Kicad is a serious
> issue:
> >     As a old teacher I am knowing what I am saying:
> >     In the department I worked before being retired, we have roughly 200
> PCs
> >     (most of them are dual boot: Linux and Windows).
> >     Not of all are used to run Kicad, but many of them.
> >     Saying: our new Kicad version needs a recent computer+OS so you have
> to
> >     change 50 or 100 of your computers in a bit hard for these users.
> >
> >     >
> >     > On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
> >     >> Hi,
> >     >>
> >     >> I've been recently playing with Victor's huge 32-layer PCB design
> and
> >     >> trying to improve the performance of pcbnew for larger designs.
> This
> >     >> board causes even pretty decent PCs to crash/render glitches due
> to
> >     >> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
> >     >>
> >     >> It turns out it's caused by the way KiCad renders filled zones:
> >     >> - the inside of a zone is drawn/plotted as a filled polygon with
> >     0-width
> >     >> boundary. This one not a problem - we already triangulate the
> >     polygons
> >     >> and I recently developed a patch for the OpenGL GAL that allows
> >     reusing
> >     >> vertices of triangulated polys in the VBO/Index buffer to further
> >     reduce
> >     >> memory footprint.
> >     >> - the thick outline is drawn with rounded segments with the width
> =
> >     >> minimum width of the polygon. Since we don't have arcs in
> >     polygons, each
> >     >> of round features (e.g. vias) surrounded by a zone gets a ton of
> tiny
> >     >> segments in the polygon outline. Each rounded segment in OpenGL is
> >     >> composed of 2 triangles, hence 6 vertices (that can't be
> >     reused...). For
> >     >> Victor's board it means 1 GB (sic!) of the VBO goes for outlines
> >     of the
> >     >> polygons alone. Disabling the outline drawing makes the renderer
> work
> >     >> smooth again.
> >     >>
> >     >> I've been experimenting with some ways to fix this:
> >     >> - generating the thick outline strokes using a Geometry Shader
> (which
> >     >> means bumping up GL 3.0+), which means farewell to many
> Linux/older
> >     >> integrated Graphics users.
> >     >> - caching a triangulated polygon which is a boolean sum of the
> filled
> >     >> inside and the thick stroked outline. This takes a lot of time (~2
> >     >> minutes for Victor's design) to load and still takes quite a bit
> >     of VBO
> >     >> memory. Another downside is that the polygons are not fully
> WYSIWYG
> >     >> (outline segments have true rounded corners, while the corners of
> the
> >     >> displayed shape would be approximated with line segments).
> >     >> - change the way KiCad handles filled zones to calculate the
> >     (stroke +
> >     >> inside) boolean sum during zone filling process. It means changes
> >     to the
> >     >> plotting/GAL/3D code, but no changes to the file format. We'll
> >     also be
> >     >> forced to inform the users that they have to refill the zones if
> they
> >     >> read a file generated by an older KiCad version.
> >     >>
> >     >>
> >     >> Which solution would you prefer?
> >     >> Cheers,
> >     >> Tom
>
>
> --
> Jean-Pierre CHARRAS
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>