-rd.shader_test and
vs-output-array-vec4-index-wr-before-gs.shader_test on nvc0 at least.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git
-rd.shader_test and
vs-output-array-vec4-index-wr-before-gs.shader_test on nvc0 at least.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.5 10.6 mesa-sta...@lists.freedesktop.org
---
v1 - v2:
- redo final section of ConstantFolding::expr using a switch, per tobijk
.../drivers/nouveau/codegen
clearing.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nv30/nv30_clear.c | 2 +-
src/gallium/drivers/nouveau/nv30/nv30_context.h| 2 +-
src/gallium/drivers/nouveau/nv30/nv30_draw.c | 4 ++--
src/gallium/drivers/nouveau/nv30
nv30_validate_clip depends on the rasterizer state. Also we should
upload all the new clip planes on change since next time the plane data
won't have changed, but the enables might.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nv30/nv30_state_validate.c | 16
On Thu, May 21, 2015 at 10:05 AM, Robert Morell rmor...@nvidia.com wrote:
Hi Ilia,
On Sat, May 02, 2015 at 12:34:21PM -0400, Ilia Mirkin wrote:
Hi,
As I'm looking to add some support to nouveau for features like atomic
counters and images, I'm running into some confusion about what
, rather than just the top 1. However I see no
such behaviour on GF108.
I'm going to test out tomorrow whether this is the cause of my GK208 woes.
On Fri, May 22, 2015 at 5:10 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, May 18, 2015 at 4:48 PM, Ilia Mirkin imir...@alum.mit.edu wrote
to work/works, and I believe
most of that is due to legacy reasons. I'm just saying let's not do
the whole thing - just the dri version would be great (as you
suggested).
-Emil
On 4 July 2015 at 19:28, Ilia Mirkin imir...@alum.mit.edu wrote:
Erm, that's nuts. I also don't really understand
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
On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@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 due to the lack of PUSH_KICK in the *Done
Supposed to? Sure! :) DP is finicky in general, and Maxwell is a
fairly new generation that not a lot of people have tested or had
access to, so quite expected for things to go wrong. Can you file a
bug at bugs.freedesktop.org xorg - Driver/nouveau with the output of
nouveau loaded with
I said this on IRC, but I'll say it here too:
(a) please regenerate this with -M (not in the general case, but it
makes sense here)
(b) this seems odd as there's no support for cull distance elsewhere
yet. should be part of a series that adds cull distance support. right
now there is none, so
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Seen on my GK208. Trace available at
http://people.freedesktop.org/~imirkin/traces/gk208/gk208-mmiotrace.log.xz
Thanks to Roy for his assistance on finding the parameters. I tested
this on top of his patch bios/rammap: Identify DLLoff
This fixes arb_get_texture_sub_image-get, and any situation where the 2d
engine was being used for multi-layer blits to a non-0 level.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.6 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 14
On Tue, Aug 18, 2015 at 9:57 PM, Matt Turner matts...@gmail.com wrote:
On Tue, Aug 18, 2015 at 6:49 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Some shaders appear to extract bits using shift/and combos. Detect
(some) of those and convert to EXTBF instead.
What is EXTBF? Extract byte to float
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Entirely untested as there are no piglit tests for this
functionality. Won't push until some appear, but wanted to get it out
there.
.../drivers/nouveau/codegen/nv50_ir_driver.h | 2 +-
.../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
The hardware only generates vertexid when vertices come from a VBO. This
fixes:
vertexid-drawelements
vertexid-drawarrays
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 11.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nv50/nv50_program.c| 1 +
src/gallium
On Mon, Aug 24, 2015 at 11:57 AM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
On 24.08.2015 17:51, Ilia Mirkin wrote:
The hardware only generates vertexid when vertices come from a VBO. This
fixes:
vertexid-drawelements
vertexid-drawarrays
Signed-off-by: Ilia
Some shaders appear to extract bits using shift/and combos. Detect
(some) of those and convert to EXTBF instead.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 66 +++---
1 file changed, 46 insertions(+), 20 deletions
of that.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1 +
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 2 +
.../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 4 ++
.../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 79
Hello,
It seems that NVIDIA GPUs, at least starting with G80, have an
optimized path for the sequence
draw;
update consts;
draw;
update consts;
etc
Whereby it will start processing draw2 before draw1 is done. To do
this, it appears there's some magic constbuf cache on the chip which
buffers the
The RING_SPACE macro accounts how much space is used up so it's
important to ask it for the right amount. Incorrect accounting of this
can cause page faults down the line as writes are attempted outside of
the ring.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: sta...@vger.kernel.org
Only 58 words get written to the ring, not 59. Also, normalize the accel
init wrt nvc0 and nv04 fbcon impls by firing the ring at accel init time
rather than waiting until later.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
drm/nouveau/nv50_fbcon.c | 3 ++-
1 file changed, 2 insertions
On Thu, Jun 25, 2015 at 10:41 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
Hello,
We recently tracked down a bug on Tesla GPUs (i.e. G80-GT218) whereby
it appears that instructions like
0028: b5000409 08000780 add rn f32 $r2 $r2 neg c0[$a1]
0040: b500060d 08004780 add rn f32
to a DRI level to make it consistent with the
same option in the released Intel-ddx.
Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
Cc: Ilia Mirkin imir...@alum.mit.edu
Cc: Emil Velikov emil.l.veli...@gmail.com
Cc: Martin Peres martin.pe...@free.fr
Cc: Ben Skeggs bske
Series is Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
I'll let it sit for a day or so in case others have feedback.
On Wed, Jul 29, 2015 at 8:39 AM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
Allow user to select the maximum level of DRI implementation
to use, DRI2 or DRI3.
exa accel
On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 03-08-15 17:36, Ilia Mirkin wrote:
On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@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
On Mon, Aug 10, 2015 at 8:47 AM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 03-08-15 20:09, Ilia Mirkin wrote:
On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 03-08-15 17:36, Ilia Mirkin wrote:
On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego
On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote:
GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family...
The update was made using DNF (Yum) in my daily update procedure using
the Fedora 22 Update repository.
I am not familiar with details I just can
wrote:
Thanks - the only xorg.conf I found is -
/usr/share/abrt/conf.d/plugins/xorg.conf
Is this the file to be edited?
--
Rudolf Künzli rudolf.kun...@gmail.com
On Tue, 2015-08-11 at 10:56 -0400, Ilia Mirkin wrote:
On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli
rudolf.kun...@gmail.com
for. find didn't help...
I guess I'll have to run x config as root to get a xorg.conf which I
can edit later...
--
Rudolf Künzli rudolf.kun...@gmail.com
On Tue, 2015-08-11 at 11:42 -0400, Ilia Mirkin wrote:
No, you probably want something in /etc/X11... a lot of the time it's
split up
I don't understand this patch (what are all these masks? how are they
used?), and don't want to invest the time required to do so.
However Mario is probably the sole serious user of ZaphodHeads, and if
it fixes issues for him, probably fixes issues for others who try and
give up with ZaphodHeads.
Alexandre, could you take a look? 0xbad* generally comes from bad mmio
reads.
On Aug 9, 2015 1:08 PM, Eric Biggers ebigge...@gmail.com wrote:
Hi,
I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly
after
startup in gk104_fifo_intr_runlist(). What I've found is that the
}
0x EXPORT_EN_1 = 0
0x EXPORT_EN_2 = 0
0x EXPORT_EN_3 = 0
0x EXPORT_EN_4 = 0
0x EXPORT_EN_5 = { CLIP_DISTANCE = 0 | UNK12 = 0 }
0x 19 = 0
Anything that we need to also be setting?
-ilia
On Mon, Jun 22, 2015 at 9:10 PM, Ilia Mirkin imir
Apparently this is necessary in order for tess factors to work in a tess
eval program without a tess control program bound. Probably because it
uses the fake program's shader header to work out the number of patch
constants.
Fixes vs-tes-tessinner-tessouter-inputs
Signed-off-by: Ilia Mirkin imir
that patch.
Eric, would you be able to give an estimate of the repro rate for this
issue? More testing with and without the patch would be welcome, it'd
be good to know whether it is actually the culprit or not.
On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
Alexandre, could
Here's an example of what happens with DRI3:
https://bugs.freedesktop.org/show_bug.cgi?id=91445
I'm not equipped to figure out why.
On Mon, Jul 13, 2015 at 11:43 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
On 07/07/2015 09:51 PM, Ilia Mirkin wrote:
Lastly, from some discussions
MEM_OUT_OF_BOUNDS errors with tessellation shaders are gone.
On Thu, Jul 23, 2015 at 2:36 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
I think I figured out what was going on. Will re-check on the GK208,
but on a GF108 the random blue splotches in Unigine Heaven are gone
now. Turns out that with an instruction
, May 26, 2015 at 7:34 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
One additional observation that I just made is that on GK208, the blob
apparently doesn't use the result of S2R Rx, SR_INVOCATION_ID
wholesale in TCS. It either passes it through a I2I.S32.S32 Rx, |Rx|
(i.e. absolute value), or even
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
On Tue, Jul 21, 2015 at 5:51 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
The variables are already set/substituted by the PKG_CHECK_MODULES
macro.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
configure.ac | 4
1 file
On Mon, Jul 13, 2015 at 11:43 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
On 07/07/2015 09:51 PM, Ilia Mirkin wrote:
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
On Tue, Jul 14, 2015 at 3:00 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
On 07/14/2015 05:26 PM, Ilia Mirkin wrote:
On Mon, Jul 13, 2015 at 11:43 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
On 07/07/2015 09:51 PM, Ilia Mirkin wrote:
Lastly, from some discussions with ajax
---
src/nouveau_dri2.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index f22e319..4398559 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -142,6 +142,7 @@ nouveau_dri2_copy_region2(ScreenPtr pScreen,
, 2015 at 5:46 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 14 July 2015 at 22:17, Ilia Mirkin imir...@alum.mit.edu wrote:
---
src/nouveau_dri2.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index f22e319
Any one which, after using a geometry shader, enables an extra clip
distance. i.e. none.
On Mon, Jul 13, 2015 at 4:16 AM, Samuel Pitoiset
samuel.pitoi...@gmail.com wrote:
What piglit test does this fix?
On Sat, Jul 11, 2015 at 7:13 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Signed-off
This was, btw, introduced in commit 3a8ae6ac243b (nvc0: adapt to new
clip state). Back then there was no real geometry support yet.
On Mon, Jul 13, 2015 at 2:05 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Any one which, after using a geometry shader, enables an extra clip
distance. i.e. none
-by: Samuel Pitoiset samuel.pitoi...@gmail.com
This fix is simpler than I was expected. What about the edge flag stuff now?
:)
On 08/24/2015 05:51 PM, Ilia Mirkin wrote:
The hardware only generates vertexid when vertices come from a VBO. This
fixes:
vertexid-drawelements
vertexid
On Fri, Oct 2, 2015 at 6:14 PM, Robert Morell <rmor...@nvidia.com> wrote:
> Hi Ilia,
>
> On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote:
>> Hi Robert,
>>
>> Thanks for the quick response! That goes in line with my observations
>> which is that
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70354#c75
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
Unclear if we want this. Someone with the same vendor/subvendor pci
ids didn't have any issues with nouveau at all:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1
).
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nvc0/nvc0_vbo_translate.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_vbo_translate.c
b/src/gallium/d
> works very similarly) create a new helper to arm vblank events for
> such drivers.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
> Cc: Thierry Reding <tred...@nvidia.com>
> Cc: Mario Kleiner <mario.kleiner...@gmail.com>
> Cc: Ben Skeggs <bske...@
On Fri, Nov 13, 2015 at 3:42 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 13 November 2015 at 14:38, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> On Fri, Nov 13, 2015 at 9:25 AM, Emil Velikov <emil.l.veli...@gmail.com>
>> wrote:
>>> H
See libdrm's pushbuf.c -- iirc push->cur points to a GART-mapped bo.
http://cgit.freedesktop.org/mesa/drm/tree/nouveau/pushbuf.c#n682
nouveau_pushbuf_data(push, NULL, 0, 0);
nouveau_bo_ref(bo, >bo);
nouveau_bo_ref(NULL, );
nvpb->bgn = nvpb->bo->map;
nvpb->ptr = nvpb->bgn;
push->cur = nvpb->bgn;
usion and thanks for the reply.
> Awaiting
> for an answer if possible. Thanks in advance.
>
> 2015-11-02 14:44 GMT-03:00 Ilia Mirkin <imir...@alum.mit.edu>:
>>
>> See libdrm's pushbuf.c -- iirc push->cur points to a GART-mapped bo.
>>
>> http://cgit.freede
e when it is actual possible.
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nv50_display.c | 8
drm/nouveau/nvkm/engine/disp/gf119.c | 2 +-
drm/nouveau/nvkm/engine/disp/nv50.c | 2 +-
3 files changed,
Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nouveau_connector.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nvkm/engine/gr/ctxgk20a.c | 2 +-
drm/nouveau/nvkm/subdev/fb/ramgk104.c | 8
drm/nouveau/nvkm/subdev/therm/nv40.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drm/nouveau/nvkm/eng
://bugs.freedesktop.org/show_bug.cgi?id=91236
Having an accurate way to auto-detect this would be ideal though, as
higher bandwidth monitors are becoming more ubiquitous.
-ilia
On Mon, Oct 26, 2015 at 1:35 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> Hello,
>
> Various HDMI versions enable hi
Hi Hans,
All pushed. I made a few additional fixes and improvement to fp64
immediate handling along the way, but all your commits were fine
as-is. (Except that they enabled fp64 immediates on nv50 implicitly
which is wrong -- there are no immediate-taking variants on nv50, so I
fixed that glitch.
On Fri, Nov 6, 2015 at 4:19 PM, Robert Morell <rmor...@nvidia.com> wrote:
> On Fri, Nov 06, 2015 at 04:15:29PM -0500, Ilia Mirkin wrote:
>> In order for ATOM.*/RED.* to work, the addresses in question must
>> *NOT* be inside of the 16MB local/shared windows. So if I'm
On Wed, Nov 4, 2015 at 3:38 AM, C Bergström wrote:
> To bring this conversation back on track - where would someone start
> *exactly* to port this to another OS? What kernel dependencies are
> there?
drivers/gpu/drm/nouveau/{nvkm,nvif,usif} can be dropped in wholesale
On Tue, Nov 3, 2015 at 7:02 PM, Ben Skeggs <skeg...@gmail.com> wrote:
> On 11/04/2015 08:41 AM, Ilia Mirkin wrote:
>> From: Hauke Mehrtens <ha...@hauke-m.de>
>>
>> Without this patch a pixel clock rate above 165 MHz on a TMDS link is
>> assume
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nv50_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
index bdaba91..d9cba87 100644
--- a/drm/nouveau/nv50_display.c
+++ b/drm/nouveau/nv50_display.c
@@
e when it is actually possible and requested.
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
[imirkin: check for hdmi monitor for computing proto, use sor ctrl to
enable extra config bit]
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nv50_display.c | 18 +
Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nouveau_connector.
Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nouveau_connector.
e when it is actually possible and requested.
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
[imirkin: check for hdmi monitor for computing proto, use sor ctrl to
enable extra config bit]
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nv50_display.c | 15 ++
Nouveau kernel module has a largely os-agnostic "core" component (called
nvkm/nvif now) which encompasses the actual operation of the GPU. The drm
wrapper around it provides the relevant interfaces for KMS/ioctls/etc. Any
port would want the ioctl bits as well, since that's what the userspace
On Fri, Nov 6, 2015 at 3:59 PM, Robert Morell <rmor...@nvidia.com> wrote:
> On Fri, Oct 02, 2015 at 06:05:21PM -0400, Ilia Mirkin wrote:
>> Could you advise what the proper way of indicating
>> that the memory is "global" to the op? I'm sure I'm just missing
>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91557
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nvkm/engine/device/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drm/nouveau/nvkm/engine/device/pci.c
b/drm/nouveau/nvkm/engine/device/pci.c
index e
NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE,
which apparently happens when trying to use an atomic operation on
local or shared memory (instead of global memory).
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nvkm/engine/gr/gf100.c | 1 +
GF110+ supports both the A and B compute classes, make sure to accept
both.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nvkm/engine/gr/gf110.c | 1 +
drm/nouveau/nvkm/engine/gr/gf117.c | 1 +
drm/nouveau/nvkm/engine/gr/gf119.c | 1 +
3 files changed, 3 insertions(+)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nouveau_gem.c | 5 +++--
lib/include/nvif/os.h | 6 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drm/nouveau/nouveau_gem.c b/drm/n
the remaining failing glsl-1.30/execution/interpolation piglits.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
Incomplete as per above. Wanted to get it out there in case there was
any feedback. This will only work on GK110/GK208 as-is.
.../drivers/nouveau/codegen/nv50_ir_driver.h
e to write frame buffer apps that run in the console.
>
> Thank you.
>
>
>
> On 10/08/2015 04:44 PM, Ilia Mirkin wrote:
>>
>> If you only get 1920x1080 in X, chances are that nouveau doesn't
>> believe it can do 3840x2160 for one reason or another. There are a
If you only get 1920x1080 in X, chances are that nouveau doesn't
believe it can do 3840x2160 for one reason or another. There are a
number of reasons why this might be the case, please provide dmesg,
xorg log, and information on how the monitor is connected (including
any A->B type adapters).
;
> See my comment below.
>
>
> On 10/10/2015 11:09 AM, Ilia Mirkin wrote:
>>
>> We still have to push everything out, might as well kick earlier and
>> flip pushbufs when we know we'll need it. This resolves some issues with
>> the new policy of making sure that we alway
On Sat, Oct 10, 2015 at 3:55 PM, Samuel Pitoiset
<samuel.pitoi...@gmail.com> wrote:
>
>
> On 10/10/2015 09:42 PM, Ilia Mirkin wrote:
>>
>> On Sat, Oct 10, 2015 at 3:41 PM, Samuel Pitoiset
>> <samuel.pitoi...@gmail.com> wrote:
>>>
>>>
: Samuel Pitoiset <samuel.pitoi...@gmail.com>
>
>
> On 10/10/2015 08:12 AM, Ilia Mirkin wrote:
>>
>> Right now we emit on every kick, but this is only necessary if something
>> will ever be able to observe that the fence completed. If there are no
>> refs, leave th
On Sat, Oct 10, 2015 at 4:21 PM, Samuel Pitoiset
<samuel.pitoi...@gmail.com> wrote:
>
>
> On 10/10/2015 09:58 PM, Ilia Mirkin wrote:
>>
>> On Sat, Oct 10, 2015 at 3:55 PM, Samuel Pitoiset
>> <samuel.pitoi...@gmail.com> wrote:
>>>
>>>
>&g
the space checking as well.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/nouveau/nouveau_winsys.h | 2 ++
src/gallium/drivers/nouveau/nv30/nv30_screen.c | 4 +++-
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 +
src/g
We still have to push everything out, might as well kick earlier and
flip pushbufs when we know we'll need it. This resolves some issues with
the new policy of making sure that we always leave a bit of room at the
end for fences.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
Cc: me
after. With the new mechanism,
hopefully there's no way to cause two fences to be emitted into the same
reserved space.
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
Cc: mesa-sta...@lists.freedesktop.org
Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence)
---
src/g
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 contexts
Compiler is wrong.
On Wed, Jul 8, 2015 at 2:27 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
nouveau_compiler.c: In function ‘main’:
nouveau_compiler.c:216:27: warning: ‘code’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
printf(%08x , code[i /
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 Wed, Jul 8, 2015 at 4:04 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
On 25.05.2015 17:07, Ilia Mirkin wrote:
On Mon, May 25, 2015 at 9:40 AM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
On 25.05.2015 07:17, Dave Airlie wrote:
On 25 May 2015 at 08
I don't mind telling people that the compiler is wrong :)
On Wed, Jul 8, 2015 at 3:53 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
On 08.07.2015 21:42, Emil Velikov wrote:
On 8 July 2015 at 20:34, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
Mh i'm not
I suspect the issue is actually that u_debug.h isn't included. It
defines assert to be debug_assert, which in turn is
#define debug_assert(expr) (void)(0 (expr))
which should cause the relevant var to be seen as used.
On Wed, Jul 8, 2015 at 3:40 PM, Tobias Klausmann
If you want glamor, just use modesetting instead.
---
configure.ac | 11 ---
man/nouveau.man | 3 +-
src/Makefile.am | 2 -
src/drmmode_display.c | 7 --
src/nouveau_glamor.c | 253 --
src/nouveau_glamor.h | 33 ---
There is no EXA acceleration, user better off with modesetting.
---
src/nv_driver.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/nv_driver.c b/src/nv_driver.c
index a5ffbce..16a9029 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -389,7 +389,6 @@ NVHasKMS(struct pci_device
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
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,
Fixes the following piglits:
fbo-alphatest-nocolor
fbo-alphatest-nocolor-ff
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: mesa-sta...@lists.freedesktop.org
---
The nv50 bits need testing, only have a GK208 on-hand. Will be sure to test
before pushing.
src/gallium/drivers/nouveau/nv50
On Sat, Nov 14, 2015 at 1:44 PM, Karol Herbst wrote:
> I encountered while stresstesting the reclocking code, that rarely (1 out of
> 20.000+ requests) we don't get any IRQ in nvkm_pmu_intr.
>
> This means we have a queued message on the pmu, but nouveau doesn't read it
>
On Fri, Nov 13, 2015 at 9:25 AM, Emil Velikov wrote:
> Hello Hans,
>
> Not to muddy the waters or anything, have you thought about the NIR
> integration that Rob was thinking about ?
> I'm pretty sure he'll be happy to have extra people helping him out.
How would that
On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 27-08-15 15:46, Marek Olšák wrote:
On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede hdego...@redhat.com
wrote:
Hi All,
While
Hey Ben,
So with the following totally-hack-patch below, I get OF to load (but
I have to force it, checksum fails). Of note is the following:
-r--r--r-- 1 root root 2403 Aug 28 09:31
/proc/device-tree/pci@0,f000/NVDA,Parent@10/NVDA,BMP
I'm not sure why you require the vbios fetches to be
On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 27-08-15 20:19, Ilia Mirkin wrote:
On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher alexdeuc...@gmail.com
wrote:
snip
2) Since the glretrace does work outside of libreoffice impress, I
think
it may have
On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdego...@redhat.com> wrote:
> Hi,
>
>
> On 28-08-15 11:02, Ilia Mirkin wrote:
>>
>> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdego...@redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
&g
Broken since "gr: convert user classes to new-style nvkm_object"
Tested on a PPC64 G5 + NV34
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
drm/nouveau/nvkm/engine/gr/nv04.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drm/nouveau/nvkm/engine/
601 - 700 of 1334 matches
Mail list logo