Displaying 20 results from an estimated 4000 matches similar to: "[Bug 91992] New: [NV4C] computer hangs after few minutes of use"
2017 Feb 26
6
[Bug 99968] New: [NV4C] System crashes reliably with glxinfo
https://bugs.freedesktop.org/show_bug.cgi?id=99968
Bug ID: 99968
Summary: [NV4C] System crashes reliably with glxinfo
Product: Mesa
Version: 12.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/DRI/nouveau
Assignee:
2015 Jul 27
4
[PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c
Hi,
On 24-07-15 04:32, Ben Skeggs wrote:
> On 24 July 2015 at 01:20, Hans de Goede <hdegoede at redhat.com> wrote:
>> MSI interrupts appear to not work for nv46 based cards. Change the mc
>> subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is
>> identical to the nv44 mc code except that it does not use msi
>> (it does not define a msi_rearm
2015 Jul 23
4
[PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c
MSI interrupts appear to not work for nv46 based cards. Change the mc
subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is
identical to the nv44 mc code except that it does not use msi
(it does not define a msi_rearm callback).
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90435
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
2015 Nov 30
4
NV50 compute support questions
Hi,
On 26-11-15 13:52, Samuel Pitoiset wrote:
<snip>
>> I do not have a GK106, I've a GK208, and IIRC that one is known to not
>> work,
>> I guess I can give it a try.
>
> Compute support is not supported on GK110+, yeah...
>
> If you provide me a MMT trace of, for example, vectorAdd from the CUDA samples I could have a look.
Ok, here is a MMT trace of
2015 Aug 03
3
"enable dri3 support without glamor" causes gnome-shell regression on nv4x
Hi,
On 30-07-15 16:09, Ilia Mirkin wrote:
> FWIW this is a fail on nv50+ as well. See for example
> https://bugs.freedesktop.org/show_bug.cgi?id=91445
>
> My suspicion is that this is due to the lack of PUSH_KICK in the *Done
> exa handlers -- works fine with DRI2, but DRI3 has no synchronization
> and so the commands never get flushed out. Easily verified by sticking
>
2015 Dec 16
4
Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
I believe that your problem is this:
/*01a0*/ LD R8, [R8];
/* 0x8000000000821c85 */
That needs to be LD.E (and your ST's need to be ST.E). You're using a
32-bit gmem address, but you need to be using a 64-bit one. I believe
the 32-bit ones work on fermi, but afaik not on Kepler.
Cheers,
-ilia
On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede
2015 Dec 15
2
Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Also, where's the exit op? Perhaps what's happening is that you don't
have an exit and it just goes off executing into the ether?
On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> A few things that stand out:
>
> 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0)
>
> wtf is that 0x0000000000000 thing doing there? Was it a %rX which got
2015 Jun 05
60
[Bug 90871] New: NV30: Xfwm4 use_compositing - garbled display
https://bugs.freedesktop.org/show_bug.cgi?id=90871
Bug ID: 90871
Summary: NV30: Xfwm4 use_compositing - garbled display
Product: xorg
Version: unspecified
Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
Severity: critical
Priority: medium
Component: Driver/nouveau
Assignee:
2015 Nov 13
6
llvm TGSI backend (WIP) questions
Hi All,
So as discussed I've started working on a TGSI backend for
llvm to use as a way to get compute going on nouveau (and other gpu-s).
I'm still learning all the ins and outs of llvm so I do not have
much to show yet.
I've rebased Francisco's (curro's) latest version on top of llvm
trunk, and added a commit on top to actual get it build with the
latest trunk. So
2015 Aug 03
2
"enable dri3 support without glamor" causes gnome-shell regression on nv4x
Hi,
On 03-08-15 17:36, Ilia Mirkin wrote:
> On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi,
>>
>> On 30-07-15 16:09, Ilia Mirkin wrote:
>>>
>>> FWIW this is a fail on nv50+ as well. See for example
>>> https://bugs.freedesktop.org/show_bug.cgi?id=91445
>>>
>>> My suspicion is that this is
2015 Dec 02
3
NV50 compute support questions
On 01-12-15, Samuel Pitoiset wrote:
>>> Ok, here is a MMT trace of vectorAdd:
>>>
>>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz
>>
>> Hi Hans,
>>
>> Thanks a lot.
>
> Well, I didn't know but Martin has a GK208...
> I just tested the compute support on his card and ... it works without
> any changes. :-)
2016 Jan 11
4
Some llvm questions (for tgsi backend)
Hi,
After a few distractions I'm back to work on the llvm tgsi backend. I've
added clang integration and I can now compile a simple opencl program
to something which sort of looks like tgsi.
You can find my latest work on this here:
http://cgit.freedesktop.org/~jwrdegoede/llvm
http://cgit.freedesktop.org/~jwrdegoede/clang
(the latter may still need to sync)
I've a little test
2014 Dec 16
0
[PATCH] mc/nv4c: disable msi
Several users have, over time, reported issues with MSI on these IGPs.
They're old, rarely available, and MSI doesn't provide such huge
advantages on them. Just disable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87361
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74492
Fixes: fa8c9ac72fe ("drm/nv4c/mc: nv4x igp's have a different msi rearm register")
2015 Dec 15
2
Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Hi all,
As part of my compute work I'm trying to get some TGSI compute
code to work. The code from mesa/src/gallium/tests/trivial.c
works.
So now I'm trying to get a "native" tgsi kernel to run via
clover, I'm using Francisco's nbody.c example for this:
https://fedorapeople.org/~jwrdegoede/nbody.c
Which does not work, at first I thought there was an issue
with the
2015 Jul 30
2
"enable dri3 support without glamor" causes gnome-shell regression on nv4x
Hi Maarten,
xf86-video-nouveau causes a garbled display when running
gnome-shell on nv4x (tested with nv43 and nv46) since this commit:
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e7289f25a342a457952b9b0e539c2f0b81d99
I've seen some discussion about issues caused by enabling dri,
but AFAIK no solution let.
I have time to help with debugging / fixing this, but I
2015 Nov 20
2
NV50 compute support questions
Hi,
On 20-11-15 17:07, Samuel Pitoiset wrote:
>
>
> On 11/20/2015 11:36 AM, Hans de Goede wrote:
>> Hi Samual, et al,
>
> Hi Hans,
>
>>
>> In
>> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau?id=ff72440b40211326eda118232fabd53965410afd
>>
>> you write: "This compute support has been tested by
>> Pierre
2016 Mar 14
2
[RFC mesa] nouveau: Add support for OpenCL global memory buffers
Hi,
On 14-03-16 16:41, Samuel Pitoiset wrote:
>
>
> On 03/14/2016 04:28 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 14-03-16 16:05, Ilia Mirkin wrote:
>>> There's a less hacky and more hacky way forward. The more hacky
>>> solution is
>>> to set file index to -1 or something and then not do the lowering when
>>> you
>>> see
2014 Feb 05
2
[PATCH 1/3] drm/nv4c/mc: nv4x igp's have a different msi rearm register
See https://bugs.freedesktop.org/show_bug.cgi?id=74492
Reported-by: Ronald <ronald645 at gmail.com>
Suggested-by: Marcin Ko?cielnicki <koriakin at 0x04.net>
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 10 ++---
2011 Jan 28
8
[Bug 33668] New: [regression] [nv4c] Screen corruption
https://bugs.freedesktop.org/show_bug.cgi?id=33668
Summary: [regression] [nv4c] Screen corruption
Product: xorg
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
AssignedTo: nouveau at lists.freedesktop.org
2016 Mar 17
1
[RFC mesa] nouveau: Add support for OpenCL global memory buffers
Hi,
On 14-03-16 21:50, Samuel Pitoiset wrote:
<snip>
>>> Btw, do you need someone with commit access to push your previous
>>> series (the tgsi thing)? I can do this for you.
>>
>> Thanks for the offer. IIRC Ilia wanted some minor fixes there, so I'll do
>> a v2 tomorrow. Talking about commit rights, I guess it would be
>> convenient for all