Hello,
My system died last night apparently due to OOM conditions. Note that
I don't have any swap set up, but my understanding is that this is not
required. The full log is at: http://pastebin.com/YCYUXWvV. It was in
my messages, so I guess the system took a bit to die completely.
nouveau is
On Fri, Mar 29, 2013 at 11:22 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 27-03-13 14:25:36, Ilia Mirkin wrote:
Hello,
My system died last night apparently due to OOM conditions. Note that
I don't have any swap set up, but my understanding is that this is not
required. The full log
On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter c...@linux.com wrote:
On Wed, 27 Mar 2013, Ilia Mirkin wrote:
The GPF happens at +160, which is in the argument setup for the
cmpxchg in slab_alloc_node. I think it's the call to
get_freepointer(). There was a similar bug report a while back
On Sat, Apr 6, 2013 at 5:01 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter c...@linux.com wrote:
On Wed, 27 Mar 2013, Ilia Mirkin wrote:
The GPF happens at +160, which is in the argument setup for the
cmpxchg in slab_alloc_node. I think it's
the mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
This patch applies on top of nouveau/master (16a41bcc8).
This seems to work for me. There was one boot where my userspace
component
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/Makefile.sources | 3 +-
src/gallium/drivers/nouveau/nouveau_vp3_video.h| 6 +
src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c | 485 +
src/gallium/drivers/nvc0/nvc0_video.h
h264/mpeg4 remain disabled for pre-nvc0, there's some minor
bug/difference which causes the decoding to hang after some frames.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nouveau_vp3_video.c | 39 ++-
src/gallium/drivers/nv50/Makefile.sources | 6
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: sta...@vger.kernel.org # 3.8+
---
I don't exactly understand what's going on, but this is just a
straightforward way to avoid a null deref that you see happens in the
bug. I haven't figured out the root cause of this, but it's getting
well
Deifel hpdei...@gmx.de
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
This will only happen if i2c_algo_bit.bit_test=1.
drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 8 +---
drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
drivers/gpu/drm/nouveau/core/subdev/i2c
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 imir...@alum.mit.edu
---
Tested on NV42. Ben, I'm going to guess that you hate
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach d...@lynxeye.de wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach d...@lynxeye.de wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs skeg...@gmail.com wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs skeg...@gmail.com wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu
Hi Ben,
Someone came in to the channel to report that the outputs on the
second gpu of the NVS 420 were not being detected properly. Emil
tracked it down to the pclass == PCI_CLASS_DISPLAY_VGA check in
nouveau_display that you added in e412e95a in order to avoid
modesetting on Tesla cards. This
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
drivers/gpu/drm/nouveau/nouveau_connector.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index 6e399aa..4cefce3 100644
--- a/drivers/gpu/drm
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 imir...@alum.mit.edu
---
Not even compile-tested, but the change should be fairly self-evident.
drivers/gpu/drm/nouveau
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 imir
In the process, fixes the VRAM check for DMA_IMAGE.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
NV1A is numerically higher than NV17 but generationally lower. Use the
new card type to help disambiguate.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
A previous version, not based on card type, was found to help NV1A users.
drivers/gpu/drm/nouveau/core/engine/device/base.c | 2
This enables the one-decoder-at-a-time logic for nv40-nv43, and
removes the unnecessary context setup.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
drivers/gpu/drm/nouveau/Makefile | 2 +-
drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 32
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 imir...@alum.mit.edu
---
An alternative is to move this logic into the nv44 intr
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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 bjloc...@lockie.ca wrote:
What does this mean:
[ 626.850292] nouveau E[
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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 imir...@alum.mit.edu
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu
Since nv40 only covers pre-nv44 now, it can use the nv31-provided
functions.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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 imir...@alum.mit.edu
---
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
This makes nv31+ able to actually perform the nv_call, since previously
the inst was not available.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 27 +++--
drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.h | 9
On Sun, Sep 8, 2013 at 12:53 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de 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
On Wed, Sep 25, 2013 at 4:46 PM, Daniel Melo Jorge da Cunha
dmjcu...@gmail.com 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
On Thu, Oct 3, 2013 at 2:45 PM, Fernando Negro fernando.ne...@mail.ru wrote:
Hi everyone.
I read on a 2011 article -
http://www.phoronix.com/scan.php?page=articleitem=nouveau_comp_2011num=19
- that my particular card, GeForce 8400 GS, overheats with nouveau. (So, I
never tried using if for
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 imir...@alum.mit.edu
---
src/mesa/drivers/dri/nouveau
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 imir...@alum.mit.edu
---
src/gallium/docs/source/screen.rst | 3 +++
src/gallium/drivers/freedreno
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 imir...@alum.mit.edu
---
src/mesa/state_tracker/st_extensions.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src
On Sun, Oct 6, 2013 at 6:31 AM, Fernando Negro f3rn4nd0.n3...@gmail.com 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
ping
On Fri, Oct 4, 2013 at 4:32 AM, Ilia Mirkin imir...@alum.mit.edu 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 imir...@alum.mit.edu
---
src
, Oct 13, 2013 at 3:43 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
ping
On Fri, Oct 4, 2013 at 4:32 AM, Ilia Mirkin imir...@alum.mit.edu 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
-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I didn't go as far as subdevice matching... IMO that's overkill for now.
drivers/gpu/drm/nouveau/nouveau_agp.c | 44 +++
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_agp.c
On Sun, Oct 27, 2013 at 11:01 PM, Robert Hancock hancock...@gmail.com 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 mode
On Mon, Oct 28, 2013 at 3:45 AM, Martin Kaffanke martin.kaffa...@gmx.at 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
On Mon, Oct 28, 2013 at 12:31 PM, Martin Kaffanke
martin.kaffa...@gmx.at wrote:
Am 2013-10-28 15:42, schrieb Ilia Mirkin:
On Mon, Oct 28, 2013 at 3:45 AM, Martin Kaffanke martin.kaffa...@gmx.at
wrote:
Hi there,
Sometimes my computer crashes since i use now ubuntu 13.10 with
unity/compiz
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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 Thu, Nov 21, 2013 at 5:07 PM, Benjamin Morris bmor...@nvidia.com 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
similar-style video decoding
Reported-by: Jim Davis jim.ep...@gmail.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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
passed
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 imir...@alum.mit.edu
Cc: 9.2 10.0 mesa-sta...@lists.freedesktop.org
---
TBH I'm pretty confused by the whole fence
This resolves some rendering issues in source games.
See https://bugs.freedesktop.org/show_bug.cgi?id=64323
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 9.2 10.0 mesa-sta...@lists.freedesktop.org
---
Doing a nouveau_bo_wait works as well, but I got a slightly higher framerate
from
On Thu, Nov 21, 2013 at 5:22 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Nov 21, 2013 at 5:07 PM, Benjamin Morris bmor...@nvidia.com 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
://bugs.freedesktop.org/show_bug.cgi?id=69155
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 9.2 10.0 mesa-sta...@lists.freedesktop.org
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
On Mon, Dec 2, 2013 at 9:31 PM, Chris Forbes chr...@ijw.co.nz 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
On Wed, Dec 4, 2013 at 6:01 AM, Bruno Prémont bonb...@linux-vserver.org 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]
On Wed, Dec 4, 2013 at 6:15 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Wed, Dec 4, 2013 at 6:01 AM, Bruno Prémont bonb...@linux-vserver.org
wrote:
[ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22
[ 657.802123] general protection fault: [#1] SMP
[ 657.802130
On Thu, Dec 5, 2013 at 10:17 AM, Bruno Prémont
bonb...@linux-vserver.org 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
On Fri, Dec 6, 2013 at 2:44 AM, Thomas Glanzmann tho...@glanzmann.de 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
[
On Fri, Dec 6, 2013 at 8:30 AM, Thomas Glanzmann tho...@glanzmann.de 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]
On Fri, Dec 6, 2013 at 7:36 PM, Benjamin Morris bmor...@nvidia.com 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
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 imir...@alum.mit.edu wrote:
On Fri, Dec 6, 2013 at 7:36 PM, Benjamin
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 imir...@alum.mit.edu
Cc: 10.0 mesa-sta...@lists.freedesktop.org
---
Would be great if someone could see if this also makes MPEG4 work
this comment to reflect reality. Or just remove it.
With that change,
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
Or I can fold this into my h264 change if you don't want to send a v2,
up to you.
return profile = PIPE_VIDEO_PROFILE_MPEG1 (
--
1.8.4.2
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 imir...@alum.mit.edu
Cc: sta...@vger.kernel.org
---
Couldn't get video decoding started on a long-running system
On Fri, Dec 6, 2013 at 11:43 PM, Ilia Mirkin imir...@alum.mit.edu 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 imir...@alum.mit.edu
Cc: 10.0 mesa-sta
Based on comments by Benjamin Morris bmor...@nvidia.com 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 imir...@alum.mit.edu
---
src/gallium/drivers
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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 imir...@alum.mit.edu
Tested-by: Martin Peres martin.pe...@labri.fr
Fixes the texelFetch piglit tests.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
On Wed, Dec 11, 2013 at 6:43 AM, Bruno Prémont
bonb...@linux-vserver.org 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
I get following
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 s@gmx.de
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: sta
On Thu, Dec 12, 2013 at 2:32 AM, Matthias Nagel
matthias.h.na...@gmail.com 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]
On Sat, Dec 14, 2013 at 9:20 AM, ael law_ence@ntlworld.com 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
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
matthias.h.na...@gmail.com wrote:
Hello,
I run the Gentoo Linux distribution and use a self-compiled Linux 3.10.17
kernel. According to
[1] http
On Tue, Dec 31, 2013 at 5:14 AM, Sid Boyce sbo...@blueyonder.co.uk 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
On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce sbo...@blueyonder.co.uk wrote:
On 31/12/13 10:36, Ilia Mirkin wrote:
On Tue, Dec 31, 2013 at 5:14 AM, Sid Boyce sbo...@blueyonder.co.uk
wrote:
System x86_64 with openSUSE 13.1.
X.Org version: 1.14.99.905
openSUSE 12.2 kernels boot successfully
On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce sbo...@blueyonder.co.uk wrote:
On 01/01/14 00:55, Ilia Mirkin wrote:
On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce sbo...@blueyonder.co.uk
wrote:
On 31/12/13 10:36, Ilia Mirkin wrote:
Having a dmesg would be nice. One thing I can think of off-hand
On Wed, Jan 1, 2014 at 3:29 PM, Michele Baldessari mich...@acksyn.org 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:
With drm-nouveau-next branch on top of 3.13
On Wed, Jan 1, 2014 at 9:36 PM, Sid Boyce sbo...@blueyonder.co.uk wrote:
On 01/01/14 18:46, Ilia Mirkin wrote:
On Wed, Jan 1, 2014 at 9:04 AM, Sid Boyce sbo...@blueyonder.co.uk wrote:
On 01/01/14 00:55, Ilia Mirkin wrote:
On Tue, Dec 31, 2013 at 7:41 PM, Sid Boyce sbo...@blueyonder.co.uk
On Mon, Jan 6, 2014 at 7:53 AM, fbs 777 fbs...@gmail.com 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.
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
On Thu, Jan 9, 2014 at 7:14 PM, Grant emailgr...@gmail.com 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?
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
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 imir...@alum.mit.edu
---
An earlier version of this patch was tested. I added
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 imir...@alum.mit.edu
---
Not strictly needed, but I think it's nice to unify it all
On Thu, Jan 9, 2014 at 4:04 AM, Ilia Mirkin imir...@alum.mit.edu 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's approximately
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 imir...@alum.mit.edu
---
In a perfect world I'd have separate callbacks for depth and color, but given
On Fri, Jan 10, 2014 at 2:32 PM, Javier Domingo Cansino
javier...@gmail.com 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
of
EXT_framebuffer_multisample piglit tests.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
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
On Mon, Jan 13, 2014 at 12:51 PM, Grant emailgr...@gmail.com 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
From: Christoph Bumiller e0425...@student.tuwien.ac.at
---
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
: 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: add support
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 imir...@alum.mit.edu
---
I'm not particularly happy with this patch. Some investigation needs to happen
as to what's going on here. NVIDIA's
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 imir...@alum.mit.edu
1 - 100 of 1338 matches
Mail list logo
