All the present logic relies on EXA being used to wrap everything.
Unclear if present could even be used without the other things EXA
enables, but better be safe.
Signed-off-by: Ilia Mirkin
---
src/nv_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nv_driver.c b
This got broken with commit 86024cee back in 2014!
drmmode_pixmap/nouveau_pixmap expect there to be EXA wrapping around the
pixmap now, which is not there without accel.
Signed-off-by: Ilia Mirkin
---
src/drmmode_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src
nels. While the code is a
> mess right now, here is a link to the program:
> https://github.com/EchelonX-Ray/ttygraphics . I'm just trying to learn
> about this and you really helped.
> On 7/5/20 7:17 PM, Ilia Mirkin wrote:
>
> Check fb_pan_display in drivers/video/fbdev/core/
ig so I doubt the cmdline
> would make a difference.
>
> I really appreciate the help. I've been looking header files and a such
> trying to cobble together some information to figure this out. I hate
> to bother you with this because it seems slightly off topic.
>
&
, though, because I just tried it again on a
> dell laptop with Intel HD Graphics 4400 to the same failure.
>
> On Jul 5, 2020 12:35, Ilia Mirkin wrote:
>
> Are you setting the overallocation to 200?
>
> On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos
> wrote:
> >
> &
Are you setting the overallocation to 200?
On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos
wrote:
>
> Does NOUVEAU support mmaping a double-sized Framebuffer?
> When attempting to run, where fd refers to "/dev/fb0":
>
> mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
>
> I g
You probably have drm.debug set to something.
On Tue, Jun 23, 2020 at 4:42 AM Mathieu Malaterre wrote:
>
> Hi there,
>
> I am gettings tons of messages in dmesg output such as:
>
> [...]
> [ 2419.238990] [drm:drm_mode_addfb2 [drm]] [FB:65]
> [ 2419.243388] 00a0 2 base507c_ntfy_set
> [ 2419.243391
environment.
Cheers,
-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
reen tearing for both 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 lo
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 P
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 1
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 e
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
> lo
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 fine
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
> +++ b/drivers/gpu/drm/nouveau/nouveau_connec
board.
On Fri, 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. There'
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
[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 with
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, anythin
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...
>
> 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 OK.
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
> > us
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
>
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,
other log, per Lyude on #nouveau.
> >
> > 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 Mirk
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 automati
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 sometimes
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 whe
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
7df4e9c110f38cb3f3d709195d
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 9340d77f5327ea673a7f95f58139123d7a
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 this.
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&id=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 would
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), includi
;t have the issue
> 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
&
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
genera
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
> ---
> drive
ust have 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:
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,
> b
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
95d" 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
recommend 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
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 encountered
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
> valid
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
image_load_store.non-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,
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
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 t
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 driver->io_mem_reserv
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 ---
> drivers/gpu/drm/nouveau/dispnv50
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 hook
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:
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
> inde
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 bad
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
> >
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 regardl
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 wit
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 nouveau.hdmimhz=340
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 inform
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 I'v
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 Mem
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 pow
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
https://cgit.freedesktop.org/mesa/mesa/tree/src/gall
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 suit
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 th
>
>
> 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 nv50 GPU,
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 nv50 GPU, or some other model? I can try to take a
> closer look at this
>
> On Sun, 2019-06-16 at 10:28 -0400, Ilia Mirkin wrote:
>
> I don
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+ change
9.88Hz
>
> 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
>
>
> Gesen
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: runli
r are not part of the
> problem.
>
> 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 H
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++
port
101 - 200 of 1419 matches
Mail list logo
