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.
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.
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 "
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 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
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 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
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
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
[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
[..
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
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
> > > > [
This was already done in dcb.c inside nvkm, but the other parser did not
get the update.
Signed-off-by: Ilia Mirkin
---
Entirely untested. Why do we have two DCB parsers again? Also the other one
sets link_bw to a totally different set of units for link_bw...
drm/nouveau/nouveau_bios.c | 6
On Wed, Nov 1, 2017 at 12:51 PM, Karol Herbst wrote:
> fixes compilation issues with recent envytools, because movw was removed
> from fuc5, because it doesn't exist there anymore. The current code is
> most likely broken for fuc5 hardware as well and might have triggered all
> kinds of random mem
With a new kernel, mind grabbing a dmesg with drm.debug=0x1e
nouveau.debug=debug (or maybe even =trace)? Maybe also see if
fbcon/fbdev have any debug things that can be turned on?
Sounds like things are generally working, just the fbcon -> nouveaufb
path seems somehow buggered.
Another thing to t
On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
wrote:
> @@ -483,8 +483,8 @@
> nouveau :02:00.0: disp:0860: -> 0500
> nouveau :02:00.0: disp:0864:
> nouveau :02:00.0: disp:0868: -> 04000500
> -nouveau :02:00.0: disp:086c: ->
On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary wrote:
> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>
>> wrote:
>> > @@ -483,8 +483,8 @@
>> > nouveau :02:00.0: disp:0860: ->
On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary
> wrote:
>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>>
>>> wrote:
>>> > @@
On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary
> wrote:
>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>>
>>> wrote:
>>> > @@
On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote:
>> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary
>> wrote:
>>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>>>> On Fri, Nov 17, 2017 at 12
On Tue, Nov 21, 2017 at 1:07 PM, Mikko Perttunen wrote:
> Thanks to Thierry for finding this - applying
>
> index e14643615698..00eeaaffeae5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2369,7 +2369,7 @@ nv13b_chip
On Tue, Nov 21, 2017 at 8:29 PM, Andy Ritger wrote:
> Hi Martin,
Martin should have complete answers,
>
> I was asked to clarify a few things:
>
> (1) Are all the user reports of loud fans on Fermi-era GPUs?
Yes. Although I believe some GK208 users are also having trouble,
including yours truly
NVIDIA has been releasing some very partial documentation about their
display hw. You can see the latest iteration of those efforts at
http://download.nvidia.com/open-gpu-doc/Display-Class-Methods/2/ . I
don't know which, if any, NVIDIA chips support FreeSync (as opposed to
G-SYNC). Perhaps the Vol
This is parallel to the pre-SM50 change which does this. Adjusts the
shuffles / quadops to make the values correct relative to lane 0, and
then splat the results to all lanes for the final move into the target
register.
Signed-off-by: Ilia Mirkin
---
Entirely untested beyond compilation. Should
On Tue, Dec 19, 2017 at 11:41 PM, Ilia Mirkin wrote:
> This is parallel to the pre-SM50 change which does this. Adjusts the
> shuffles / quadops to make the values correct relative to lane 0, and
> then splat the results to all lanes for the final move into the target
> register.
&g
Hi Ben,
I was looking into some of the LUT-related modesetting issues. I've
noticed the following... after I load nouveau, one of my secondary
GPUs shows this on first modeset (with drm.debug=4):
[ 2368.081307] [drm:drm_helper_probe_single_connector_modes
[drm_kms_helper]] [CONNECTOR:44:DVI-I-1]
-vram systems, which can occur with some IGP-based configurations
with little "stolen" vram.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80675
Signed-off-by: Ilia Mirkin
---
There's more to be done here I think since the first modeset ends up
skipping a bunch of stuff for some
Unfortunately the ABI is a little annoying around almost requiring a
256-entry lut. While that is being worked out, allow proper mapping of
colors in 30bpp framebuffers.
Signed-off-by: Ilia Mirkin
---
If I bump the gamma size to 1024, then all existing software will start
failing since the
Not clear what the depth % 8 was trying to protect against, but it was
breaking 30bpp visuals with DRI3.
Signed-off-by: Ilia Mirkin
---
src/nouveau_dri2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index cbb7b2a..07b6022 100644
On Sun, Dec 31, 2017 at 2:23 AM, Ilia Mirkin wrote:
> Not clear what the depth % 8 was trying to protect against, but it was
> breaking 30bpp visuals with DRI3.
Erm, actually switching to my test config which doesn't enable dri3 is
what "fixed" things. DRI3 is still bust
On Tue, Dec 19, 2017 at 8:45 AM, Christian König
wrote:
> Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
>>
>> On 2017-12-19 11:37 AM, Michel Dänzer wrote:
>>>
>>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote:
On 12/18/17 7:06 PM, Mike Galbraith wrote:
>
> Greetings,
>
>
On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith wrote:
> On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote:
>> On Tue, Dec 19, 2017 at 8:45 AM, Christian König
>> wrote:
>> > Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
>> >>
>> >
Did anything change other than the kernel version? What was the
previous kernel version?
On Tue, Jan 2, 2018 at 2:43 PM, Daniel Boyd wrote:
> I am running Debian testing and updated my system this morning which
> included a new kernel: 4.14.0.2-amd64
>
> After this update, my system froze twice -
On Tue, Jan 2, 2018 at 4:26 PM, Daniel Boyd wrote:
> Previous kernel was 4.13.0-10.1-liquorix-amd64
>
> The updated kernel that I'm having trouble was not liquorix -- was
> straight from Debian.
>
> Here's my apt log:
Yeah, unfortunately I'm not sure how to read that. But when you're
flipping bet
This largely copies the code from modesetting with minor adjustments.
Signed-off-by: Ilia Mirkin
---
I've tried privately to get people to test this out, but to no avail.
I don't have the hardware to verify this one way or the other. Ideally
with this patch you should be (a) able to u
On Thu, Jan 25, 2018 at 8:47 AM, Luís Mendes wrote:
> Sorry for alI these individual emails, but I think is more readable
> this way, by having each independent information in a separate email.
>
> I also have these additional cards that I can try: Gefoce GT 1030 and
> Geforce GTX 1050 Ti.
>
> I h
On Thu, Jan 25, 2018 at 10:35 PM, Lyude Paul wrote:
> Same as the previous patch, but for Kepler2 now
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--
> drivers/gpu/drm/nouveau/nvkm/engin
Yeah, a lot of people were getting that, as a result of some drm/ttm
hugepage usage.
Christian, did a fix ever end up going out? If so, what kernel was it
included in?
-ilia
On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez
wrote:
> Hello,
>
> I've noticed firefox got randomly stuck,
On Sun, Dec 31, 2017 at 2:35 AM, Ilia Mirkin wrote:
> On Sun, Dec 31, 2017 at 2:23 AM, Ilia Mirkin wrote:
>> Not clear what the depth % 8 was trying to protect against, but it was
>> breaking 30bpp visuals with DRI3.
>
> Erm, actually switching to my test config which d
Not clear what the depth % 8 was trying to protect against, but it was
breaking 30bpp visuals with DRI3. Add it in to ensure that bitsPerPixel
% 8 is 0, since there is plenty of bpp/8 math in the driver.
Signed-off-by: Ilia Mirkin
---
src/nouveau_dri2.c | 5 -
1 file changed, 4 insertions
Ostensibly it should probably be looking at the pixmap format. However
it's always the window pixmap, so we can assume it's what we expect.
Signed-off-by: Ilia Mirkin
---
src/nouveau_xv.c | 11 +--
src/nv50_xv.c| 3 ++-
src/nvc0_xv.c| 3 ++-
3 files changed, 13
In case anyone's curious about 30bpp framebuffer support, here's the
current status:
Kernel:
Ben and I have switched the code to using a 256-based LUT for Kepler+,
and I've also written a patch to cause the addfb ioctl to use the
proper format. You can pick this up at:
https://github.com/skeggsb
On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä
wrote:
> On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
>> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
>> > In case anyone's curious about 30bpp framebuffer support, here's the
>>
The permission check fails if udev sets the render node to 0666 but
leaves the card at 0660, as is done in at least udev-236.
Signed-off-by: Ilia Mirkin
---
src/nouveau_dri2.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/src/nouveau_dri2.c b/src
On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote:
>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>
> NV5 in another PC (secondary card in x86-64) made the systrem crash on
> boot, in nvkm_therm_clkgate_fini.
Mind booting with nouveau.debug=trace? That should hopeful
On Wed, Feb 14, 2018 at 9:35 AM, Ilia Mirkin wrote:
> On Wed, Feb 14, 2018 at 9:29 AM, Meelis Roos wrote:
>>> This is 4.16-rc1+todays git on a lowly P4 with NV5, worked fine in 4.15:
>>
>> NV5 in another PC (secondary card in x86-64) made the systrem crash on
>> bo
On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> Replace the ad-hoc iturbt_709 property with the new standard
> COLOR_ENCODING property. Compiles, but not tested.
>
> Cc: Daniel Vetter
> Cc: nouveau@lists.freedesktop.org
> Cc: Ben S
On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin wrote:
> On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> wrote:
>> From: Ville Syrjälä
>>
>> Replace the ad-hoc iturbt_709 property with the new standard
>> COLOR_ENCODING property. Compiles, but not tested.
>>
NVLoadPalette is pretty hard-coded to 256. I haven't looked at what
all xf86HandleColormaps does, but it seems pretty suspicious. Also
note that the kernel currently only exposes a 256-sized LUT to
userspace, even for 10bpc modes.
On Thu, Mar 1, 2018 at 1:31 AM, Mario Kleiner
wrote:
> The various
Hello,
This question is in the context of Tesla / Fermi generations, which
have explicit bindings for textures / samplers. It might also apply to
Kepler+, not quite as sure due to the bindless nature.
I've been trying to understand how the TLD operation works (which is
used to implement texelFetc
On Fri, Mar 2, 2018 at 5:16 PM, Mario Kleiner
wrote:
> On 03/01/2018 07:21 PM, nouveau-requ...@lists.freedesktop.org wrote:
>>
>>
>> Message: 1
>> Date: Thu, 1 Mar 2018 08:15:55 -0500
>> From: Ilia Mirkin
>> To: Mario Kleiner
>> Cc: nouveau
&
On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
wrote:
> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>> OK, so even if you're passing 1024 to xf86HandleColormaps, gamma_set
>> still only gets called with a 256-entry LUT? If so, that works nicely
>> here, but is not int
On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
wrote:
> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>
>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>> wrote:
>>>
>>> On 03/02/2018 11:29 PM, Ilia Mirkin wrote:
>>>>
>>>> OK, s
On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
wrote:
> On 02/05/2018 12:50 AM, Ilia Mirkin wrote:
>>
>> In case anyone's curious about 30bpp framebuffer support, here's the
>> current status:
>>
>> Kernel:
>>
>> Ben and I have switched the
sonable state in the entry in slot #0: as I
> understand it, the one piece of sampler state that will influence TLD
> is sRGBConversion (bit 13).
>
> I hope that helps,
> - Andy
>
>
> On Thu, Mar 01, 2018 at 11:47:18PM -0500, Ilia Mirkin wrote:
>> Hello,
>>
>>
On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
wrote:
> Cc'ing mesa-dev, which was left out.
>
>
> On 03/05/2018 01:40 PM, Ilia Mirkin wrote:
>>
>> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
>> wrote:
>>> Afaics EGL does the right thing wr
On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin wrote:
> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
> wrote:
>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>>
>>> On Fri, Mar 2, 2018 at 6:46 PM, Mario Kleiner
>>> wrote:
>>>>
>>>> On
On Wed, Apr 4, 2018 at 6:58 PM, Adam Borowski wrote:
> On Wed, Apr 04, 2018 at 03:48:39PM +0300, Māris Nartišs wrote:
>> 2018-04-03 23:00 GMT+03:00, Adam Borowski :
>> > In commit da5e45e619b3f101420c38b3006a9ae4f3ad19b0
>> >
>> > yet it is still reproducible for me on 4.16-rc7 and 4.16.0, which a
A NV34 GPU was seeing temp and pwm entries in hwmon, which would error
out when read. These should not have been visible, but also the whole
hwmon object should just not have been registered in the first place.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 16
On Thu, Mar 8, 2018 at 11:29 PM, Ilia Mirkin wrote:
> On Mon, Mar 5, 2018 at 7:33 AM, Ilia Mirkin wrote:
>> On Mon, Mar 5, 2018 at 1:17 AM, Mario Kleiner
>> wrote:
>>> On 03/03/2018 12:59 AM, Ilia Mirkin wrote:
>>>>
>>>> On Fri, Mar 2, 2018 at 6:
What GPU do you have? For video acceleration (i.e. va-api and vdpau),
did you install the necessary firmware?
On Tue, May 1, 2018 at 5:53 PM, James wrote:
> I am playing videos from my lubuntu computer to my tv through the hdmi
> interface on my video card.
> It mostly works.
> Some sound doesn't
On Tue, May 1, 2018 at 6:16 PM, James wrote:
> On 2018-05-01 06:00 PM, Ilia Mirkin wrote:
>> On Tue, May 1, 2018 at 5:53 PM, James wrote:
>>> I am playing videos from my lubuntu computer to my tv through the hdmi
>>> interface on my video card.
>>> It mostly
On Sun, May 27, 2018 at 5:54 PM, Colin King wrote:
> From: Colin Ian King
>
> The constant values being shifted are 32 bit integers and may potentially
> overflow on the shift. Avoid this potential overflow by making them
> unsigned long long values before the shift.
>
> Detected by CoverityScan
Are you on mesa 18.1.0 and using a nv3x/nv4x gpu? If so, update to
18.1.1. If not, provide more information.
The error is that nouveau_dri.so can't be loaded, which means you're
not getting acceleration. You can also make the error go away by
sticking LIBGL_ALWAYS_SOFTWARE=1 into your environment
On Mon, Jun 11, 2018 at 1:32 PM, 積丹尼 Dan Jacobson wrote:
> # lspci | grep ' VGA ' | cut -d" " -f 1 | xargs -i lspci -v -s {}
> 00:05.0 VGA compatible controller: NVIDIA Corporation C51G [GeForce 6100]
> (rev a2) (prog-if 00 [VGA controller])
That's a NV4C or NV4E (i.e. nv4x).
> I.e., no 18.1.1
Where did you see instructions for doing this? Apparently this is
disabled on purpose due to spam. Or did you just assume it would work
based on other mailman lists?
On Mon, Jun 11, 2018 at 1:08 PM, Dan Jacobson wrote:
> Can't join the list confirming via email.
> Will get:
>
> gabe.freedeskt
On Tue, Jun 12, 2018 at 9:09 PM, 積丹尼 Dan Jacobson wrote:
>>>>>> "IM" == Ilia Mirkin writes:
>
> IM> OK, well 18.1.0 is completely busted for those GPU's. Either upgrade
> IM> or downgrade. But don't use that release.
>
> I did
> [DO
Lyude bisected a similar problem on a much newer GPU to this very same
change as well. [Sorry, no useful information beyond that, but thought
I'd make the connection.]
On Sun, Jun 17, 2018 at 5:46 PM, Adam Borowski wrote:
> Hi!
> On v4.18-rc1, the mouse cursor is missing on my right monitor.
> Ca
On Sun, Jun 17, 2018 at 8:50 PM, Yoann LE BARS wrote:
>
> Hello everybody out there!
>
> Well, I just subscribed to this mailing list, so I guess I should
> introduce myself, at least giving relevant information about me
> concerning the development of Nouveau.
>
> You can call me
Did you accidentally send this to the nouveau list instead of the chromium one?
On Tue, Jun 19, 2018 at 10:09 AM, 積丹尼 Dan Jacobson wrote:
> chromium prints thousands of
> [1886:1886:0619/220640.036283:ERROR:gl_surface_presentation_helper.cc(115)]
> GetVSyncParametersIfAvailable() failed!
> _
On Tue, Jun 26, 2018, 04:49 Dan Carpenter wrote:
> Hello Ben Skeggs,
>
> The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel
> interfaces to control error interrupts" from May 8, 2018, leads to
> the following static checker warning:
>
> drivers/gpu/drm/nouveau/nvkm/engine/disp/c
This removes user control to force a hdmimhz. Given the vast variety
of hardware and display configurations out there, I don't see how a
patch like this won't blow up in our faces.
I'm not saying we shouldn't do it -- we should attempt to respect the
various maximums in the vbios, but until we get
On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst wrote:
> v2: clean up left over comments
> don't overwrite hdmimhz parameter
> cap to 297MHz
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/dispnv50/disp.c | 5 +
> drm/nouveau/nouveau_connector.c | 15 ++-
> drm/nouv
GP106 is supported, you must be using an older kernel (since yours
says "unknown chipset"). Note that mobile chips, esp GP10x's, appear
to have a ton of issues with runtime pm, so YMMV.
On Sat, Aug 4, 2018 at 7:37 PM, don fisher wrote:
> I had desire for a light laptop, so purchased an Alienware
On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> +bool
> +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> +{
> + bool hotplug;
> +
> + if (!fbcon)
> + return false;
> +
> + mutex_lock(&fbcon->hotplug_lock);
> + hotplug = fbcon->hotplug_w
IPA is to interpolate an input in a fragment shader. Have a look at
OP_LINTERP / OP_PINTERP in codegen
(https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/).
Also feel free to ask specific questions in #nouveau on
irc.freenode.net.
Cheers,
-ilia
On Sat, Sep 1, 2018
When SCDC is supported, make sure that we configure the GPU and monitor
to the same parameters.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 40 -
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 +
.../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 34 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 2 ++
.../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 +
.../gpu
The register programmed by the clock method needs to contain a different
setting for the link speed as well as special divider settings.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 5
High pixel clocks are required to use a 40 TMDS divider instead of 10,
and even low ones may optionally use scrambling depending on device
support.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 -
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
d by one or the
other. But at least it works a little bit!
Note that I have limited testing equipment, but I did verify that a
GM204 trace referred to the same register for controlling
scrambling. I may get access to a GM206 later in the week to verify
there.
Ilia Mirkin (5):
drm/nouveau/disp: add
Scrambling is required for supporting any mode over 340MHz. If it's not
supported, reject any modes that would require it.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 34 +++--
1 file changed, 22 insertions(+), 12 deletions(-)
diff
DC = depth compare (extra arg with compare reference)
AOFFI = texel offset (extra arg with offsets encoded). Note that TLD4
can also have a iirc AOFFIS variant which takes 4 offsets encoded in 2
sequential regs. and iirc at 8 bits per offset, while other ops do 4
bits per offset. check what nouveau
Doesn't look like the GV100 firmware is publicly available yet.
However it won't affect you at all - you only need the GP106 firmware.
Without more info, your issue could potentially be helped by
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=85c5d90fc155d78
Swizzling is implemented by the hardware. Nouveau doesn't implement it
directly -- we just blit from a linear surface into a swizzled
surface.
Ideally you should be able to ignore swizzling entirely. However if an
application uploads pre-swizzled data, you have to deal with it. This
isn't possible
On Sun, Sep 23, 2018 at 12:26 PM, Wolfgang Rißler wrote:
> I try to send a friendly ping to my problem.
> At the moment I'm running at 1600x1200 (monitor than has 1600x1200
> too), what looks better then 1920x1200 picture on that Monitor with
> 960x1200.
> I cant get 1920x1200 working, but I'm shu
On Sun, Sep 23, 2018 at 1:48 PM, Wolfgang Rißler wrote:
> Am Sonntag, den 23.09.2018, 12:55 -0400 schrieb Ilia Mirkin:
>> On Sun, Sep 23, 2018 at 12:26 PM, Wolfgang Rißler
>> wrote:
> [snip]
>>
>> That's not extremely surprising ... force-enabling an output I
This largely copies the code from modesetting with minor adjustments.
Signed-off-by: Ilia Mirkin
---
I've tested this back and forth with a GTX 960 + 2x U2415 monitors,
chained to each other. I turned them on/off. I messed with their DP
1.1/1.2 settings. I pulled plugs a few times.
This
On Sat, Oct 13, 2018 at 5:40 PM Fernando Sahmkow wrote:
>
> So there's a register in Render Targets called Array Mode:
> https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L289
>
> We've witnessed values of 1 and 6 (array mode -> layers) but we can't tell
> their meaning.
On Fri, Oct 19, 2018 at 8:53 AM 孫偉程 wrote:
> I can imagine there is a long way to go to fulfill my requirements. But I
> know a driver for my NVIDIA card is a must for the hardware decoder to work.
> Can somebody shed some lights that if I want to play an 8K HEVC encoded video
> on Android-x86
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c#n190
On Thu, Oct 25, 2018 at 6:30 AM Fernando Sahmkow wrote:
>
> I'm currently implementing mipmaps but I have a set of troubles guessing the
> block height and block depth of them. According to
> https:/
On Wed, Nov 7, 2018 at 10:34 AM Thierry Reding wrote:
>
> On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Irrespective of whether or not the device has any usable outputs, the
On Mon, Nov 12, 2018 at 6:11 PM Fernando Sahmkow wrote:
>
> So I'm trying to track an special value in IPA instruction generation.
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp#L2561
>
> Register on 0x14 (20) is set to some source on "insn
On Fri, Nov 23, 2018 at 11:00 PM Yang Tsao wrote:
>
> Hi, guys:
> I’m a developer of FydeOS. We porting ChromiumOS to amd64 and arm platforms.
> Now, I’m woking on porting android environment to Nvidia graphic cards. I
> have experience to port android to Vmware(SVGA).
> I found two display form
On Thu, Dec 6, 2018 at 7:11 AM riveravaldez wrote:
> [ 16.573419] nouveau :00:0d.0: bus: MMIO write of 005c0001 FAULT at
> 00b000
This is not a big deal. We write to some register that doesn't exist,
but we don't use that engine anyways -- it's the media engine, I
think.
> So, what could/
On Sun, Dec 9, 2018 at 12:24 AM James wrote:
>
> https://nouveau.freedesktop.org/wiki/CodeNames/
>
> > If you're running a recent version nouveau, you can find your chipset by
> > doing dmesg | grep -i chipset. This will always be correct, whereas the
> > lists below are approximate.
>
> # dmesg
On Tue, Dec 11, 2018 at 11:16 AM riveravaldez
wrote:
>
> > Use an environment that doesn't make use of GL for basic tasks.
>
> I've been researching more and it seems that I'm already in that case.
> The freezes appears randomly, in every situation, and not when I
> launch some 3D applications or
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
b/drivers/gpu/drm/nouveau/nvkm/engine
GF117 appears to use the same register as GK104 (but still with the
general Fermi readout mechanism).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf100.c | 3 ++-
1 file changed, 2 insertions(+), 1
Ben - ping? Just ran into this myself on a NV42.
On Wed, Nov 14, 2018 at 11:01 AM Takashi Iwai wrote:
>
> On Fri, 14 Sep 2018 13:59:25 +0200,
> Martin Peres wrote:
> >
> > On 14/09/2018 10:28, Ben Skeggs wrote:
> > > On Wed, 12 Sep 2018 at 20:59, Takashi Iwai wrote:
> > >>
> > >> When a fan is c
201 - 300 of 1419 matches
Mail list logo
