On Sat, May 6, 2017 at 5:32 PM, Karl Schmidt wrote:
> So I'm guessing that nouveau computes the modelines from the combination of
> what the card and edid claim they support.
With some limitations, it will take the list of modelines in the EDID
(which, mind you, might be just VIC id's), and compa
First things first -- I've alluded to this before, but let me be clear
-- there is no global database that contains monitor-specific
information which is used by any linux drivers. Please forget any
notions you had of such a thing existing or being used.
The information comes from the EDID blob su
On May 4, 2017 6:44 PM, "Karl Schmidt" wrote:
On 05/04/2017 04:00 AM, Pierre Moreau wrote:
> Hello,
>
> Acceleration for Pascal cards is coming in Linux 4.12, support for Pascal
> cards
> in xorg-video-nouveau is in 1.0.15, and if I remember correctly, on the
> Mesa-side, you will need >=17.0.
>
On Apr 30, 2017 8:14 AM, "Karol Herbst" wrote:
2017-04-30 2:28 GMT+02:00 Ilia Mirkin :
> Maybe in a separate change. I'd want to double check on all gens. I think
> the thing I suggested is sufficient.
>
well, if I just fixup the op, I kind of have to fix the mod as well
Maybe in a separate change. I'd want to double check on all gens. I think
the thing I suggested is sufficient.
On Apr 29, 2017 8:09 PM, "Karol Herbst" wrote:
2017-04-30 0:28 GMT+02:00 Ilia Mirkin :
> On Sat, Apr 29, 2017 at 6:09 PM, Karol Herbst
wrote:
>> helps two
0
>
> v2: handle potential mods on src0
>
> Signed-off-by: Karol Herbst
> Reviewed-by: Samuel Pitoiset
> Reviewed-by: Ilia Mirkin
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --g
gests that src(0) may have modifiers, although I
can't imagine what that'd be. Perhaps it can take a neg? In that case,
you need to fix the OP_MOV above -- should probably do it anyways,
i.e. i->op = i->src(0).mod.getOp() or something. With that, this is
Reviewed-by: Ilia Mir
On Sat, Apr 29, 2017 at 10:41 AM, Karol Herbst wrote:
> fixes a crash in Alien Isolation
What crash? How did the zero get there? Does this only happen if you
do your optimization loop thing?
In either case, we still want the replaceZero() logic. However that
logic should be aware that the middle
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> This patch creates a special group attributes for attrs like "*auto_point*".
> We check if we have support for them, and if we do, we gather them all in
> an attribute_group's structure which is the parameter regarding special groups
> of hw
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> +static char *input_label = "GPU core";
This needs to be static const char input_label[] = "GPU core";
or at least static const char *const input_label = "GPU core";
-ilia
___
Nouveau mailing
All kernel patches must have a Signed-off-by: $user. See
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> This is a preparation for the next patches. It just adds th
On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater
wrote:
> Enable stereoscopic output for HDMI and DisplayPort connectors on
> NV50+ (G80+) hardware. We do not enable stereoscopy on older
> hardware in case there is some older board that still has HDMI
> output but for which we have no logic
On Mon, Apr 3, 2017 at 11:58 AM, Karol Herbst wrote:
> Signed-off-by: Karol Herbst
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> b/src/gallium/drivers/nou
On Mon, Apr 3, 2017 at 11:58 AM, Karol Herbst wrote:
> Signed-off-by: Karol Herbst
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> b/src/gal
Chris, could you have a look at this since it's allegedly your work in
the intel driver and let us know if it's reasonable? I'm definitely
not enough of an X driver guy to rule one way or the other.
On Wed, Mar 29, 2017 at 4:07 PM, Mariusz Bialonczyk wrote:
> When using Xinerama, RandR is automat
On Wed, Mar 29, 2017 at 10:24 AM, Alastair Bridgewater
wrote:
> On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä
> wrote:
>>
>> On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote:
>> > And the tenth patch enables stereo mode support... on HDMI and DPort
>> > connectors on nv50+ h
Signed-off-by: Ilia Mirkin
---
v1 -> v2: add 0x130 as a valid chip type early on in detection
src/nouveau_copy.c| 2 ++
src/nouveau_exa.c | 1 +
src/nv_accel_common.c | 1 +
src/nv_driver.c | 4
src/nv_type.h | 1 +
src/nvc0_accel.c | 6 ++
6 files chan
Signed-off-by: Ilia Mirkin
---
Untested.
src/nouveau_copy.c| 2 ++
src/nouveau_exa.c | 1 +
src/nv_accel_common.c | 1 +
src/nv_driver.c | 3 +++
src/nv_type.h | 1 +
src/nvc0_accel.c | 6 ++
6 files changed, 14 insertions(+)
diff --git a/src/nouveau_copy.c b
Signed-off-by: Ilia Mirkin
Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx
lookup")
Cc: sta...@vger.kernel.org # v4.3+
---
This is just a nice-to-have, as it only affects an error print afterwards.
drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 2 +-
d
=70388
Signed-off-by: Ilia Mirkin
Cc: sta...@vger.kernel.org
---
OK, so I'm not 100% sure about my claims, but I don't have the necessary
hardware to test it out. Right now, AGP nv41+ boards are getting the nv04
mmu, while PCI nv41+ boards are getting the PCIE one. Perhaps this work
I think you want kernel 4.10, or cherry-pick upstream commit
7dfee6827780d4228148263545af936d0cae8930.
On Sun, Mar 12, 2017 at 11:27 AM, Marcelo Ribeiro wrote:
> Hi, I am changing from proprietary nvidia drivers to Nouveau drivers in my
> mediacenter.
>
> I run a Gentoo linux in this hardware and
On Sun, Mar 5, 2017 at 11:35 AM, Karol Herbst wrote:
> We won't need it now, because we will adjust the clocks depending on engine
> loads later on anyway or a static lockup table. It also simplifies the
Presumably "lookup"?
> clocking logic.
>
> This code was nowhere used anyway and just a mock
Can you elaborate what you mean by "32MB memory space"? Do you mean
that the sum of the PCI memory regions has to be under 32MB? If so,
you may be out of luck, the VRAM BAR is always at least 64MB for GPUs
that have PCIe interfaces. See
https://envytools.readthedocs.io/en/latest/hw/bus/bars.html#b
On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
wrote:
> Hello Ilia,
>
> On 17 February 2017 at 11:14, Ilia Mirkin wrote:
>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>> wrote:
>>> I'm happy to file
>>> a bugzilla entry and provi
On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
wrote:
> I'm happy to file
> a bugzilla entry and provide any other needed information or help with
> testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
> bugzilla?
Nouveau bugs are tracked on the fdo bugzilla. It would appear t
I believe what's missing at this point is a mmiotrace of the NVIDIA
driver to make sure that there's nothing different about this GPU. If
you can make one (see https://wiki.ubuntu.com/X/MMIOTracing for a
guide - should end up ~100MB uncompressed), please send a compressed
one to mmio.du...@gmail.co
ping?
On Mon, Oct 3, 2016 at 7:22 PM, Martin Peres wrote:
> On 29/09/16 03:41, Martin Peres wrote:
>>
>> This seems to be absolutely necessary for a lot of NV40.
>>
>> Reported-by: gsgf on IRC/freenode
>> Signed-off-by: Martin Peres
>
>
> I of course forgot to tag this patch for stable. The thin
Context switching = very slow on NVIDIA. Don't do it if you can avoid
it. Each context is like a megabyte of data, if not more. Each time it
has to get saved off and restored.
On Wed, Feb 8, 2017 at 1:38 PM, Sampsa Riikonen wrote:
> Dear Devs,
>
> (I hope this question is not that much OT for thi
On Thu, Feb 2, 2017 at 5:09 PM, Phil Turmel wrote:
> On 02/02/2017 05:01 PM, Ilia Mirkin wrote:
>
>> Note that a lot of this stuff has been redone for kernel 4.10 to
>> conform to atomic modesetting. I wouldn't be surprised if that
>> jiggers things around enough t
On Thu, Feb 2, 2017 at 4:54 PM, Phil Turmel wrote:
> On 02/02/2017 04:48 PM, Ilia Mirkin wrote:
>> On Thu, Feb 2, 2017 at 4:43 PM, Phil Turmel wrote:
>>> On 02/01/2017 10:40 AM, Phil Turmel wrote:
>>>> Hi All,
>>>>
>>>> I've been runn
On Thu, Feb 2, 2017 at 4:43 PM, Phil Turmel wrote:
> On 02/01/2017 10:40 AM, Phil Turmel wrote:
>> Hi All,
>>
>> I've been running Gentoo on a ZBook with great success for a couple years,
>> but I've been stymied in my attempts to implement SecureBoot by an
>> apparent problem with efifb to nouvea
620
Cc: # v4.6+
Signed-off-by: Ilia Mirkin
---
v1 -> v2: add vga.h include (had it sitting in my local tree but forgot to
amend the commit with it)
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/n
d=97620
Cc: sta...@vger.kernel.org # v4.6+
Signed-off-by: Ilia Mirkin
---
Not sure if this is safe to do esp on GM20x+ boards?
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf1
Ben, perhaps time to apply this? It's been nearly 2 years, and no
better fix has come forward. As it is, we're hanging people's CPUs.
See https://bugs.freedesktop.org/show_bug.cgi?id=91413
On Mon, Mar 30, 2015 at 1:25 AM, 임성택 wrote:
> Hi,
>
> I used to experience kernel panics caused by CPUx hard
On Wed, Feb 10, 2016 at 9:10 PM, Alexandre Courbot wrote:
> It is not advisable to perform devinit if it has already been done.
> VBIOS will very likely have invoked devinit if the GPU is the primary
> graphics device, but there is no accurate way to detect this fact yet.
>
> This patch adds such
...@vger.kernel.org
Signed-off-by: Ilia Mirkin
---
According to several users this improves the flickering situation
substantially, but does not fix the problems entirely. I'm guessing
there's more, but this is pretty easy to compare with the old logic.
drm/nouveau/dispnv04/hw.c | 3 +
On Thu, Jan 19, 2017 at 11:40 AM, Shailesh Tripathi <
shailesh.tripathi.ec...@itbhu.ac.in> wrote:
> Hello,
> Even I think it would be a very big project for just 3 months, but it
> would be fun learning and developing this. I feel I have the required
> skills and would like to learn more for this.
On Wed, Jan 18, 2017 at 11:57 AM, Ilia Mirkin wrote:
> On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau
> wrote:
>> On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote:
>>> On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote:
>>> > Damien -
On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau
wrote:
> On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote:
>> On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote:
>> > Damien - did you ever test these mandatory modes on an actual
>> > commerc
On Wed, Jan 18, 2017 at 6:45 AM, Damien Lespiau
wrote:
> On Wed, Jan 18, 2017 at 12:10:56AM -0500, Ilia Mirkin wrote:
>> On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater
>> wrote:
>> > HDMI specification 1.4a, table 8-15 is very explicitly a "must
>> >
On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater
wrote:
> HDMI specification 1.4a, table 8-15 is very explicitly a "must
> support at least one of" table, not a "must support all of" table.
> It is not hard to find hardware that does not support some of the
> so-called "mandatory" modes.
>
>
On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater
wrote:
> Now that we have mechanism by which to pass mode-dependent HDMI
> InfoFrames to the low-level hardware driver, it is incumbent upon
> us to do so.
>
> Experimentation on a gt215 device suggests that the Audio InfoFrame
> is not require
On Tue, Jan 17, 2017 at 5:41 PM, Alastair Bridgewater
wrote:
> The nouveau driver, in the Linux 3.7 days, used to try and set the
> AVI InfoFrame based on the selected display mode. These days, it
> uses a fixed set of InfoFrames. Start to correct that, by
> providing a mechanism whereby InfoFra
There's not a lot of information about it. Basically we need 2 instruction
scheduling passes -- one pre-RA and one post-RA. The prerequisites are
"know how compilers work" and "have a GPU that you can test performance on".
I won't beat around the bush - this is a very tough project. Every attempt
On Fri, Jan 13, 2017 at 10:11 AM, Sylvain Fabre wrote:
> xrandr --setprovideroutputsource 1 0 seems to do nothing, either with a
> monitor connected to HDMI-1 or not. The second monitor is detected and
> available in the screen configuration tool of KDE, but it remains black, no
> window, nothing.
On Thu, Jan 12, 2017 at 3:51 AM, Sylvain Fabre wrote:
> xrand
>
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y
> axis) 344mm x 194mm
> 1920x1080 60.02*+ 47.99
> 1400x1050 59.98
> 12
audit and version SOR_HDA_ELD method")
Cc: sta...@vger.kernel.org # v3.17+
Reviewed-by: Ilia Mirkin
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hd
On Wed, Jan 11, 2017 at 4:48 AM, Sylvain Fabre wrote:
> Hi all,
>
>
>
> On my recent MSI Apache Pro laptop with Intel Skylake + GP106M Nvidia chip,
> i am unable to use the external HDMI and DP outputs. The outputs are
> available thru xrandr and can be activated, but the connected monitors
> alwa
Ben - ping on this - should definitely be pushed for 4.10. People keep
running into it and sending variously broken patches attempting to fix
it.
On Tue, Dec 6, 2016 at 11:30 PM, Martin Peres wrote:
> The proper fix would have been to select LEDS_CLASS but this can lead
> to a circular dependency
The issue was recorded in fd.o bug 27501, not 25701.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb
This xrandr output only represents outputs on your Intel iGPU, not
your NVIDIA G98 dGPU. You may find reading
http://nouveau.freedesktop.org/wiki/Optimus instructional.
Cheers,
-ilia
On Thu, Dec 29, 2016 at 8:48 PM, Terra Frost wrote:
> I have an ASUS UX50V laptop with a "NVIDIA Corporation:
On Thu, Dec 29, 2016 at 10:28 AM, Terra Frost wrote:
> I have a GeForce G 105M. That's, I guess, an NV50 family video card:
>
> https://nouveau.freedesktop.org/wiki/CodeNames/#NV50
>
> My question is... does Nouveau support HDMI with this video card?
>
> According to https://nouveau.freedesktop.o
"fail ttm_validate" basically means "you ran out of vram".
Unfortunately the GL driver doesn't handle this gracefully, causing
commands to get submitted which eventually hang the GPU. You can
disable hw accel in chrome which should ideally "fix" this for you.
Cheers,
-ilia
On Fri, Dec 9, 2016
On Fri, Dec 16, 2016 at 4:09 PM, Joseph D. Wagner
wrote:
> On 2016-12-16 12:52, Ilia Mirkin wrote:
>
>> On Fri, Dec 16, 2016 at 12:10 PM, Joseph D. Wagner
>> wrote:
>>
>>> When using the nouveau driver, my screen freezes (and stays frozen) when
>>> it
&
On Fri, Dec 16, 2016 at 12:10 PM, Joseph D. Wagner
wrote:
> When using the nouveau driver, my screen freezes (and stays frozen) when it
> starts to more than a minimum amount of work. To fix this, I've been using
> the nvidia driver with the Preferred Mode set to Prefer Maximum Performance.
>
> I
If ret == 0, then node should not be null. Either that no longer holds, or
your static checker is no longer able to deduce that.
On Dec 12, 2016 7:07 AM, "Dan Carpenter" wrote:
> [ No idea why it's only complaining about this a year later... -dan ]
>
> Hello Ben Skeggs,
>
> This is a semi-automa
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot wrote:
> On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote:
>> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
>>>> That's right -- nouveau currently r
That's right -- nouveau currently requires 4k page sizes to work. This is a
software limitation, not a hardware one though.
On Dec 1, 2016 5:13 PM, "Jeremy Linton" wrote:
Hi,
I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau
driver failed to claim the device with :
[drm] In
On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote:
> The newly introduced LED handling for nouveau fails to link when the
> driver is built-in but the LED subsystem is a loadable module:
>
> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend':
> tvnv17.c:(.text.nouveau_do_suspend
On Wed, Nov 2, 2016 at 12:54 AM, Alexandre Courbot wrote:
> Look for firmware files using the legacy ("nouveau/nvxx_fuc") path
> if they cannot be found in the new, "official" path. User setups were
> broken by the switch, which is bad.
>
> There are only 4 firmware files we may want to look u
On Mon, Oct 31, 2016 at 2:31 AM, Alexandre Courbot wrote:
> On Mon, Oct 31, 2016 at 1:34 AM, Ilia Mirkin wrote:
>> Hi Alex,
>>
>> As you're well-aware, your commit
>> 8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouveau/gr: use
>> NVIDIA-provided exte
Hi Alex,
As you're well-aware, your commit
8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouveau/gr: use
NVIDIA-provided external firmwares) broke tons of existing setups for
people who were using extracted firmware files (stored in the
"nouveau" firmware directory) as a result of nouveau's ctxsw
You can force a power state (depending on the GPU) on boot with
nouveau.config=NvClkMode=... Not sure exactly what those PowerMizer
settings do.
On Fri, Oct 28, 2016 at 3:37 PM, Joseph D. Wagner
wrote:
> The only way I can get my nvidia card to work is by using the nvidia driver
> with these sett
On Thu, Oct 27, 2016 at 1:19 PM, Samuel Pitoiset
wrote:
> Are you sure this refactoring doesn't break anything?
>
> Few comments inline.
>
>
> On 10/27/2016 04:02 PM, Ilia Mirkin wrote:
>>
>> This flips GM10x to using the updated format, which is what I test
Yep. It's in the nouveau codebase, check ce/gp100.c.
On Thu, Oct 27, 2016 at 1:10 PM, Samuel Pitoiset
wrote:
> 0xc0b5 is not in rnndb, I guess it should be GP100_COPY, right?
>
> Reviewed-by: Samuel Pitoiset
>
>
> On 10/27/2016 04:02 PM, Ilia Mirkin wrote:
>>
Signed-off-by: Ilia Mirkin
---
src/nouveau_copy.c | 2 ++
src/nvc0_accel.c | 10 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/nouveau_copy.c b/src/nouveau_copy.c
index c139de6..7118a7a 100644
--- a/src/nouveau_copy.c
+++ b/src/nouveau_copy.c
@@ -42,6 +42,8
This flips GM10x to using the updated format, which is what I tested
with. However GM20x and GP10x also use this TIC format.
Signed-off-by: Ilia Mirkin
---
src/nvc0_accel.c | 11 ++
src/nvc0_accel.h | 56 ++
src/nvc0_exa.c | 23
;t want to
claim support for it.
Ilia Mirkin (7):
exa: add GM10x acceleration support
hwdefs: update nvc0_3d, add gm107_texture for new TIC format
nvc0: make use of the new hwdefs for TEX_CB_INDEX
nvc0: rename BEGIN_IMC0 to IMMED_NVC0
nvc0: refactor TIC uploads to allow different spe
Signed-off-by: Ilia Mirkin
Reviewed-by: Samuel Pitoiset
---
src/nvc0_accel.c | 2 +-
src/nvc0_accel.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c
index 52a17db..0682806 100644
--- a/src/nvc0_accel.c
+++ b/src/nvc0_accel.c
@@ -313,7
These are copied directly from the mesa repository.
Signed-off-by: Ilia Mirkin
Acked-by: Samuel Pitoiset
---
src/Makefile.am| 1 +
src/hwdefs/gm107_texture.xml.h | 365 +
src/hwdefs/nvc0_3d.xml.h | 867 +
3 files
x27;t want to
rock the boat.
Signed-off-by: Ilia Mirkin
---
src/Makefile.am | 16
src/nouveau_copy.c| 1 +
src/nouveau_exa.c | 2 +-
src/nouveau_xv.c | 2 +-
src/nv_accel_common.c | 1 +
src/nv_driver.c | 1 +
src/nvc0_ac
For consistency with mesa. It wasn't used anywhere previously.
Signed-off-by: Ilia Mirkin
Reviewed-by: Samuel Pitoiset
---
src/nouveau_local.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nouveau_local.h b/src/nouveau_local.h
index 3de69a2..dd49395 100644
---
Signed-off-by: Ilia Mirkin
---
src/nv_driver.c | 2 ++
src/nvc0_accel.c | 10 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/nv_driver.c b/src/nv_driver.c
index fff83f8..61940a8 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -390,6 +390,7 @@ NVHasKMS
On Mon, Oct 17, 2016 at 5:28 AM, Samuel Pitoiset
wrote:
> Looks reasonable, some minor comments below.
>
>
> On 10/16/2016 02:06 AM, Ilia Mirkin wrote:
>> diff --git a/src/nvc0_exa.c b/src/nvc0_exa.c
>> index 6add60b..a53dfe6 100644
>> --- a/src/nvc0_exa.c
>>
On Mon, Oct 17, 2016 at 5:46 AM, Samuel Pitoiset
wrote:
> Few comments below.
>
> On 10/16/2016 09:14 PM, Ilia Mirkin wrote:
>>
>> This flips GM10x to using the updated format, which is what I tested
>> with. However GM20x and GP10x also use this TIC format.
>&
On Sun, Oct 16, 2016 at 11:39 PM, C Bergström wrote:
> Is there any particular reason you're not using the open source NVIDIA
> Tegra drivers?
>
> This is what is being used for the TX1 (Sorry I don't know if it's the
> same for the TK1)
> http://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=summ
For consistency with mesa. It wasn't used anywhere previously.
Signed-off-by: Ilia Mirkin
---
src/nouveau_local.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nouveau_local.h b/src/nouveau_local.h
index 3de69a2..dd49395 100644
--- a/src/nouveau_local.h
+++
Signed-off-by: Ilia Mirkin
---
Untested. I don't have the hardware.
src/nv_driver.c | 2 ++
src/nvc0_accel.c | 10 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/nv_driver.c b/src/nv_driver.c
index fff83f8..61940a8 100644
--- a/src/nv_driver.c
+++
This flips GM10x to using the updated format, which is what I tested
with. However GM20x and GP10x also use this TIC format.
Signed-off-by: Ilia Mirkin
---
src/nvc0_accel.c | 11 ++
src/nvc0_accel.h | 56 ++
src/nvc0_exa.c | 22
Signed-off-by: Ilia Mirkin
---
src/nvc0_accel.c | 2 +-
src/nvc0_accel.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/nvc0_accel.c b/src/nvc0_accel.c
index 52a17db..0682806 100644
--- a/src/nvc0_accel.c
+++ b/src/nvc0_accel.c
@@ -313,7 +313,7 @@ NVAccelInit3D_NVC0
These are copied directly from the mesa repository.
Signed-off-by: Ilia Mirkin
---
src/hwdefs/gm107_texture.xml.h | 365 +
src/hwdefs/nvc0_3d.xml.h | 867 +
2 files changed, 892 insertions(+), 340 deletions(-)
create mode 100644 src
x27;t want to
rock the boat.
Signed-off-by: Ilia Mirkin
---
Note: this won't work for GM20x - we need to allow TIC format to be updated
for that to work. But this is a step in that direction.
src/Makefile.am | 16
src/nouveau_copy.c| 1 +
src/nouveau_exa.c
---
rnndb/display/nv3_pramdac.xml | 67 +++
1 file changed, 67 insertions(+)
diff --git a/rnndb/display/nv3_pramdac.xml b/rnndb/display/nv3_pramdac.xml
index 13b6a7b..e236921 100644
--- a/rnndb/display/nv3_pramdac.xml
+++ b/rnndb/display/nv3_pramdac.xml
@@
On Sun, Oct 2, 2016 at 2:43 PM, Tobias Klausmann
wrote:
>
>
> On 02.10.2016 20:26, Ilia Mirkin wrote:
>>
>> That's very odd. LoadPropagation should have picked that up even in
>> its current form. Should try to figure out why it didn't and that is
>&
That's very odd. LoadPropagation should have picked that up even in
its current form. Should try to figure out why it didn't and that is
likely to "fix" a *lot* more situations.
On Sun, Oct 2, 2016 at 2:24 PM, Tobias Klausmann
wrote:
>
>
> On 02.10.2016 20:03, Il
On Sun, Oct 2, 2016 at 1:58 PM, Tobias Klausmann
wrote:
> Previously we'd end up with an unnecessary mov for the thirs immediate value.
>
> total instructions in shared programs : 851881 -> 851864 (-0.00%)
> total gprs used in shared programs: 110295 -> 110295 (0.00%)
> total local used in sha
On Fri, Sep 30, 2016 at 5:50 PM, Tobias Klausmann
wrote:
> Split the source immediate value into two new values and create OP_MOV
> instructions the two newly created values.
>
> V2: get rid of special cases
>
> Signed-off-by: Tobias Klausmann
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_
On Fri, Sep 30, 2016 at 3:21 PM, Tobias Klausmann
wrote:
>
>
> On 28.09.2016 02:01, Ilia Mirkin wrote:
>>
>> On Tue, Sep 27, 2016 at 7:25 PM, Tobias Klausmann
>> wrote:
>>>
>>> Split the source immediate value into two new values and create OP_MOV
A ton of stuff that used to be in the regular info output has gotten
removed in v4.3, this among them. Not sure if there was any rhyme or
reason to it. I'm definitely in favor of re-adding stuff, at the very
least at the debug level.
On Thu, Sep 29, 2016 at 12:57 PM, Dan Moulding wrote:
> Any com
On Fri, Sep 9, 2016 at 10:34 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> Cc: sta...@vger.kernel.org
Ian mentioned that he tested this out on IRC:
#dri-devel: imirkin: Your patch to the nouveau kernel module
fixes the oops that I encountered. Consider that a Tested-by.
So y
On Tue, Sep 27, 2016 at 7:25 PM, Tobias Klausmann
wrote:
> Split the source immediate value into two new values and create OP_MOV
> instructions the two newly created values.
>
> Signed-off-by: Tobias Klausmann
> ---
> .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 23
> ++
I think you want the reduced blanking modeline:
$ cvt -r 2560 1440
# 2560x1440 59.95 Hz (CVT 3.69M9-R) hsync: 88.79 kHz; pclk: 241.50 MHz
Modeline "2560x1440R" 241.50 2560 2608 2640 2720 1440 1443 1448
1481 +hsync -vsync
This matches your monitor's detailed timings:
[55.220] (II) NOUVEAU(
In addition to that bugfix, as Xorg 1.19 is being released we also
need to release something with the new ABI support. I will be
attempting to push a release in the next day or two unless someone
beats me to it (or objects). I've never done a release before, so
someone else beating me to it is defi
On Sun, Sep 18, 2016 at 11:39 PM, Alexandre Courbot wrote:
> On Sun, Sep 18, 2016 at 7:21 PM, Karol Herbst wrote:
>> This reverts commit 01bbcb69f80e1058395b737ae399c6f4ef48691b.
I think you meant aff51175cdbf345740ec9203eff88e772af88059 - that's
the commit id that matters, not the one in Ben's
Every other *_drm.h does #include "drm.h". Something else is wrong.
On Sun, Sep 18, 2016 at 6:21 AM, Karol Herbst wrote:
> Cought while working on travis-ci integration
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/uapi/drm/nouveau_drm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
Unfortunately there's no sure-fire way to distinguish a sched "op" from
regular ones. They happen purely based on position. So for disassembly,
use the byte position in the file to determine whether the current op
should be decoded as sched or as regular.
For assembly, we go back to using a shared
Signed-off-by: Ilia Mirkin
Cc: sta...@vger.kernel.org
---
Ian Romanick reported a kernel crash that implicated this path in a null
pointer jump, which means that one of the function pointers had been nulled
out. Not sure if a race there would explain it, but maybe.
There is also questionable
Tested on a NV34. There are reports of this also working on the other
nv3x chips. Largely useful for testing software written for NV2x without
having the actual hardware available.
Signed-off-by: Ilia Mirkin
---
Not sure whether nv30/nv35 have 0x0097 or 0x0597. Even though their respective
On Thu, Jul 28, 2016 at 1:32 PM, Zachary Wolfe wrote:
> I have read several bugs with similar issues on BugZilla concerning 4.6.4
> and GTX 970's.
>
> I managed a work around by booting to previous kernel release but nouveau
> wont work with this card. I run two GPUs, so I moved my 760 to primary
On Wed, Jul 27, 2016 at 7:16 PM, Ilia Mirkin wrote:
> This should fix some unaligned access warnings. This is also likely to
> fix non-descript issues on nv30/nv34 as a result of incorrect channel
> setup.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836
> S
401 - 500 of 1419 matches
Mail list logo
