https://bugs.freedesktop.org/show_bug.cgi?id=91231
--- Comment #5 from Ilia Mirkin imir...@alum.mit.edu ---
Marek posted a patch for this at http://patchwork.freedesktop.org/patch/53843/
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew ac...@nvidia.com wrote:
Hello,
I am currently looking into ways to support fixed virtual address
allocations
and sparse mappings in nouveau, as a step towards supporting CUDA.
https://bugs.freedesktop.org/show_bug.cgi?id=91231
Béla Gyebrószki gyebr...@gmail.com changed:
What|Removed |Added
CC||gyebr...@gmail.com
On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew ac...@nvidia.com wrote:
These ioctls just call into the allocator to allocate a range of addresses,
resulting in a struct nvkm_vma that tracks that allocation (or releases the
struct
Lastly, from some discussions with ajax on IRC, it appears that DRI3
is half-baked at best wrt sync between server and client. I think we
should just disable it by default for now, until issues are ironed
out. (Rather than what this patch has, which is default-on for Xorg
some version.)
On Sat,
Ben,
Looks like the reality is that glamor is just not hooked up properly
in the nouveau DDX. Mainly it's missing DRI2, which in turn means no
core GL contexts, and probably lots of other issues. While this could
probably be fixed somehow, I doubt there's any advantage to using the
nouveau DDX
https://bugs.freedesktop.org/show_bug.cgi?id=91233
--- Comment #2 from Victor Porton por...@narod.ru ---
I've got a similar situation again.
The error was:
[171009.586992] nouveau E[ DRM] GPU lockup - switching to software fbcon
My hardware:
GeForce 8400 GS Rev. 3
--
You are receiving
On 7 July 2015 at 23:40, Ken Adams kad...@nvidia.com wrote:
Hello again,
I've updated my nouveau branch to incorporate some suggested tweaks, etc.
Also, this version breaks out all the chips separately. Seeing it
expressed this way shows how many files it is... :) I've removed the drf
On Tue, Jul 7, 2015 at 5:05 PM, Ben Skeggs skeg...@gmail.com wrote:
On 8 July 2015 at 06:06, Ilia Mirkin imir...@alum.mit.edu wrote:
Ben,
Looks like the reality is that glamor is just not hooked up properly
in the nouveau DDX. Mainly it's missing DRI2, which in turn means no
core GL
On 8 July 2015 at 07:09, Ilia Mirkin imir...@alum.mit.edu wrote:
On Tue, Jul 7, 2015 at 5:05 PM, Ben Skeggs skeg...@gmail.com wrote:
On 8 July 2015 at 06:06, Ilia Mirkin imir...@alum.mit.edu wrote:
Ben,
Looks like the reality is that glamor is just not hooked up properly
in the nouveau DDX.
On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew ac...@nvidia.com wrote:
Hello,
I am currently looking into ways to support fixed virtual address allocations
and sparse mappings in nouveau, as a step towards supporting CUDA.
CUDA requires that the GPU virtual address for a given buffer match the
On 8 July 2015 at 10:15, Andrew Chew ac...@nvidia.com wrote:
On Tue, Jul 07, 2015 at 08:13:28PM -0400, Ilia Mirkin wrote:
On Tue, Jul 7, 2015 at 8:11 PM, C Bergström cbergst...@pathscale.com wrote:
On Wed, Jul 8, 2015 at 7:08 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Tue, Jul 7, 2015 at
On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote:
There's some minimal state that needs to be mapped into GPU address space.
One thing that comes to mind are pushbuffers, which are needed to submit
stuff to any engine.
I guess you can probably use the start of the kernel's address
On 8 July 2015 at 10:31, Andrew Chew ac...@nvidia.com wrote:
On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote:
There's some minimal state that needs to be mapped into GPU address space.
One thing that comes to mind are pushbuffers, which are needed to submit
stuff to any engine.
On Tue, Jul 7, 2015 at 5:16 PM, Ben Skeggs skeg...@gmail.com wrote:
On 8 July 2015 at 07:09, Ilia Mirkin imir...@alum.mit.edu wrote:
On Tue, Jul 7, 2015 at 5:05 PM, Ben Skeggs skeg...@gmail.com wrote:
On 8 July 2015 at 06:06, Ilia Mirkin imir...@alum.mit.edu wrote:
Ben,
Looks like the
regarding
Fixed address allocations weren't going to be part of that, but I see
that it makes sense for a variety of use cases. One question I have
here is how this is intended to work where the RM needs to make some
of these allocations itself (for graphics context mapping, etc), how
On 8 July 2015 at 09:53, C Bergström cbergst...@pathscale.com wrote:
regarding
Fixed address allocations weren't going to be part of that, but I see
that it makes sense for a variety of use cases. One question I have
here is how this is intended to work where the RM needs to make
On Wed, Jul 8, 2015 at 6:58 AM, Ben Skeggs skeg...@gmail.com wrote:
On 8 July 2015 at 09:53, C Bergström cbergst...@pathscale.com wrote:
regarding
Fixed address allocations weren't going to be part of that, but I see
that it makes sense for a variety of use cases. One question I
On Tue, Jul 7, 2015 at 8:07 PM, C Bergström cbergst...@pathscale.com wrote:
On Wed, Jul 8, 2015 at 6:58 AM, Ben Skeggs skeg...@gmail.com wrote:
On 8 July 2015 at 09:53, C Bergström cbergst...@pathscale.com wrote:
regarding
Fixed address allocations weren't going to be part of that,
On Wed, Jul 08, 2015 at 10:37:34AM +1000, Ben Skeggs wrote:
On 8 July 2015 at 10:31, Andrew Chew ac...@nvidia.com wrote:
On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote:
There's some minimal state that needs to be mapped into GPU address
space.
One thing that comes to mind
https://bugs.freedesktop.org/show_bug.cgi?id=91231
Béla Gyebrószki gyebr...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 8 July 2015 at 06:06, Ilia Mirkin imir...@alum.mit.edu wrote:
Ben,
Looks like the reality is that glamor is just not hooked up properly
in the nouveau DDX. Mainly it's missing DRI2, which in turn means no
core GL contexts, and probably lots of other issues. While this could
probably be
22 matches
Mail list logo
