,
-ilia
On Mon, Jun 22, 2020 at 2:15 PM Jeroen Diederen wrote:
>
> This is with 64k page size.
>
>
>
> Ilia Mirkin schreef op 2020-06-22 19:27:
> > I suspect screen tearing (as it's usually defined) is to be expected.
> > Can you take a photo of what you're see
h 64k and 4k page size.
> My iMac G5 has an nVidia Geforce FX 5200 Ultra GPU.
>
> Regards,
> Jeroen
>
> Ilia Mirkin schreef op 2020-06-22 17:25:
> > Which GPU do you have? The NV40 AGP board (GeForce 6800) works
> > particularly poorly. However as long as you go with
Which GPU do you have? The NV40 AGP board (GeForce 6800) works
particularly poorly. However as long as you go with 4k pages (and
there's no real benefit to 64k pages for most applications), basic
things should work. I wouldn't recommend using a GL-based compositor
though.
Which distortion are you
Hi Boris,
There was a fixup to that patch that you'll also have to revert first
-- 7dbbdd37f2ae7dd4175ba3f86f4335c463b18403. I guess there's some
subtle difference between the old open-coded logic and the helper,
they were supposed to be identical.
Cheers,
-ilia
On Thu, Jun 18, 2020 at 4:09
On Thu, Jun 4, 2020 at 12:04 PM Zeno Davatz wrote:
>
> Thank you, Ilia
>
> On Thu, Jun 4, 2020 at 5:25 PM Ilia Mirkin wrote:
>
> > There's a lot more firmware files than that ... everything in the
> > gp107 directory. Also this would only be necessary if nouveau i
On Thu, Jun 4, 2020 at 11:16 AM Zeno Davatz wrote:
>
> On Thu, Jun 4, 2020 at 4:36 PM Ilia Mirkin wrote:
> >
> > Starting with kernel 5.6, loading nouveau without firmware (for GPUs
> > where it is required, such as yours) got broken.
> >
> > You are loading n
Starting with kernel 5.6, loading nouveau without firmware (for GPUs
where it is required, such as yours) got broken.
You are loading nouveau without firmware, so it fails.
The firmware needs to be available to the kernel at the time of nouveau loading.
Cheers,
-ilia
On Thu, Jun 4, 2020 at
On Fri, May 29, 2020 at 2:35 PM Marc MERLIN wrote:
>
> Howdy,
>
> So, I have a Thinkpad P70 with hybrid graphics.
> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M]
> (rev a2)
> that one works fine, I can use i915 for the main screen, and nouveau to
> display on the
Isn't this already fixed by
https://cgit.freedesktop.org/drm/drm/commit/?id=7dbbdd37f2ae7dd4175ba3f86f4335c463b18403
On Wed, May 27, 2020 at 9:43 AM Arnd Bergmann wrote:
>
> Calling directly into the fbdev stack only works when the
> fbdev layer is built into the kernel as well, or both are
>
Hi Andreas,
On Mon, May 18, 2020 at 9:56 AM Andreas Schwab wrote:
>
> On Mai 18 2020, Michael Ellerman wrote:
>
> > The old drivers may be crufty but they presumably have been tested by
> > people and at least somewhat work.
>
> I can confirm that the nvidia fbdev driver is working perfectly
On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 43bcbb6d73c4..6dae00da5d7e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++
, May 8, 2020 at 11:13 AM Milan Buška wrote:
>
> Thanks for the info.
> I'll pull it out in a year and try it.
>
> Greeting
>
> pá 8. 5. 2020 v 15:27 odesílatel Ilia Mirkin napsal:
> >
> > On Fri, May 8, 2020 at 4:34 AM Milan Buška wrote:
> > >
> > &g
On Fri, May 8, 2020 at 4:34 AM Milan Buška wrote:
>
> Good day.
> I'm not a programmer, so I don't understand.
>
> Just a question:
> What's wrong =>
> => nouveau driver
> => pcie driver
> => graphics card
>
> It will help me save unnecessary lost time.
Most likely the issue is in nouveau.
On Thu, May 7, 2020 at 12:11 AM Milan Buska wrote:
>
> On 20-05-06 18:53:00, Ilia Mirkin wrote:
> > On Wed, May 6, 2020 at 5:59 PM Milan Buska wrote:
> > >
> > > On 20-05-06 17:12:44, Ilia Mirkin wrote:
> > > > You need both VRAM *and* UNCACHED. Separate
On Wed, May 6, 2020 at 10:42 AM Ilia Mirkin wrote:
> On Wed, May 6, 2020 at 10:39 AM Lucas Stach wrote:
> > > > [ 17.146929] nouveau :01:00.0: DRM: core notifier timeout
> > > > [ 19.146846] nouveau :01:00.0: DRM: base-0: timeout
> > > > [
On Wed, May 6, 2020 at 10:39 AM Lucas Stach wrote:
>
> Am Mittwoch, den 06.05.2020, 10:26 -0400 schrieb Ilia Mirkin:
> > [please keep list cc'd in your replies]
> >
> > On Wed, May 6, 2020 at 10:15 AM Milan Buška wrote:
> > > [0.00] Linux version 5.6.
[please keep list cc'd in your replies]
On Wed, May 6, 2020 at 10:15 AM Milan Buška wrote:
> [0.00] Linux version 5.6.10-zotac (root@saux) (gcc version 9.3.0
> (SAUX Aarch64)) #1 SMP PREEMPT Tue May 5 22:16:40 CEST 2020
> [0.00] Machine model: NVIDIA Jetson TX2 Developer Kit
In general it should be possible. If you're having issues, please include dmesg.
One issue that has come up is that the PCIe controllers on such boards
have very narrow memory windows, not enough to map certain (required)
BARs of NVIDIA GPUs (or other GPUs, I'd expect). This comes up in
dmesg
non-desktop: 0
> supported: 0, 1
> 2560x1440 59.91*+
>
> On 5/5/20 11:17 AM, Ilia Mirkin wrote:
> > On Tue, May 5, 2020 at 11:02 AM Alberto Sentieri <2...@tripolho.com> wrote:
> >> I have two monitors connected to the PC. One is an AOC 23" (1920
On Tue, May 5, 2020 at 11:02 AM Alberto Sentieri <2...@tripolho.com> wrote:
>
> I have two monitors connected to the PC. One is an AOC 23" (1920 x 1080)
> and the other is a BenQ 27" (2560 x 1440). Nothing special about them.
> BenQ has a display port and the AOC uses some sort of DVI adapter.
Do
The warning you included happens when we're trying to execute a VBIOS
script as part of DP training. Can you include your vbios? It should
be available at /sys/kernel/debug/dri/0/vbios.rom
Also, can you confirm how your monitors are connected to the card (and
e.g. what resolution they are,
On Fri, May 1, 2020 at 9:15 AM Souptick Joarder wrote:
>
> On Fri, May 1, 2020 at 2:21 AM Ilia Mirkin wrote:
> >
> > Interesting. I do remember seeing some snow on NV5's overlay at high
> > resolutions. Wonder if it was because of this missing code...
>
> What w
Interesting. I do remember seeing some snow on NV5's overlay at high
resolutions. Wonder if it was because of this missing code...
On Thu, Apr 30, 2020 at 4:19 PM Souptick Joarder wrote:
>
> These are dead code since 3.10. If there is no plan to use
> it further, these can be removed forever.
>
On Thu, Apr 30, 2020 at 3:32 AM Alexey Dobriyan wrote:
>
> On Thu, Apr 30, 2020 at 12:15:28AM -0400, Ilia Mirkin wrote:
> > Hi Alexey,
> >
> > On Fri, Apr 24, 2020 at 10:52 PM Alexey Dobriyan
> > wrote:
> > >
> > > gp104 refuses to switch to "
Hi Alexey,
On Fri, Apr 24, 2020 at 10:52 PM Alexey Dobriyan wrote:
>
> gp104 refuses to switch to "graphic" mode and show anything past
> this line:
>
> fb0: switching to nouveaufb from EFI VGA
>
> Machine is fine, as it I can press Ctrl+Alt+Delete and reboot it
> normally.
>
> 5.5 is
Does it print anything else before that?
There's definitely some dubious endian-unsafe code in the later
nouveau stuff. For example, nvkm_falcon_v1_read_dmem seems to make
assumptions about CPU being LE, based on a quick read of the code, and
I would expect the file header parsing stuff does too.
I'll quickly improve. :)
Perfect so far!
>
> El lun., 30 mar. 2020 a las 13:38, Ilia Mirkin
> () escribió:
> >
> > Yes, GF108 is Fermi (F = Fermi). Reclocking is currently not available
> > for that generation, unfortunately. You should be able to otherwise
> >
On Fri, Apr 3, 2020 at 1:59 PM Zeno Davatz wrote:
>
> On Fri, Apr 3, 2020 at 7:23 PM Ilia Mirkin wrote:
> >
> > On Fri, Apr 3, 2020 at 1:21 PM Zeno Davatz wrote:
> > >
> > > On Fri, Apr 3, 2020 at 6:59 PM Ilia Mirkin wrote:
> > > >
> > >
On Fri, Apr 3, 2020 at 1:21 PM Zeno Davatz wrote:
>
> On Fri, Apr 3, 2020 at 6:59 PM Ilia Mirkin wrote:
> >
> > Ben -- probably the ACR changes in 5.6 don't fall back nicely anymore
> > when there's no firmware? The load shouldn't be failed, just GR
> > disabled.
Ben -- probably the ACR changes in 5.6 don't fall back nicely anymore
when there's no firmware? The load shouldn't be failed, just GR
disabled...
Zeno -- if you grab linux-firmware, it should be all better. Not sure
if you're missing it on purpose or by accident.
Cheers,
-ilia
On Fri, Apr 3,
gt; > j
> >
> > On Tuesday, January 14, 2020 8:52:51 AM AKST Joshua J. Kugler wrote:
> > > Here we go!
> > >
> > > j
> > >
> > > On Tuesday, January 14, 2020 7:08:20 AM AKST Ilia Mirkin wrote:
> > > > Hi Joshua,
>
Yes, GF108 is Fermi (F = Fermi). Reclocking is currently not available
for that generation, unfortunately. You should be able to otherwise
use your GPU just fine, but I'm guessing it'll come up in the "07"
state when it powers on (in the state as-is it appears powered off,
which it will do
I believe that there's a single shared resource for MME in GRAPH, not
separate ones for separate classes. Ultimately, the classes just
provide frontends for the single internal GRAPH engine. (This is
probably also why setting some stuff on the compute class "unsets" it
on the 3d class, or
Hi Jasmin,
On Sun, Mar 1, 2020 at 11:32 AM Jasmin wrote:
>
> Hi,
>
> for quite some time now I would like to switch from the proprietary driver to
> nouveau, using a GK107 (Quadro) in a thinkpad.
> Unfortunately the monitors connected to the lenovo "ultra dock" are not
> properly recognized
Can you try to figure out what was updated in the latest updates? My
guess would be that it's actually the software used to display your
desktop/etc which changed.
You can disable all accel by booting with nouveau.noaccel=1.
Cheers,
-ilia
On Sat, Feb 29, 2020 at 12:31 AM Juan Manuel Alvarez
d
Author: Ben Skeggs
Date: Wed May 29 09:58:18 2019 +1000
drm/nouveau/kms: disallow dual-link harder if hdmi connection detected
and went into v5.3. I'm not sure where this got broken... I think it
would have been
commit 9340d77f5327ea673a7f95f58139123d7a278243
Author: Ilia Mirki
On Tue, Feb 25, 2020 at 10:59 AM Thomas Zimmermann wrote:
>
> Non-KMS drivers store state in struct drm_driver. This bloats the
> structure for KMS drivers and prevents it from being declared with
> 'static const' qualifiers. Moving the non-KMS state into a separate
> data structure resolves
On Sat, Feb 22, 2020 at 1:02 PM Lukas Schubert wrote:
>
> Hi list,
>
> my media center PC is freshly installed with Debian 10.2 "Buster". It doesn't
> support Geforce 6800 GT (NV40) boards through the nvidia nor the
> nvidia-legacy drivers any longer. The legacy drivers worked up until Debian 9
Hi Frédéric,
It appears Ben made his own version of this patch (probably based on
the one you added to the kernel bz), and it's already upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2=0e6176c6d286316e9431b4f695940cfac4ffe6c2
Cheers,
-ilia
On
So ... for Vulkan, the API requires allocating VA before declaring
what goes into that VA (e.g. an image or data). I believe our plan for
that was to move all this into userspace, which would allocate VA and
then just tell the kernel "make VA range X have memtype Y". At that
point, nouveau_bo
All GPUs supported by nouveau (Riva TNT and newer) can work without
additional firmware. It all depends on the definition of what one
means by "work", of course.
Across the board, modesetting works without any additional firmware
(i.e. lighting up displays, making pictures appear on them),
t; and removed the snap
>
> Then installed the kernel (see below) and had the issue again
>
> I also tried running specific applications individually to see if it was
> related to only a certain app but, that was not the case
>
>
> Thanks
>
> Dave
>
>
>
> O
This is not a known issue. No GPU support has been dropped from nouveau
(thus far, nor ever, I expect). Did you update anything other than the
kernel?
Cheers,
-ilia
On Thu, Jan 30, 2020 at 7:27 AM Dave wrote:
> Not sure if this is the correct forum for this question / issue so please
> feel
On Wed, Jan 29, 2020 at 5:03 AM riveravaldez wrote:
>
> On 12/11/18, Ilia Mirkin wrote:
> > On Tue, Dec 11, 2018 at 11:16 AM riveravaldez
> > wrote:
> >
> >> The freezes appears randomly, in every situation, and not when I
> >> launch some 3D app
Hi Joshua,
Not a fix for your issue, but Ben noticed this (and fixed it):
https://github.com/skeggsb/nouveau/commit/024bda7d2b0c3b0731433d60a494c78ab58cb216
which is what causes us to even try 540MB/s link training. However
with this fix applied, it'll just give up faster. I'm told eDP is
Probably want ULL for 32-bit arches to be correct here too.
On Tue, Dec 31, 2019 at 3:53 PM Wambui Karuga wrote:
>
> Explicitly declare constants are unsigned long to address the following
> sparse warnings:
> warning: constant is so big it is long
>
> Signed-off-by: Wambui Karuga
> ---
>
ave some tearing when
> something it's moving a lot in videos.
>
> Definitely it was the solution for flickering issue.
>
> Have a nice day
>
> Enviado desde mi Samsung Mobile de Claro
>
>
> ---- Original message
> From: Ilia Mirkin
> Date: 12/27/19 7
s flickering, just screen off and on suddenly
> in shorts periods of time.
>
> I have this problem with videos in YouTube using Firefox, and local videos
> using vlc and MPlayer for example.
>
>
> Enviado desde mi Samsung Mobile de Claro
>
>
>
> Orig
(and vdpau
decoding), or Xv? (What video player are you using?)
On Fri, Dec 27, 2019 at 8:33 AM Jairo Quintanilla
wrote:
>
> I'm using xorg and nouveau, not modesetting.
>
>
> Thanks for your response.
>
>
>
> Enviado desde mi Samsung Mobile de Claro
>
>
>
> -
Are you on Xorg or wayland of some sort? If on Xorg, which DDX are you
using -- nouveau or modesetting?
On Fri, Dec 27, 2019 at 3:13 AM Jairo Quintanilla
wrote:
>
> Hi mates,
>
> First to all thanks for your help.
>
> I've installed Nouveau driver for my Nvidia GeForce GT210 using Archlinux,
>
Nouveau should work largely OK, although the Tesla series (to which
your card belongs) has some unfortunate random hang issues due to what
we suspect is an incorrect FIFO channel switch procedure.
Support should already exist in any linux distro, so as long as you
don't do anything to proactively
uot; works
well for you.
On Thu, Dec 19, 2019 at 3:27 PM Marcin Zajączkowski wrote:
>
> On 2019-12-16 19:45, Ilia Mirkin wrote:
> > The obvious candidate based on a quick scan is
> > 0acf5676dc0ffe0683543a20d5ecbd112af5b8ee -- it merges a fix that
> > messes with PCI stuff
ensuring that the good kernel
is really good and the bad kernel is really bad -- boot them a few
times.
Cheers,
-ilia
On Mon, Dec 16, 2019 at 12:42 PM Marcin Zajączkowski wrote:
>
> On 2019-12-16 18:08, Ilia Mirkin wrote:
> > Hi Marcin,
> >
> > You should do a git bisect ra
Hi Marcin,
You should do a git bisect rather than guessing about commits. I
suspect that searching for "kernel git bisect fedora" should prove
instructive if you're not sure how to do this.
Cheers,
-ilia
On Mon, Dec 16, 2019 at 11:42 AM Marcin Zajączkowski wrote:
>
> Hi,
>
> I've
On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote:
>
> Allow setting the block layout of a nouveau FB
> object using DRM format modifiers. When
> specified, the format modifier block layout and
> kind overrides the GEM buffer's implicit layout
> and kind. The specified format modifier is
>
Observed an issue when looking at the code generatedy by the
image-vertex-attrib-input-output piglit test. Even though the test
itself worked fine (due to TIC 0 being used for the image), this needs
to be fixed.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen
-layered_binding without breaking
anything else.
Signed-off-by: Ilia Mirkin
---
OK, first of all -- to whoever thought that binding single layers of a 3d
image and telling the shader they were regular 2d images was a good idea --
I disagree.
This change feels super super dirty, but I honestly don't
without doing the explicit move-in.
Signed-off-by: Ilia Mirkin
---
This fixes some crashes on a NV5 with 32MB VRAM + xfwm4 --vblank=present,
however the failure modes (e.g. pixmap doesn't have backing) can happen
anywhere I believe, just much less likely.
src/nouveau_dri2.c| 18
less than 8192. The current logic will align
1920*4 up to 8192 unnecessarily.
Signed-off-by: Ilia Mirkin
Cc: Marcin Kościelnicki
Cc: Francisco Jerez
---
src/nouveau_dri2.c | 5 -
src/nv_driver.c| 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/nouveau_dri2.c b
On Sun, Sep 29, 2019 at 4:46 AM pete wrote:
>
>
> Hi .
>
> I am having a very annoying problem not sure where the root of it lies
>
> When running FLdigi it runs fine for about 10 mineuts then i start
> getting errors leading to a complete lock up that needs a power button
> to free it up i get
On Thu, Sep 26, 2019 at 5:44 PM Ben Skeggs wrote:
>
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
> >
> > Hi guys,
> >
> > while working through more old TTM functionality I stumbled over the
> > io_reserve_lru.
> >
> > Basic idea is that when this flag is set the
On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang wrote:
>
> cpp[BytePerPlane] can't describe the 10bit data format correctly,
> So we use bpp[BitPerPlane] to instead cpp.
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ---
>
On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul wrote:
>
> When drm_connector_helper_funcs->atomic_best_encoder is defined,
> ->best_encoder is ignored both by the atomic modesetting helpers. That
By both the atomic modesetting helpers and ... (usually "both" implies 2 things)
> being said, this
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote:
>
> On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote:
> >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote:
> >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> >> >
On Fri, Sep 13, 2019 at 10:46 AM Sasha Levin wrote:
>
> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> >Hi Greg,
> >
> >This feels like it's missing a From: line.
> >
> >commit b513a18cf1d705bd04efd91c417e79e4938be093
> >Author: Lyude
Hi Greg,
This feels like it's missing a From: line.
commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul
Date: Mon Jan 28 16:03:50 2019 -0500
drm/nouveau: Don't WARN_ON VCPI allocation failures
Is this an artifact of your notification-of-patches process and I
never noticed
On Thu, Sep 12, 2019 at 3:00 PM Karol Herbst wrote:
>
> taken from nvgpu
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/nvkm/subdev/pci/gk104.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c
> b/drm/nouveau/nvkm/subdev/pci/gk104.c
>
On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding wrote:
>
> On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > Changing the order doesn't look hard. Patch attached (untested, have
> > > > > no
> > >
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Signed-off-by: Ilia Mirkin
---
Only tested on G84 and GK208. The GV100+ is entirely untested.
With the fixed modetest tool, setting ilut and olut sizes to different
Can you check to see if that bit was set prior to entering the code? I
wonder if you can just restore it if it was there, and leave it if
it's not?
On Wed, Sep 4, 2019 at 10:28 AM Mark Menzynski wrote:
>
> I have looked at problem with Fermi GPUs where changing to higher clock
> led to really
On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä
wrote:
>
> On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> > wrote:
> > >
> > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
&
On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
wrote:
>
> On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> > This should probably be fixed to account for the scenario where an
> > HDMI connector is plugged directly into the DP++ port. I don't think
> > the
This should probably be fixed to account for the scenario where an
HDMI connector is plugged directly into the DP++ port. I don't think
the dp.subconnector property will be valid in that case.
(Unfortunately I don't remember how one detects that particular
situation.)
On Mon, Aug 26, 2019 at 9:22
On Wed, Aug 14, 2019 at 7:37 AM Ralph Corderoy wrote:
>
> Hi Ilia,
>
> A fortnight ago, you wrote:
> > > The video plays, CPU load is less (my aim), but there's ‘tearing’ of
> > > the picture as if small rectangles that are updates are appearing in
> > > the wrong location, off by a little. If I
On Wed, Aug 7, 2019 at 5:55 PM Daniel Vetter wrote:
>
> On Wed, Aug 07, 2019 at 05:33:00PM -0400, Lyude Paul wrote:
> > The code claims to grab a runtime PM ref when at least one CRTC is
> > active, but that's not actually the case as we grab a runtime PM ref
> > whenever a CRTC is enabled
That's OK - nouveau doesn't let you pick bit depth either (yet). It's
all 8bpc - higher bpc mode support will come ... eventually.
On Tue, Aug 6, 2019 at 5:25 PM James wrote:
>
> I think I may have updated the tv firmware between when it worked and
> when it didn't.
> I wonder it it has to do
Can you try something very simple - unplug the cable, and plug it back
in, while the TV is on, and set to the HDMI input? That should ensure
that the SCDC write can go through at modeset time.
You can also force nouveau to avoid any modes that require scrambling
by booting with
Hi James,
I semi-recently added support for HDMI 2.0 (in 4.20+, so you're good),
which is why you got 60Hz in the first place. In order for the high
rates to work, something called "scrambling" must be enabled. This is
done by 2-party agreement between the sink and the source. The sink
will
On Mon, Jul 29, 2019 at 7:29 AM Solerman Kaplon wrote:
>
> Às 14:46 de 27/07/2019, Ilia Mirkin escreveu:
> > On Sat, Jul 27, 2019 at 7:37 AM Ralph Corderoy
> > wrote:
> >> The video plays, CPU load is less (my aim), but there's ‘tearing’ of the
> >
On Sat, Jul 27, 2019 at 7:37 AM Ralph Corderoy wrote:
> The video plays, CPU load is less (my aim), but there's ‘tearing’ of the
> picture as if small rectangles that are updates are appearing in the
> wrong location, off by a little. If I step through the frames with
> mpv's ‘.’ and ‘,’ then
On Mon, Jul 15, 2019 at 2:34 PM Fernando Sahmkow wrote:
>
> So we have been busy implementing the compute engine lately but we have
> discovered a few issues with Compute Shaders. I hope you guys can answer some
> questions.
>
> 1st How do I determine the size of Compute Shaders/Kernel Local
Please add a config override to skip this, since we'll invariably get
it wrong for some setup, and should be able to provide users with
workarounds while the issue is being worked out.
On Mon, Jul 15, 2019 at 5:43 AM Mark Menzynski wrote:
>
> Currently, nouveau doesn't check if GPU is missing
I believe that NVDec is similar to the MSDEC engines (BSP, VP, and
PPP) on Kepler GPUs. You can see the details of the various bits being
submitted here:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nouveau_vp3_video.h
On Wed, Jul 3, 2019 at 1:49 PM Ralph Campbell wrote:
> On 6/30/19 11:20 PM, Christoph Hellwig wrote:
> > hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
> > the current nouvea flow. Move it to the only user in preparation for
>
> I didn't quite parse the phrase "quite
Yeah, this is a little confusing. It's important to remember how
queries work in the first place, which informs how conditional
rendering works.
There are two kind of queries (QUERY_ADDRESS_HIGH & co) -- "short" and
"long". A "short" query value is a single 32-bit value, presumably the
value of
>
>
> On Saturday, June 22, 2019, 2:19:31 PM EDT, Ilia Mirkin <
> imir...@alum.mit.edu> wrote:
>
>
> Mar - can you provide the output of
>
> lspci -nn -d 10de:
>
> On Sat, Jun 22, 2019 at 2:17 PM Lyude Paul wrote:
>
> Hi, is this actually an n
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Finally, experimental evidence suggests you can't mix sizes for degamma
and gamma. Disallow this as well.
Signed-off-by: Ilia Mirkin
---
Note that all the gv100+ changes
> When switching to VGA cable, the only changes are in the gamma, brightness,
> and Identifier values. I don't find anything which refers to DP or a port.
> What else can I do to narrow it down?
> --
> Harald Harders
> harald.hard...@gmx.de
>
>
> Gesendet: Dienstag, 18. J
On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
wrote:
>
> On (06/19/19 01:20), Ilia Mirkin wrote:
> > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > wrote:
> > >
> > > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > > dmesg
> &
On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
wrote:
>
> On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > dmesg
> >
> > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> > nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> > nouveau :01:00.0: fifo:
oblem.
>
> Best regards
> Harald
>
> PS: I guess sending to the mailing list and omitting your personal mail
> address is correct, right?
>
>
> Gesendet: Dienstag, 18. Juni 2019 um 21:36 Uhr
> Von: "Ilia Mirkin"
> An: "Harald Harders"
> Cc: nouveau
Which kernel did you update from and to? Also, 4.12 is fairly old -
can you try like a live usb image of some distro with e.g. a 5.0
kernel or something?
How do you connect the external screen? Is it like a DP port with an
optional dock with a variety of active DP adapters? Or is there a DP++
I don't really see anything between v5.0..v5.1 which would account for
this. Could have been a subtle change to the i2c logic somewhere. The
fastest way to identify the problem would be to do a bisect on the kernel
to identify the commit that caused this. There are many guides for this
online.
On
On Thu, Jun 13, 2019 at 9:15 AM Ilia Mirkin wrote:
>
> On Thu, Jun 13, 2019 at 2:35 AM Daniel Drake wrote:
> >
> > From: Lukas Wunner
> >
> > The integrated HDA controller on Nvidia GPUs can be hidden with a bit in
> > the GPU's config space. Inform
This is done with a sequence of blits, from level 0 -> level 1, then
level 1 -> level 2, etc. st/mesa has a helper which will call the
gallium driver's blit method with the appropriate parameters.
Internally, assuming there's nothing too funky going on, we'll use the
2d blit logic (class 0x902d).
controller are two functions of the same PCI device
> (VGA class device on function 0 and audio device on function 1).
> The multifunction flag in the GPU's Header Type register is cleared when
> the HDA controller is hidden and set if it's exposed, so reread the flag
> after exposing
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC).
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- ctm -> csc
- mark csc.valid = false when there is no ctm property
drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++
drivers/gpu/drm/nouveau/dispnv50/base907c.
For GF119:GV100, we can enable DEGAMMA/CTM/GAMMA. For earlier GPUs, as
there is no CTM, having both degamma and gamma is a bit pointless. Later
GPUs currently lack an implementation.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 5 +
1 file changed, 5 insertions
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC).
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65 +
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 13 +
drivers/gpu/drm
Here's what I know, which may or may not be accurate, and may or may
not be complete. You've been warned.
GRAPH.SERIALIZE (0x0110)
This is a method available on all GRAPH-engine classes (at least 3d
and 2d). What this does is that it tells the GRAPH engine (not FIFO!)
to wait until all previous
101 - 200 of 1335 matches
Mail list logo
