drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Tomasz CEDRO
Hello world :-)

I have noticed some bad thing with the X11 Intel driver (12.1-RELEASE
AMD64 with latest intel driver from 2018???) - it eats out all of the
RAM, then it eats all of the SWAP, then system gets unusable for
anything except hard reset :-( This happens when it works together
with latest DRM i915KMS. On hard computer use that means workstation
gets useless in around 15 minutes. Closing applications does not free
the memory resources, once it get some some it never returns.

I have set the UXA as the default for i5-5300U CPU.

On the other hand the DRM i915kms works fine with SCFB on the same
load and hardware. I am working on DRM + i915kms + SCFB so far.

This is why I suspect problem with X11-INTEL driver? Maybe it does not
like latest Xorg changes?

I also sometimes get this DRM warning on the dmesg:
[drm] Reducing the compressed framebuffer size. This may lead to less
power savings than a non-reduced-size. Try to increase stolen memory
size if available in BIOS.

Did anyone observe such problem too?

Best regards :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Niclas Zeising-5
On 2020-04-14 13:57, Tomasz CEDRO wrote:
> Hello world :-)
>
> I have noticed some bad thing with the X11 Intel driver (12.1-RELEASE
> AMD64 with latest intel driver from 2018???) - it eats out all of the
> RAM, then it eats all of the SWAP, then system gets unusable for
> anything except hard reset :-( This happens when it works together
> with latest DRM i915KMS. On hard computer use that means workstation
> gets useless in around 15 minutes. Closing applications does not free
> the memory resources, once it get some some it never returns.

Which driver are you talking about? xf86-video-intel or drm-fbsd12.0-kmod?

>
> I have set the UXA as the default for i5-5300U CPU.
>
> On the other hand the DRM i915kms works fine with SCFB on the same
> load and hardware. I am working on DRM + i915kms + SCFB so far.

If you are using SCFB, you are not using i915kms.

>
> This is why I suspect problem with X11-INTEL driver? Maybe it does not
> like latest Xorg changes?
>
> I also sometimes get this DRM warning on the dmesg:
> [drm] Reducing the compressed framebuffer size. This may lead to less
> power savings than a non-reduced-size. Try to increase stolen memory
> size if available in BIOS.

This is unrelated to this issue.

Have you tried using the modesetting xorg driver instead?
Regards
--
Niclas
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Kevin Oberman-4
On Tue, Apr 14, 2020 at 5:15 AM Niclas Zeising <[hidden email]>
wrote:

> On 2020-04-14 13:57, Tomasz CEDRO wrote:
> > Hello world :-)
> >
> > I have noticed some bad thing with the X11 Intel driver (12.1-RELEASE
> > AMD64 with latest intel driver from 2018???) - it eats out all of the
> > RAM, then it eats all of the SWAP, then system gets unusable for
> > anything except hard reset :-( This happens when it works together
> > with latest DRM i915KMS. On hard computer use that means workstation
> > gets useless in around 15 minutes. Closing applications does not free
> > the memory resources, once it get some some it never returns.
>
> Which driver are you talking about? xf86-video-intel or drm-fbsd12.0-kmod?
>
> >
> > I have set the UXA as the default for i5-5300U CPU.
> >
> > On the other hand the DRM i915kms works fine with SCFB on the same
> > load and hardware. I am working on DRM + i915kms + SCFB so far.
>
> If you are using SCFB, you are not using i915kms.
>
> >
> > This is why I suspect problem with X11-INTEL driver? Maybe it does not
> > like latest Xorg changes?
> >
> > I also sometimes get this DRM warning on the dmesg:
> > [drm] Reducing the compressed framebuffer size. This may lead to less
> > power savings than a non-reduced-size. Try to increase stolen memory
> > size if available in BIOS.
>
> This is unrelated to this issue.
>
> Have you tried using the modesetting xorg driver instead?
> Regards
> --
> Niclas
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "[hidden email]"
>

A day or two ago I saw a post to this list stating that modesetting was not
interesting because it did not support 3-D acceleration. At least on my
Sandy Bridge system running the latest available software for FreeBSD
12-STABLE, 3-D acceleration works just fine. This assumes the most recently
committed mesa, server, drm-fbsd12.0-kmod, etc. It may be that modesetting
does not provide 3-D on other platforms, but that is not the norm, I
suspect. If it does normally work, a clear statement to that effect would
be a "good  thing", though, other than this mailing list, I have no idea
where to find current status and no idea where else users would look.

If it is not going to be maintained, please take down the graphics wiki
page! It list supporting evdev as "Not started" and everything on it seems
over a year old. I'm tempted to volunteer to try to update it myself, but I
am hardly the best informed. I only discovered the modesetting driver as an
option for Intel GPUs when I had serious issues and someone (Jan) suggested
I try it.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: [hidden email]
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Niclas Zeising-5
On 2020-04-14 21:38, Kevin Oberman wrote:

> On Tue, Apr 14, 2020 at 5:15 AM Niclas Zeising
> <[hidden email] <mailto:zeising%[hidden email]>> wrote:
>
>     On 2020-04-14 13:57, Tomasz CEDRO wrote:
>      > Hello world :-)
>      >
>      > I have noticed some bad thing with the X11 Intel driver (12.1-RELEASE
>      > AMD64 with latest intel driver from 2018???) - it eats out all of the
>      > RAM, then it eats all of the SWAP, then system gets unusable for
>      > anything except hard reset :-( This happens when it works together
>      > with latest DRM i915KMS. On hard computer use that means workstation
>      > gets useless in around 15 minutes. Closing applications does not free
>      > the memory resources, once it get some some it never returns.
>
>     Which driver are you talking about? xf86-video-intel or
>     drm-fbsd12.0-kmod?
>
>      >
>      > I have set the UXA as the default for i5-5300U CPU.
>      >
>      > On the other hand the DRM i915kms works fine with SCFB on the same
>      > load and hardware. I am working on DRM + i915kms + SCFB so far.
>
>     If you are using SCFB, you are not using i915kms.
>
>      >
>      > This is why I suspect problem with X11-INTEL driver? Maybe it
>     does not
>      > like latest Xorg changes?
>      >
>      > I also sometimes get this DRM warning on the dmesg:
>      > [drm] Reducing the compressed framebuffer size. This may lead to less
>      > power savings than a non-reduced-size. Try to increase stolen memory
>      > size if available in BIOS.
>
>     This is unrelated to this issue.
>
>     Have you tried using the modesetting xorg driver instead?
>     Regards
>     --
>     Niclas
>     _______________________________________________
>     [hidden email] <mailto:[hidden email]> mailing list
>     https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>     To unsubscribe, send any mail to
>     "[hidden email]
>     <mailto:[hidden email]>"
>
> A day or two ago I saw a post to this list stating that modesetting was
> not interesting because it did not support 3-D acceleration. At least on
> my Sandy Bridge system running the latest available software for FreeBSD
> 12-STABLE, 3-D acceleration works just fine. This assumes the most
> recently committed mesa, server, drm-fbsd12.0-kmod, etc. It may be that
> modesetting does not provide 3-D on other platforms, but that is not the
> norm, I suspect. If it does normally work, a clear statement to that
> effect would be a "good  thing", though, other than this mailing list, I
> have no idea where to find current status and no idea where else users
> would look.
>
> If it is not going to be maintained, please take down the graphics wiki
> page! It list supporting evdev as "Not started" and everything on it
> seems over a year old. I'm tempted to volunteer to try to update it
> myself, but I am hardly the best informed. I only discovered the
> modesetting driver as an option for Intel GPUs when I had serious issues
> and someone (Jan) suggested I try it.

The modesetting xorg-server driver works fine, and has been working fine
for quite a number of years.  It is the driver used by default, in the
default set up.  You need to explicitly install another xf86-video-*
driver to get something else.  It also should give 3D acceleration (and
has always, to my knowledge, done so).  If you, or anyone else on the
mailing list, have problems using it, it is most likely a bug.
I've been telling people this on mailing lists for a long time, and as I
said before, it is the default configuration.  I don't know what else to
do to squash rumors like this.  It is even stated on the graphics wiki
page that you don't need for instance xf86-video-intel when using drm-kmod.
Regards
--
Niclas
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Kevin Oberman-4
On Tue, Apr 14, 2020 at 12:53 PM Niclas Zeising <[hidden email]>
wrote:

> On 2020-04-14 21:38, Kevin Oberman wrote:
> > On Tue, Apr 14, 2020 at 5:15 AM Niclas Zeising
> > <[hidden email] <mailto:zeising%[hidden email]>>
> wrote:
> >
> >     On 2020-04-14 13:57, Tomasz CEDRO wrote:
> >      > Hello world :-)
> >      >
> >      > I have noticed some bad thing with the X11 Intel driver
> (12.1-RELEASE
> >      > AMD64 with latest intel driver from 2018???) - it eats out all of
> the
> >      > RAM, then it eats all of the SWAP, then system gets unusable for
> >      > anything except hard reset :-( This happens when it works together
> >      > with latest DRM i915KMS. On hard computer use that means
> workstation
> >      > gets useless in around 15 minutes. Closing applications does not
> free
> >      > the memory resources, once it get some some it never returns.
> >
> >     Which driver are you talking about? xf86-video-intel or
> >     drm-fbsd12.0-kmod?
> >
> >      >
> >      > I have set the UXA as the default for i5-5300U CPU.
> >      >
> >      > On the other hand the DRM i915kms works fine with SCFB on the same
> >      > load and hardware. I am working on DRM + i915kms + SCFB so far.
> >
> >     If you are using SCFB, you are not using i915kms.
> >
> >      >
> >      > This is why I suspect problem with X11-INTEL driver? Maybe it
> >     does not
> >      > like latest Xorg changes?
> >      >
> >      > I also sometimes get this DRM warning on the dmesg:
> >      > [drm] Reducing the compressed framebuffer size. This may lead to
> less
> >      > power savings than a non-reduced-size. Try to increase stolen
> memory
> >      > size if available in BIOS.
> >
> >     This is unrelated to this issue.
> >
> >     Have you tried using the modesetting xorg driver instead?
> >     Regards
> >     --
> >     Niclas
> >     _______________________________________________
> >     [hidden email] <mailto:[hidden email]> mailing
> list
> >     https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> >     To unsubscribe, send any mail to
> >     "[hidden email]
> >     <mailto:[hidden email]>"
> >
> > A day or two ago I saw a post to this list stating that modesetting was
> > not interesting because it did not support 3-D acceleration. At least on
> > my Sandy Bridge system running the latest available software for FreeBSD
> > 12-STABLE, 3-D acceleration works just fine. This assumes the most
> > recently committed mesa, server, drm-fbsd12.0-kmod, etc. It may be that
> > modesetting does not provide 3-D on other platforms, but that is not the
> > norm, I suspect. If it does normally work, a clear statement to that
> > effect would be a "good  thing", though, other than this mailing list, I
> > have no idea where to find current status and no idea where else users
> > would look.
> >
> > If it is not going to be maintained, please take down the graphics wiki
> > page! It list supporting evdev as "Not started" and everything on it
> > seems over a year old. I'm tempted to volunteer to try to update it
> > myself, but I am hardly the best informed. I only discovered the
> > modesetting driver as an option for Intel GPUs when I had serious issues
> > and someone (Jan) suggested I try it.
>
> The modesetting xorg-server driver works fine, and has been working fine
> for quite a number of years.  It is the driver used by default, in the
> default set up.  You need to explicitly install another xf86-video-*
> driver to get something else.  It also should give 3D acceleration (and
> has always, to my knowledge, done so).  If you, or anyone else on the
> mailing list, have problems using it, it is most likely a bug.
> I've been telling people this on mailing lists for a long time, and as I
> said before, it is the default configuration.  I don't know what else to
> do to squash rumors like this.  It is even stated on the graphics wiki
> page that you don't need for instance xf86-video-intel when using drm-kmod.
> Regards
> --
> Niclas
>
Niclas, you are pretty much preaching to the choir. I have no issues with
the modesetting driver. It works fine. Being the default, anyone doing a
new install from the distribution will run it. But those with existing
systems who are building ports, as I do on my development system, never see
this change unless there is an entry in ports/UPDATING. That is one reason
that I suspect a lot of people have issues with the drm-kmod and fall back
to the legacy code.

As for the wiki, I do need to take back what I said. If I had not seen the
introductory section so out of date, I would have continued on and
discovered that the Hardware Support section does look current with regard
to Intel system. I have no recent experience with either nVidia or AMD GPU
to have any idea. I am sorry for not looking more closely.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: [hidden email]
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Tomasz CEDRO
In reply to this post by Niclas Zeising-5
On Tue, Apr 14, 2020 at 2:15 PM Niclas Zeising wrote:

>
> On 2020-04-14 13:57, Tomasz CEDRO wrote:
> > Hello world :-)
> >
> > I have noticed some bad thing with the X11 Intel driver (12.1-RELEASE
> > (..)
>
> Which driver are you talking about? xf86-video-intel or drm-fbsd12.0-kmod?
>
> (..)
>
> If you are using SCFB, you are not using i915kms.
>
> (..)
>
> Have you tried using the modesetting xorg driver instead?
> Regards
> --
> Niclas

Well, you are right Niclas, thanks for the reminder, I am sorry, late
working and lots of iterations blurs the picture!

I forgot that xf86-video-intel is for the old cards only, the new way
is to use drm-kmod + xorg modesetting this is my default setup (even
no xorg.conf).

I am sometimes using scfb when no drm is loaded just to have xorg working.

Anyways in a test setup I also did install the xf86-video-intel (along
with scfb and drm-kmod) that was explicitly selected in xorg.conf and
it seems to interfere the way described by eating up the memory. Maybe
there is another reason, I am not yet sure, my workstation was
freezing after some time and I had to hard-reset it. But there is no
need to have this driver when drm-kmod is present. So I have
uninstalled the intel driver and the problem is gone :-)

Best regards :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Theron Tarigo
Please forgive the following for being not exactly related to the memory
leak, but very relevant to scfb vs. modesetting vs. intel:

On 2020-04-14 19:44, Tomasz CEDRO wrote:
> I forgot that xf86-video-intel is for the old cards only
So, new cards (newer than skylake at least) don't encounter
frame-tearing problem (completely unacceptable to me) even with
modesetting driver and no compositor ?  But the software design bug is
still there either way if it can happen on some hardware.  Sorry, I have
no idea whether it's a hardware timing being configured wrong or a
software data race, but when I've heard "use a compositor" proposed as a
solution, it smells of underlying ill-conceived implementation.  I
wouldn't be surprised if Linux graphics has this same problem, but I
don't run that.

Shame to see xf86-video-intel being treated as if it's deprecated
software meanwhile modesetting driver lags behind it on this basic level
of image quality.

> , the new way
> is to use drm-kmod + xorg modesetting this is my default setup (even
> no xorg.conf).
>
> I am sometimes using scfb when no drm is loaded just to have xorg working.
Using scfb with i915kms loaded (yes it does work, no reason not to)
actually gives substantial power savings for me (530 Skylake GT2 0x191b)
compared to using xf86-video-intel: even with Xorg and a few
non-animated graphical apps I can have power consumption on laptop
almost as low as in console, but of course it is not good for video. 
Xorg+xf86-video-intel always wastes a few watts no matter what I try.

Theron
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

pete wright


On 4/14/20 5:40 PM, Theron wrote:

> Please forgive the following for being not exactly related to the
> memory leak, but very relevant to scfb vs. modesetting vs. intel:
>
> On 2020-04-14 19:44, Tomasz CEDRO wrote:
>> I forgot that xf86-video-intel is for the old cards only
> So, new cards (newer than skylake at least) don't encounter
> frame-tearing problem (completely unacceptable to me) even with
> modesetting driver and no compositor ?  But the software design bug is
> still there either way if it can happen on some hardware. Sorry, I
> have no idea whether it's a hardware timing being configured wrong or
> a software data race, but when I've heard "use a compositor" proposed
> as a solution, it smells of underlying ill-conceived implementation. 
> I wouldn't be surprised if Linux graphics has this same problem, but I
> don't run that.
>
> Shame to see xf86-video-intel being treated as if it's deprecated
> software meanwhile modesetting driver lags behind it on this basic
> level of image quality.

to be clear the decision to move to modesetting instead of chip specific
DDX's seems to have been made upstream on the Xorg side.

having said that there are still updates landing upstream to bot the
intel and amdgpu DDX's, but i'm not certain on the long term plan
anymore tbh.  i periodically run the intel DDX and it works well enough
with our drm-kmod (and forcing the "tear-free" option in xorg works with
SNA iirc).  I also run the amdgpu with our drm-kmod daily and have no
issues with xorg there - perf is quite good imho.

-p

--
Pete Wright
[hidden email]
@nomadlogicLA

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Alexey Dokuchaev-4
In reply to this post by Kevin Oberman-4
On Tue, Apr 14, 2020 at 12:38:25PM -0700, Kevin Oberman wrote:
> A day or two ago I saw a post to this list stating that modesetting
> was not interesting because it did not support 3-D acceleration.

I think I was quoting this forum post* by yuripv@, but now I see it's
from 2018 so it might no longer be accurate.  Sorry for confusion.

> At least on my Sandy Bridge system running the latest available
> software for FreeBSD 12-STABLE, 3-D acceleration works just fine.

I'm currently trying to get X11 back to normal on my AMD laptop, and
without `x11-drivers/xf86-video-ati' port installed X server does not
even start, spamming me with "radeon: The kernel rejected CS, see dmesg
for more information (-16)."  Of course, there is nothing useful in
dmesg. :-(

Is "modesetting driver" only a thing in the Intel world, or it should
work for AMD cards too?

./danfe

*) https://forums.freebsd.org/threads/how-to-use-the-old-or-the-new-i915kms-driver-for-intel-integrated-graphics-with-xorg.66732/post-406316
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Tomasz CEDRO
In reply to this post by Kevin Oberman-4
On Tue, Apr 14, 2020 at 9:38 PM Kevin Oberman wrote:
d be a "good  thing", though, other than this mailing list, I have no
idea where to find current status and no idea where else users would
look.
> (..)
> (..) graphics wiki page (..) I'm tempted to volunteer to try to update (..)

I really love FreeBSD for its comprehensive and consistent/coherent
documentation. I always give "The FreeBSD Handbook" as an example of
perfect project documentation. It contains practical examples, is
written both for new and advanced users, can be printed as a book.
Everything in one place always up to date. Also you can type "man
something" and you will usually get a man page for that something.
This is in total opposition to Linux documentation that is spread
around the net on various blogs and mostly irrelevant or outdated.

From what I understand, things under development are usually described
on WIKI. Those wiki pages are sometimes outdated or could contain some
more useful information and examples. But in general the are very
useful and centralized source of information. Having a good WIKI could
save time both for people asking questions and answering questions on
various support media such as mailinglists or forums. Also wiki could
be a source of documentation merge into the Handbook.

Maybe if WIKI access is more liberal (but still moderated) then people
(like me or Kevin) could put more detailed descriptions and examples.
That could be the central point for information exchange on things
under development and then practical examples source for stable stuff.
It could be a single page organized in a Sections like I am used to:
1. Documentation - nicely edited human readable text or information
that then sources the information to The FreeBSD Handbook.
2. TODO - a checklist that would point all tasks and subtasks to be
done and marked as completed.
3. Examples - can show example configurations and use cases to be
quickly applied in the field.
4. Workbench - a developer workbench scratchpad to leave developer
readable comments, notes, memos.
5. References - anything helpful to understand the project for a new
developers or users.

The above sections are just an example that I got used to create when
starting a project (for instance a bit outdated
https://github.com/cederom/icederom) in a form of one simple page with
everything in one place just like in The FreeBSD Handbook does :-)

Besr regards :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Jan Beich-5
In reply to this post by Theron Tarigo
Tomasz CEDRO <[hidden email]> writes:

> On Wed, Apr 15, 2020 at 2:41 AM Theron wrote:
>
>> Shame to see xf86-video-intel being treated as if it's deprecated
>> software meanwhile modesetting driver lags behind it on this basic level
>> of image quality.
>
> Wow, I also noticed a bit better picture quality with Intel driver,
> but I was not sure if this is the driver thing, now it gets more
> probable when also you mention it. To be honest I was a bit surprised
> that it even worked :-) :-)

xf86-video-intel support ends after CoffeeLake. Current version in ports/
is more than 1 year old, so maybe try the patch in bug 236003.

Outside of DDX Intel deprecated pre-Broadwell support:
- beignet is abandoned in favor of compute-runtime (aka NEO)
- intel-vaapi-driver is maintenance-only in favor of media-driver
- i965 development slowed down in favor of iris (default since Mesa 20.0.0)

> I guess this new modesetting driver will catch up quickly and get into
> the point of better picture quality.. maybe there is some additional
> setup that could improve things already?

Unlikely. modesetting reached "good enough" level while X11 is
deprecated in favor of Wayland. Compared to Mesa or Wayland compositors
there's little activity in xserver repo nowadays.

See also https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/24

Given modesetting uses glamor picture quality may depend on Mesa.
Try using more recent version, especially "iris" driver.

https://github.com/myfreeweb/freebsd-ports-dank/blob/lite/graphics/mesa-dev
https://github.com/evadot/freebsd-ports/tree/mesa/graphics/mesa
https://reviews.freebsd.org/D23161
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Tomasz CEDRO
On Fri, Apr 17, 2020 at 7:02 PM Jan Beich <[hidden email]> wrote:
> xf86-video-intel support ends after CoffeeLake. Current version in ports/
> is more than 1 year old, so maybe try the patch in bug 236003.
>
> Outside of DDX Intel deprecated pre-Broadwell support:
> - beignet is abandoned in favor of compute-runtime (aka NEO)
> - intel-vaapi-driver is maintenance-only in favor of media-driver
> - i965 development slowed down in favor of iris (default since Mesa 20.0.0)

Thank you Jan! To be honest I just need several monitors to work, web
browser, KiCAD, FreeCAD, Blender, most of my work I do in a
terminal+tmux anyway :-) Nice image quality, 3D acceleration, and
OpenCL would be really nice to have but not a blocker to work (it
would bring efficiency and comfort for sure). For years I was using
simple vesa video driver on my FreeBSD laptop and I could live with
that. I had another machine for multimedia (macOS). Now  I am working
only on a FreeBSD laptop, so basic work requirements come first. I am
keeping my fingers for DRM KMS Intel for my laptop (multiple monitors)
and AMDGPU OpenCL for my workstation (GPU computing). Threre is no
reason to invest time into something that is dead already (x11-intel).


> Unlikely. modesetting reached "good enough" level while X11 is
> deprecated in favor of Wayland. Compared to Mesa or Wayland compositors
> there's little activity in xserver repo nowadays.

For years I did work on Xfce4. Now I am working on Enlightenment WM,
they stated Weyland support is already there and they plan to abandon
X11, so maybe its time to play again with Weyland, thanks for
motivating :-)


> See also https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/24
>
> Given modesetting uses glamor picture quality may depend on Mesa.
> Try using more recent version, especially "iris" driver.
>
> https://github.com/myfreeweb/freebsd-ports-dank/blob/lite/graphics/mesa-dev
> https://github.com/evadot/freebsd-ports/tree/mesa/graphics/mesa
> https://reviews.freebsd.org/D23161

Its good to know people are working on it.. should show up one day on
my desktop too :-)

Best regards! :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Alexey Dokuchaev-4
In reply to this post by Jan Beich-5
On Fri, Apr 17, 2020 at 07:01:49PM +0200, Jan Beich wrote:
> ...
> Unlikely. modesetting reached "good enough" level while X11 is
> deprecated in favor of Wayland.

X11 is certainly not going anywhere as it mostly works just fine and no
replacement is needed.  You guys can play with Wayland or whatever the
next cool kid on the block is called as long as you wish but please let
it be your pain, not ours.

Deprecating X11, huh.  That's preposterous!

./danfe
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Warner Losh
On Fri, Apr 17, 2020 at 8:49 PM Alexey Dokuchaev <[hidden email]> wrote:

> On Fri, Apr 17, 2020 at 07:01:49PM +0200, Jan Beich wrote:
> > ...
> > Unlikely. modesetting reached "good enough" level while X11 is
> > deprecated in favor of Wayland.
>
> X11 is certainly not going anywhere as it mostly works just fine and no
> replacement is needed.  You guys can play with Wayland or whatever the
> next cool kid on the block is called as long as you wish but please let
> it be your pain, not ours.
>
> Deprecating X11, huh.  That's preposterous!


The day will come. Not today, but when upstream stops supporting it...  The
writing is on the wall...

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

pete wright
In reply to this post by Alexey Dokuchaev-4


On 4/17/20 7:49 PM, Alexey Dokuchaev wrote:

> On Fri, Apr 17, 2020 at 07:01:49PM +0200, Jan Beich wrote:
>> ...
>> Unlikely. modesetting reached "good enough" level while X11 is
>> deprecated in favor of Wayland.
> X11 is certainly not going anywhere as it mostly works just fine and no
> replacement is needed.  You guys can play with Wayland or whatever the
> next cool kid on the block is called as long as you wish but please let
> it be your pain, not ours.
>
> Deprecating X11, huh.  That's preposterous!
You should let the Xorg development team know your opinions on this
topic.  the freebsd graphics team is trying to make sure that when
upstream does make the cut over to wayland we are not left totally out.

i would also say that *now* (well probably several years ago) is the
time for us as a community to get engaged with wayland development.
there are already lots of linux and systemd assumptions being made by
their development efforts, so this is our opportunity to make sure our
voices are heard before it's too late.

personally my biggest worry is that wayland going to end up being even
more tightly coupled with logind/systemd and we'll be left with the
choice of no modern graphics stack or having to adopt systemd in some
way.  i'd hazard a guess that this is a situation that none of us would
be too happy with.


-p

--
Pete Wright
[hidden email]
@nomadlogicLA

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Niclas Zeising-5
In reply to this post by Tomasz CEDRO
On 2020-04-17 21:09, Tomasz CEDRO wrote:

> On Fri, Apr 17, 2020 at 7:02 PM Jan Beich <[hidden email]> wrote:
>> xf86-video-intel support ends after CoffeeLake. Current version in ports/
>> is more than 1 year old, so maybe try the patch in bug 236003.
>>
>> Outside of DDX Intel deprecated pre-Broadwell support:
>> - beignet is abandoned in favor of compute-runtime (aka NEO)
>> - intel-vaapi-driver is maintenance-only in favor of media-driver
>> - i965 development slowed down in favor of iris (default since Mesa 20.0.0)
>
> Thank you Jan! To be honest I just need several monitors to work, web
> browser, KiCAD, FreeCAD, Blender, most of my work I do in a
> terminal+tmux anyway :-) Nice image quality, 3D acceleration, and
> OpenCL would be really nice to have but not a blocker to work (it
> would bring efficiency and comfort for sure). For years I was using
> simple vesa video driver on my FreeBSD laptop and I could live with
> that. I had another machine for multimedia (macOS). Now  I am working
> only on a FreeBSD laptop, so basic work requirements come first. I am
> keeping my fingers for DRM KMS Intel for my laptop (multiple monitors)
> and AMDGPU OpenCL for my workstation (GPU computing). Threre is no
> reason to invest time into something that is dead already (x11-intel).

You should be able to get this with drm-kmod as the kernel driver and
the modesetting xorg-server driver, everything except OpenCL, at least.
For AMDGPU you might still want to use xf86-video-amdgpu instead of
modesetting, if you prefer.

Regards
--
Niclas
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Niclas Zeising-5
In reply to this post by pete wright
On 2020-04-18 05:58, Pete Wright wrote:

>
>
> On 4/17/20 7:49 PM, Alexey Dokuchaev wrote:
>> On Fri, Apr 17, 2020 at 07:01:49PM +0200, Jan Beich wrote:
>>> ...
>>> Unlikely. modesetting reached "good enough" level while X11 is
>>> deprecated in favor of Wayland.
>> X11 is certainly not going anywhere as it mostly works just fine and no
>> replacement is needed.  You guys can play with Wayland or whatever the
>> next cool kid on the block is called as long as you wish but please let
>> it be your pain, not ours.
>>
>> Deprecating X11, huh.  That's preposterous!
> You should let the Xorg development team know your opinions on this
> topic.  the freebsd graphics team is trying to make sure that when
> upstream does make the cut over to wayland we are not left totally out.
>
> i would also say that *now* (well probably several years ago) is the
> time for us as a community to get engaged with wayland development.
> there are already lots of linux and systemd assumptions being made by
> their development efforts, so this is our opportunity to make sure our
> voices are heard before it's too late.

The Freedesktop.org upstream (the ones responsible for xorg and wayland)
are aware of us, and quite helpful in getting FreeBSD specific code in,
so I'm not too worried there (as long as we bring the code, at least).
I'm more worried about the people making various wayland compositors and
wayland desktop environments though.

>
> personally my biggest worry is that wayland going to end up being even
> more tightly coupled with logind/systemd and we'll be left with the
> choice of no modern graphics stack or having to adopt systemd in some
> way.  i'd hazard a guess that this is a situation that none of us would
> be too happy with.
>

With regards to logind/systemd, what we need to provide is most likely a
session manager of some sort, or at least an interface to FreeBSD
session handling, where it is possible to plug in such a thing.

Regards
--
Niclas
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Niclas Zeising-5
In reply to this post by Alexey Dokuchaev-4
On 2020-04-15 11:30, Alexey Dokuchaev wrote:

> On Tue, Apr 14, 2020 at 12:38:25PM -0700, Kevin Oberman wrote:
>> A day or two ago I saw a post to this list stating that modesetting
>> was not interesting because it did not support 3-D acceleration.
>
> I think I was quoting this forum post* by yuripv@, but now I see it's
> from 2018 so it might no longer be accurate.  Sorry for confusion.
>
>> At least on my Sandy Bridge system running the latest available
>> software for FreeBSD 12-STABLE, 3-D acceleration works just fine.
>
> I'm currently trying to get X11 back to normal on my AMD laptop, and
> without `x11-drivers/xf86-video-ati' port installed X server does not
> even start, spamming me with "radeon: The kernel rejected CS, see dmesg
> for more information (-16)."  Of course, there is nothing useful in
> dmesg. :-(
>
> Is "modesetting driver" only a thing in the Intel world, or it should
> work for AMD cards too?
>

To my knowledge, it should work on all cards with a modesetting driver
(meaning intel, various versions of the AMD/ATI driver, and nVidia, at
least).  AMD hasn't been as aggressive in deprecating
xf86-video-[ati,amdgpu] as intel has been with xf86-video-intel though.
This might also be an issue with drm-legacy-kmod vs. drm-kmod.
Regards
--
Niclas
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Tomasz CEDRO
In reply to this post by Niclas Zeising-5
On Sat, Apr 18, 2020 at 8:36 AM Niclas Zeising wrote:
> You should be able to get this with drm-kmod as the kernel driver and
> the modesetting xorg-server driver, everything except OpenCL, at least.
> For AMDGPU you might still want to use xf86-video-amdgpu instead of
> modesetting, if you prefer.

I am using drm-kmod for both intel and amdgpu, thank you for you work! :-)

Do you know when OpenCL support may show up? That would be highly
desired to speed up complex computations :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: drm-i915kms + x11-intel eats out all of the ram and swap but not with x11-scfb

Tomasz CEDRO
In reply to this post by Tomasz CEDRO
On Fri, Apr 17, 2020 at 9:09 PM Tomasz CEDRO wrote:

> On Fri, Apr 17, 2020 at 7:02 PM Jan Beich wrote:
> > Given modesetting uses glamor picture quality may depend on Mesa.
> > Try using more recent version, especially "iris" driver.
> >
> > https://github.com/myfreeweb/freebsd-ports-dank/blob/lite/graphics/mesa-dev
> > https://github.com/evadot/freebsd-ports/tree/mesa/graphics/mesa
> > https://reviews.freebsd.org/D23161
>
> Its good to know people are working on it.. should show up one day on
> my desktop too :-)

I made it to compile and run MESA-20 (and some of its dependencies)
from provided references on 12.1-RELEASE :-) But I can see no change
in picture quality.. I noticed some troubles with Xinerama
(multi-monitor) on Enlightenment but it worked fine on Xfce4. Because
other software seems to depend on mesa I have rolled back to version
18.

I have recompiled the MESA-DRI 18 port with VAPPI and VDPAU support
enabled I hope that can speed up anything :-)

Thanks! :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[hidden email]"
12