Re: MesaLib

On Sun, 9 Jul 2023 at 21:42, Taylor R Campbell
<[email protected]> wrote:
>
> > Date: Sun, 09 Jul 2023 21:24:55 +0100
> > From: Robert Swindells <[email protected]>
> >
> > I wrote:
> > > I think I have got native MesaLib to build.
> > >
> > > Not tried it out yet and still have to go through the patches in
> > > pkgsrc to see which ones need adding to xsrc.
> >
> > Tried it out a bit with swrast and an old NVidia system, can try
> > an old AMD card, don't have any Intel systems to try.

FWIW on a -current (from today, but for a long time) system with an
AMD FirePro W5000 card DRI2 and 3d-accelleration work as well as it
can be expected; it is an old card which returns glmark2 score of
about 5000. Using firefox-esr I also get some 20-30 million triangles
from cad.onsharep.com/check test (unfortunately WebGL had to be taken
out in the current firefox version, I did not understand the reason
for that, but it appeared to be some reliance on Linux API's in the
code).

If it is of interest, I can provide the dmesg and the Xorg log file.

This is using the build-in MesaLib. Stuff like OpenSCAD also works very well.

I have a laptop with Intel (graphics 530, whatever that means) and
GeForce GTX 950M (never worked with NetBSD), I can test it, although I
haven't upgraded it recently.
It used to run accelerated 3D before without a problem.

> >
> > glxgears dumps core on old NVidia, doesn't give a useful stack trace.
>
> What stack trace does it give?  What seems to be missing from it to
> make a useful stack trace?
>
> > What is the status of toolchain/50277? Are there any patches from
> > graphics/MesaLib that would be still needed for NetBSD-current?
>
> Should be fixed.  If not fixed, the problem would likely manifest as a
> null pointer dereference in logic that tries to get the current GL
> context.
>
> > I have done a build of xsrc MesaLib.old to verify that it still works
> > with my makefile changes.
> >
> > Am I ok to start committing some of this or do people want to review it
> > first? Would probably do the "old" makefiles first.
>
> Can you please post changes for review first?
>
> > One extra idea is to change everywhere to use the ${OLD_SUFFIX}
> > macro in pathnames that could be "old" or not, this could reduce the
> > work when doing the next upgrade.
>
> That sounds like a good idea.



-- 
----