Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_program.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c
b/src/gallium
Some of the hardware support is missing. The NVIDIA-provided driver,
which claims 3.3 support fails a slew of the relevant tests as well.
This allows us to expose geometry shaders without doing the additional
work involved in supporting ARB_geometry_shader4.
Signed-off-by: Ilia Mirkin
---
src
Make sure that we never try to use a 0-sized map. This can happen when
using a gp, so add a dummy mapping when computing vp_gp_mapping in that
case.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_shader_state.c | 4
1 file changed, 4 insertions(+)
diff --git a/src
e-case for accessing e.g. a[$r1], however
that's not supported for now. (Could be added by checking the register
file of the indirect parameter.)
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 6 +++---
src/gallium/drivers/nouveau/codegen/nv50_i
---
src/gallium/drivers/nouveau/nv50/nv50_program.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.h
b/src/gallium/drivers/nouveau/nv50/nv50_program.h
index 13b9516..f63352f 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_progr
Set max_out to 1 when there are no outputs.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_program.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c
b/src/gallium/drivers/nouveau/nv50/nv50_program.c
index f46f240
ample piglits pass, so turn
on PIPE_CAP_TEXTURE_MULTISAMPLE.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 8 +++
.../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 1 +
.../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 60 +
src/ga
Fixes most of the tests/spec/gl-3.2/layered-rendering/* piglits.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
b/src
Signed-off-by: Ilia Mirkin
---
There are still some things that fail -- mostly gl_Layer stuff, and also using
gl_PositionID without a gp.
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50
This code was missing a break which made it ineffective. But since
shader input loads have been disallowed, define the code out.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers
.
Signed-off-by: Bryan Cain
[calim: various updates to the indirect address logic]
Signed-off-by: Christoph Bumiller
[imirkin: remove OP_MAD change that calim made, add OP_RESTART handling
same as OP_EMIT for code flow analysis]
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_context.c | 46 +
1 file changed, 46 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_context.c
b/src/gallium/drivers/nouveau/nv50/nv50_context.c
index 11afc48..db3bd3a 100644
--- a/src
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_program.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c
b/src/gallium/drivers/nouveau/nv50/nv50_program.c
index 78a12e3..f46f240 100644
--- a/src/gallium/drivers/nouveau
---
src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp
index ade9be0..52257a8 100644
--- a/src/g
Each code BO is a heap that allocates at the end first, and so GPs are
allocated at the very end of the allocated space. When executing, we see
PAGE_NOT_PRESENT errors for the next page. Just over-allocate to make
sure that there's something there.
Signed-off-by: Ilia Mirkin
---
src/ga
For some reason, shader input accesses don't work correctly in non-ld
instructions. Disallow those loads from being propagated.
Signed-off-by: Ilia Mirkin
---
I'm not particularly happy with this patch. Some investigation needs to happen
as to what's going on here. NVIDIA'
From: Bryan Cain
Layer output probably doesn't work yet, but other than that everything seems
to be working.
Signed-off-by: Bryan Cain
[calim: fix up minor bugs, code formatting]
Signed-off-by: Christoph Bumiller
Signed-off-by: Ilia Mirkin
---
.../drivers/nouveau/codegen/nv50_ir_emit
Updates a few inconsistencies as well, like the size of the buffer,
location of the runout, etc.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_context.h| 10 ++
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 8
src/gallium/drivers
nv50/ir: fix PFETCH and add RDSV to get VSTRIDE for GPs
Ilia Mirkin (16):
nv50: allow vert_count to be >255
nv50/ir: disallow predicates on emit/restart ops
nv50/ir: disallow shader input propagation for gp
nv50/ir: comment out code to allow input/immed loads
nv50/ir: ad
From: Christoph Bumiller
---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 62 --
.../drivers/nouveau/codegen/nv50_ir_print.cpp | 1 +
3 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/src/g
On Mon, Jan 13, 2014 at 12:51 PM, Grant wrote:
Launching firefox is causing a system crash with a black or white
screen and diagonal lines across it. I've tried the latest nouveau
from git and the latest kernel. I can't find anything in the logs
unfortunately. Any ideas?
>>>
of
EXT_framebuffer_multisample piglit tests.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_state.c | 2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state.c
b/src/gallium/drivers/nouveau/n
On Fri, Jan 10, 2014 at 2:32 PM, Javier Domingo Cansino
wrote:
> Hi!
>
> I have just installed Debian in a GTX 650 computer, and found it's not
> working. The problem is that I have no idea which is the minimum kernel
> version required to complete the task.
>
> Wouldn't it be possible that in the
Fixes assertions when trying to attach textures to fbs with formats not
supported by the render engines.
See https://bugs.freedesktop.org/show_bug.cgi?id=73459
Signed-off-by: Ilia Mirkin
---
In a perfect world I'd have separate callbacks for depth and color, but given
the list of supp
On Thu, Jan 9, 2014 at 4:04 AM, Ilia Mirkin wrote:
> Hi Marek,
>
> I won't pretend to understand what's going on, but I just bisected a
> failure on tests/shaders/glsl-fs-lots-of-tex.shader_test in piglit
> between 9.1 and HEAD, and it landed on your commit. It'
This replaces the custom disable checks throughout the implementations.
As a side-effect this will honor hw disables on video decoding engines
as well as PDISP on nvc0:nvd0.
Signed-off-by: Ilia Mirkin
---
Not strictly needed, but I think it's nice to unify it all. (And it also
handles the
Signed-off-by: Ilia Mirkin
---
I decided to let the user still specify config=BLA=1 to override the hw
disable in case we get something wrong or for double-checking stuff, but I
suspect it won't really be used much. I'm not terribly fond of the message
text, if you come up with someth
This will turn off PDISPLAY/PCRYPT/PCOPY0/video engines on cards where
they are marked as disabled either by the hardware of VBIOS.
See https://bugs.freedesktop.org/show_bug.cgi?id=58378
Signed-off-by: Ilia Mirkin
---
An earlier version of this patch was tested. I added the DISP disable since
On Thu, Jan 9, 2014 at 7:14 PM, Grant wrote:
> Launching firefox is causing a system crash with a black or white
> screen and diagonal lines across it. I've tried the latest nouveau
> from git and the latest kernel. I can't find anything in the logs
> unfortunately. Any ideas?
>
> 00:0d.0 VGA c
So I figured out what was going on. The shader has a
UMAD TEMP[0].x, TEMP[0]., -TEMP[5]., TEMP[0].
instruction, in which the -TEMP[5]. got emitted as
cvt neg u32 $r1 u32 $r1
If instead I fudge mkOp() to force a s32 dtype on OP_NEG, everything
starts to work. Similarly, if I fudg
On Mon, Jan 6, 2014 at 7:53 AM, fbs 777 wrote:
> For many years im using the ubuntu with nouveau and the yuy2 scalemode in
> mame. I think the last one was 11.10 or 12.04, not sure.
> Now in the ubuntu 13.10 the yuy2 scalemode dont work in mame, but works fine
> with the intel driver.
>
> Tested w
On Wed, Jan 1, 2014 at 9:36 PM, Sid Boyce wrote:
> On 01/01/14 18:46, Ilia Mirkin wrote:
>>
>> On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce wrote:
>>>
>>> On 01/01/14 00:55, Ilia Mirkin wrote:
>>>>
>>>> On Tue, Dec 31, 2013 at 7:41 PM, S
On Wed, Jan 1, 2014 at 3:29 PM, Michele Baldessari wrote:
> On Wed, Dec 11, 2013 at 07:21:05AM -0500, Ilia Mirkin wrote:
>> >> On Thu, 5 Dec 2013 10:55:06 -0500 Ilia Mirkin wrote:
>> >> > On Thu, Dec 5, 2013 at 10:17 AM, Bruno Prémont wrote:
>> >> >
On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce wrote:
> On 01/01/14 00:55, Ilia Mirkin wrote:
>>
>> On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce
>> wrote:
>>>
>>> On 31/12/13 10:36, Ilia Mirkin wrote:
>>>> Having a dmesg would be nice. One thing I
On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce wrote:
> On 31/12/13 10:36, Ilia Mirkin wrote:
>>
>> On Tue, Dec 31, 2013 at 5:14 AM, Sid Boyce
>> wrote:
>>>
>>> System x86_64 with openSUSE 13.1.
>>> X.Org version: 1.14.99.905
>>>
>>&g
On Tue, Dec 31, 2013 at 5:14 AM, Sid Boyce wrote:
> System x86_64 with openSUSE 13.1.
> X.Org version: 1.14.99.905
>
> openSUSE 12.2 kernels boot successfully into a graphical screen, login to
> KDE4, etc. all normal.
>
> 3.13-rc kernels boot fully with X running but no graphical screen and it
> f
t;
> Anyway, as far as I am concerned, the issue is closed. I use vdpau with the
> firmware files and I am happy.
>
> Matthias
>
> Am Donnerstag, 12. Dezember 2013, 07:18:48 schrieb Ilia Mirkin:
>> On Thu, Dec 12, 2013 at 2:32 AM, Matthias Nagel
>>
>> wrote:
&
On Sat, Dec 14, 2013 at 9:20 AM, ael wrote:
> I have a crash on the current stable kernel.
>
> Here is the trace from dmesg:-
> --
>
> CPU: 0 PID: 682 Comm: modprobe Not tainted 3.13.0-rc3_exact-293199-g374b105
> #379
> Hardware name:
On Thu, Dec 12, 2013 at 2:32 AM, Matthias Nagel
wrote:
> Hello,
>
> I run the Gentoo Linux distribution and use a self-compiled Linux 3.10.17
> kernel. According to
>
> [1] http://nouveau.freedesktop.org/wiki/InstallDRM/
> [2] http://nouveau.freedesktop.org/wiki/VideoAcceleration/
>
> I need the o
The intent was to only enable it by default for optimus, e.g. see the
runtime_idle callback. The suspend callback may be called directly, e.g.
as a result of nouveau_crtc_set_config.
Reported-by: Stefan Lippers-Hollmann
Signed-off-by: Ilia Mirkin
Cc: sta...@vger.kernel.org
---
See http
On Wed, Dec 11, 2013 at 6:43 AM, Bruno Prémont
wrote:
> Hi Ilia,
>
>> On Thu, 5 Dec 2013 10:55:06 -0500 Ilia Mirkin wrote:
>> > On Thu, Dec 5, 2013 at 10:17 AM, Bruno Prémont wrote:
>> > > With drm-nouveau-next branch on top of 3.13-rc2 and a few sound commits
Fixes the texelFetch piglit tests.
Signed-off-by: Ilia Mirkin
---
Verified a few things, but it's hard to check this fully. They array-texture
piglit test fails if the conversion isn't done at all, and texelFetch starts
passing if the conversion is removed.
Dunno if this is the sor
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c | 28 ++
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c
b/src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c
index a0f5332
Create the ref_bo without any storage type flags set for now. The issue
probably arises from our use of the additional buffer space at the end
of the ref_bo. It should probably be split up in the future.
Signed-off-by: Ilia Mirkin
Tested-by: Martin Peres
Cc: "10.0"
---
src/galli
Based on comments by Benjamin Morris in
http://lists.freedesktop.org/archives/nouveau/2013-December/015328.html
This adds setting of is_long_term, and updates a few field names we were
unclear about.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c | 33
On Fri, Dec 6, 2013 at 11:43 PM, Ilia Mirkin wrote:
> Create the ref_bo without any storage type flags set for now. This can
> probably be split up somehow later on, but this seems to work.
>
> Signed-off-by: Ilia Mirkin
> Cc: "10.0"
> ---
>
> Would be great
Some firmware images may be large (64K), so using kmalloc memory is
inappropriate for them. Use vmalloc instead, to avoid high-order
allocation failures.
Signed-off-by: Ilia Mirkin
Cc: sta...@vger.kernel.org
---
Couldn't get video decoding started on a long-running system due to high-
re-nvc0 problems
> are
> * resolved. */
Update this comment to reflect reality. Or just remove it.
With that change,
Reviewed-by: Ilia Mirkin
Or I can fold this into my h264 change if you don't want to send a v2,
up to you.
>return profile >= P
Create the ref_bo without any storage type flags set for now. This can
probably be split up somehow later on, but this seems to work.
Signed-off-by: Ilia Mirkin
Cc: "10.0"
---
Would be great if someone could see if this also makes MPEG4 work on NVA3+. In
order to do that, rem
video decoding engines).
Apologies for this being such a "trivial" issue, and I had totally
forgotten about the storage type. When I was working with VP2 setting
it incorrectly just meant misrendered images, not engine hangs.
Cheers,
-ilia
On Fri, Dec 6, 2013 at 8:06 PM, Ilia Mirkin
On Fri, Dec 6, 2013 at 7:36 PM, Benjamin Morris wrote:
> I've gathered a few hints regarding H264 video decoding on our hardware.
> Hopefully some of them will be useful.
Very useful!
>
> First off, regarding naming in general. Our internal names for our video
> engines differ from the names
On Fri, Dec 6, 2013 at 8:30 AM, Thomas Glanzmann wrote:
> Hello Ilia,
>
>> > [7.569394] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac080b1
>> > [7.569460] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A
>> > (NVAC)
>> > [7.569530] nouveau [ DEVICE][:02:00.0] Family : N
On Fri, Dec 6, 2013 at 2:44 AM, Thomas Glanzmann wrote:
> [7.569394] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac080b1
> [7.569460] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC)
> [7.569530] nouveau [ DEVICE][:02:00.0] Family : NV50
> [7.571151] nouveau [
On Thu, Dec 5, 2013 at 10:17 AM, Bruno Prémont
wrote:
> Hi,
>
> With drm-nouveau-next branch on top of 3.13-rc2 and a few sound commits
> I get following errors in kernel log (repeating much more often).
> (once there was a corrupted fbcon with matrix-like strings of
> unrecognizable glyph-strings
On Wed, Dec 4, 2013 at 6:15 AM, Ilia Mirkin wrote:
> On Wed, Dec 4, 2013 at 6:01 AM, Bruno Prémont
> wrote:
>> [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22
>> [ 657.802123] general protection fault: [#1] SMP
>> [ 657.802130] Modules l
On Wed, Dec 4, 2013 at 6:01 AM, Bruno Prémont wrote:
> Hi,
>
> With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau:
> [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type
> mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95)
> [ 657.
On Mon, Dec 2, 2013 at 9:31 PM, Chris Forbes wrote:
> + *
> + * Also marks vbo/cb dirty if the buffer's binding
>
> Looks like this stops mid-sentence.
Hah, yeah. I kinda trailed off there, didn't I. Not sure how to finish
that sentence though -- it's if pipe_resource->bind &
PIPE_BIND_INDEX/VERT
Signed-off-by: Ilia Mirkin
---
This is my shot at understanding this whole transfer business. The upshot is
that after reading through it and understanding it, the transfer logic does
appear correct if potentially less-than-perfectly-efficient (e.g. one could
keep track of ranges being read
Signed-off-by: Ilia Mirkin
---
These look like pretty obvious typos. The x |= read; x &= ~write; (or
vice-versa) pattern occurs in nvc0, so I'm guessing that this is what was
intended here as well. Not sure if this fixes anything in particular though.
src/gallium/drivers/nou
See: https://bugs.freedesktop.org/show_bug.cgi?id=69155
Signed-off-by: Ilia Mirkin
Cc: "9.2 10.0"
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_sc
On Thu, Nov 21, 2013 at 5:22 PM, Ilia Mirkin wrote:
> On Thu, Nov 21, 2013 at 5:07 PM, Benjamin Morris wrote:
>> On 11/19/2013 08:16 PM, Ilia Mirkin wrote:
>>> Hello,
>>>
>>> I hope this is an appropriate style of request for this forum. I added
>>>
This resolves some rendering issues in source games.
See https://bugs.freedesktop.org/show_bug.cgi?id=64323
Signed-off-by: Ilia Mirkin
Cc: "9.2 10.0"
---
Doing a nouveau_bo_wait works as well, but I got a slightly higher framerate
from glretrace doing it this way. I tried to get
This fixes a memory leak in some situations. Also avoids emitting an
extra fence if the kick handler does the call to nouveau_fence_next
itself.
Signed-off-by: Ilia Mirkin
Cc: "9.2 10.0"
---
TBH I'm pretty confused by the whole fence refcounting logic and its
interaction with
Hi Christoph/nouveau folks,
I've noticed that the piglit test "texelFetch" fails on my nv98 for
sampler1DArray and sampler2DArray. I nuked the logic in
nv50_ir_lowering_nv50.cpp:604 that does the f32 -> u32 conversion, and
it seems to be passing now. TBH, I have no clue how the parameters are
pass
Reported-by: Jim Davis
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 38a4db5..4aff04f 100644
--- a/drivers/gpu/drm/nouveau
On Thu, Nov 21, 2013 at 5:07 PM, Benjamin Morris wrote:
> On 11/19/2013 08:16 PM, Ilia Mirkin wrote:
>> Hello,
>>
>> I hope this is an appropriate style of request for this forum. I added
>> code to support video decoding on the tesla cards that have a
>> simil
Hello,
I hope this is an appropriate style of request for this forum. I added
code to support video decoding on the tesla cards that have a
similar-style video decoding engine to fermi cards (i.e. G98, GT21x,
the IGP's -- the falcon-controlled decoding engines, rather than the
xtensa-controlled on
Signed-off-by: Ilia Mirkin
---
Copied from xf86-video-nouveau, I don't have the requisite cards to test it
out myself.
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index 32e7064..ba40c7b 100644
--- a/drivers/gpu/drm
Signed-off-by: Ilia Mirkin
---
Tested on a NV05, seems to work. I attempted to avoid duplication, so I ended
up with the function pointer. Doesn't seem too dirty, IMO.
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 176 +++--
1 file changed, 166 insertions(+
Signed-off-by: Ilia Mirkin
---
Copied from the (disabled) overlay code in xf86-video-nouveau. I verified that
my nv34 indeed doesn't scale down by more than 2, didn't test the factor of 8.
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 10 +-
1 file changed, 9 insertions(+),
Otherwise none of the format checks pass, since the width was still in
16.16 encoding.
Signed-off-by: Ilia Mirkin
---
This must have been some sort of last-second cleanup I made and forgot to
test, because with this code, there's no way it could ever have worked...
drivers/gpu/drm/no
Hi Ben,
Pre-nv40 cards don't have domains defined, which the
nouveau_clock_init code assumes exists. The following
(white-space-damaged, sorry) patch fixes boot for me, haven't really
tested the pre-nv40 cards in my system much further. I assume there's
some proper fix here.
-ilia
diff --git a
On Mon, Oct 28, 2013 at 12:31 PM, Martin Kaffanke
wrote:
> Am 2013-10-28 15:42, schrieb Ilia Mirkin:
>
>> On Mon, Oct 28, 2013 at 3:45 AM, Martin Kaffanke
>> wrote:
>>>
>>> Hi there,
>>>
>>> Sometimes my computer crashes since i use now ubunt
On Mon, Oct 28, 2013 at 3:45 AM, Martin Kaffanke wrote:
> Hi there,
>
> Sometimes my computer crashes since i use now ubuntu 13.10 with
> unity/compiz.
You're on NV4C. Do you have mesa 9.2.1 or later (or pre-9.2)? If you
have 9.2.0, there are known issues with shader compilation.
>
> dmesg tells
On Sun, Oct 27, 2013 at 11:01 PM, Robert Hancock wrote:
> On 10/27/2013 09:54 AM, Ilia Mirkin wrote:
>>
>> Certain combinations of hardware can't actually support the maximum
>> detected speed. Add a quirk list that lists pairs of hostbridge/chip pci
>> ids and the
Certain combinations of hardware can't actually support the maximum
detected speed. Add a quirk list that lists pairs of hostbridge/chip pci
ids and the mode that they should work with.
See https://bugs.freedesktop.org/show_bug.cgi?id=20341
Reported-by: Jason Detring
Signed-off-by: Ilia M
n, Oct 13, 2013 at 3:43 AM, Ilia Mirkin wrote:
>> ping
>>
>> On Fri, Oct 4, 2013 at 4:32 AM, Ilia Mirkin wrote:
>>> This CAP will determine whether ARB_framebuffer_object can be enabled.
>>> The nv30 driver does not allow mixing swizzled and linear zsbuf/cbuf
>
ping
On Fri, Oct 4, 2013 at 4:32 AM, Ilia Mirkin wrote:
> This CAP will determine whether ARB_framebuffer_object can be enabled.
> The nv30 driver does not allow mixing swizzled and linear zsbuf/cbuf
> textures.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/d
On Sun, Oct 6, 2013 at 6:31 AM, Fernando Negro wrote:
> The thing is, that, although I thought I had already run nouveau in it, I
> was, after all, only running a generic vesa driver, every time before I
> installed the proprietary drivers... And, I suppose that the wrong idea I
> had, of having b
When PIPE_CAP_MIXED_FRAMEBUFFER_SIZES is not provided, parts of
ARB_framebuffer_object can't be supported, such as on NV30.
Signed-off-by: Ilia Mirkin
---
src/mesa/state_tracker/st_extensions.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tr
This CAP will determine whether ARB_framebuffer_object can be enabled.
The nv30 driver does not allow mixing swizzled and linear zsbuf/cbuf
textures.
Signed-off-by: Ilia Mirkin
---
src/gallium/docs/source/screen.rst | 3 +++
src/gallium/drivers/freedreno/freedreno_screen.c | 1
This fixes issues where get_rt_format would see a 0 format because the
nouveau_surface had not been properly initialized. Fixes crash on
supertuxkart startup (which still fails due to out-of-vram issues).
Signed-off-by: Ilia Mirkin
---
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 9
On Thu, Oct 3, 2013 at 2:45 PM, Fernando Negro wrote:
> Hi everyone.
>
> I read on a 2011 article -
> http://www.phoronix.com/scan.php?page=article&item=nouveau_comp_2011&num=19
> - that my particular card, GeForce 8400 GS, overheats with nouveau. (So, I
> never tried using if for long, before, as
On Wed, Sep 25, 2013 at 4:46 PM, Daniel Melo Jorge da Cunha
wrote:
> Hi, is the following a (obsolete and nobody cares) bug?
>
> I have a fedora 19 i386 with nouveau and a GeForce 7100.
> The option "all" in gnome shell does not show any icon, although they are
> there
> because if I click on the
On Sun, Sep 8, 2013 at 12:53 PM, Tobias Klausmann
wrote:
> Hi there,
> with the latest snapshot of linus tree, i see a stack trace and my system
> does not start X! Maybe someone finds this useful! (3.11 is working like a
> charm)
Looks like you have Optimus (intel + nvidia), and the backtrace ha
This makes nv31+ able to actually perform the nv_call, since previously
the inst was not available.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 27 +++--
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.h | 9 +
2 files changed, 21
NV31 has different config bits than NV40+ do. Also fix the DMA_IMAGE
VRAM-only setting to check the right bits.
Signed-off-by: Ilia Mirkin
---
Sadly this doesn't cause things to start working on my NV34 PCI-E, even when I
make the gallium driver use VRAM for the cmd/data bo's (since
Since nv40 only covers pre-nv44 now, it can use the nv31-provided
functions.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c| 12 +---
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.h| 15 +
drivers/gpu/drm/nouveau/core/engine/mpeg/nv40.c| 68
The nv31/nv40 impls are actually fairly nv44-specific, since they assume
the presence of the instance register/context switching. Create a copy
before nv31/nv40 get fixed.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c
b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c
index c190043..5c54aa1 100644
--- a/drivers
Signed-off-by: Ilia Mirkin
---
This has received light testing on NV18 and NV34 cards, using the modetest
tool. Userspace support to use this for xv is not yet ready.
I decided against creating a new "pvideo" engine -- that just seems way too
heavy-handed compared to the ~10 lines
It means that an invalid command made it into the fifo. However I'm
not sure why that's happening -- at the very least, 0x00406040 seems
like a perfectly legitimate command.
On Thu, Sep 5, 2013 at 11:21 PM, James wrote:
>
> What does this mean:
> [ 626.850292] nouveau E[ PFIFO][:01:00.0] D
Signed-off-by: Ilia Mirkin
---
Tested on NV42 and NV44.
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c
b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c
index b966728
This enables the one-decoder-at-a-time logic for nv40-nv43, and
removes the unnecessary context setup.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/Makefile | 2 +-
drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 32 +-
.../nouveau/core/engine
The inst variable (and thus engctx) will not be properly populated for
pre-NV44 cards. The dma setter method didn't need it anyways, so call it
directly instead of the nv_call indirection.
Signed-off-by: Ilia Mirkin
---
An alternative is to move this logic into the nv44 intr handler,
In the process, fixes the VRAM check for DMA_IMAGE.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c
b/drivers/gpu/drm/nouveau/core
NV1A is numerically higher than NV17 but generationally lower. Use the
new card type to help disambiguate.
Signed-off-by: Ilia Mirkin
---
A previous version, not based on card type, was found to help NV1A users.
drivers/gpu/drm/nouveau/core/engine/device/base.c | 2 +-
drivers/gpu/drm
NV11/17/1F/18 come after NV10/15/16/1A. In order to facilitate using
numerical comparisons, split up the two sets into different card types.
This change should be a no-op except that the relevant cards will see
NV11 printed instead of NV10 for the family.
Signed-off-by: Ilia Mirkin
---
Only
This code was originally moved to using nv_mask by d31e078d84. This
should not have any actual effect since the mask isn't applied to the
value.
Signed-off-by: Ilia Mirkin
---
Not even compile-tested, but the change should be fairly self-evident.
drivers/gpu/drm/nouveau/dispnv04/dfp.
1301 - 1400 of 1419 matches
Mail list logo
