On Thu, Feb 13, 2014 at 2:15 AM, Kui Zhang wrote:
> Hello,
>
> When CONFIG_DRM_NOUVEAU=y, I get following error. Blank screen after initrd.
>
> This was in the dmesg.
>
> [0.282559] [drm] hdmi device not found 1 0 1
> [0.282688] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x046800a3
> [
It's really confusing for NV_DEBUG's printing to be controlled via
drm.debug while everything else is controlled via nouveau.debug. These
messages can be turned on with nouveau.debug=CLIENT=debug.
Signed-off-by: Ilia Mirkin
---
It's a bit annoying that the DRM messages are con
The hdmi device is required for runtime pm. However it is not available
on many esp older devices, which were all seeing these error messages.
Take this opportunity to also convert to nv_debug instead of the DRM_*
messages, like the rest of nouveau does.
Signed-off-by: Ilia Mirkin
---
drivers
color-mismatched-layer-count.
Signed-off-by: Ilia Mirkin
---
Haven't had a chance to do a full piglit run on this yet, but it does fix the
failing test. Have a look. I'm not sure if zeta can have layers, it seems like
a couple of things assumed it couldn't. I've changed that
It's really confusing for NV_DEBUG's printing to be controlled via
drm.debug while everything else is controlled via nouveau.debug. These
messages can be turned on with nouveau.debug=DRM=debug.
Signed-off-by: Ilia Mirkin
---
Updated version that makes the top-level DRM client have
eported-by: Torsten Wagner
Reported-by: Michael Gulick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67628
Cc: sta...@vger.kernel.org # 3.9+
Signed-off-by: Ilia Mirkin
---
Ben did a quick test that makes it seem like this is the right thing to
do. And it makes sense based on the surrou
color-mismatched-layer-count.
Also fix clears of layered depth/stencils, in case it ever happens.
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- turns out that 3d textures are actually cleared 1 layer at a time, and
their depths might also not match, so handle that case as well.
- ha
Hi Christoph,
bin/shader_runner
tests/spec/glsl-1.40/uniform_buffer/fs-struct-copy-complicated.shader_test
-auto
bin/shader_runner
tests/spec/glsl-1.40/uniform_buffer/vs-struct-copy-complicated.shader_test
-auto
bin/shader_runner
tests/spec/glsl-1.50/uniform_buffer/gs-struct-copy-complicated.shade
Signed-off-by: Ilia Mirkin
---
Statuses derived from envytools, as usual. Not 100% sure about the "any"
thing, but it makes sense...
drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/en
houldn't be too difficult for me to
extend this to categories like, or
maybe even more fine-grained, esp since nvd0 is when a lot of changes
happened. Or maybe less-fine-grained and keep the nvc0/nve0 cards under one
option.
Feedback appreciated.
Not-Signed-off-by: Ilia Mirkin
---
dri
On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin wrote:
> So... I was wondering what the impact of splitting up the card compilation by
> e.g. generation would be. Depending on the split things would get fairly
> intertwined, so I thought I'd start small. This just splits NVC0 from
>
On Fri, Feb 14, 2014 at 9:32 PM, Ilia Mirkin wrote:
> On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin wrote:
>> So... I was wondering what the impact of splitting up the card compilation by
>> e.g. generation would be. Depending on the split things would get fairly
>> intertwi
iled check to explicitly include all pre-nv50 cards.
Reported-by: Ronald
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74613
Signed-off-by: Ilia Mirkin
---
Hmmm... this seems like a really fragile semantic, I wonder if more
mem->mm_node usages have to be audited. But this one's quick and
Having a \n in the middle of a format string means that the next line
doesn't get the prefixes unlike every other line printed by the trace.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --
On Sun, Feb 16, 2014 at 10:17 AM, Rafał Miłecki wrote:
> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
>> (b) bisect. you can (almost) definitely restrict the bisect to
>> drivers/gpu/drm/nouveau. if you have additional computational power, i
>> would recommend looking into distc
On Sun, Feb 16, 2014 at 2:15 PM, Rafał Miłecki wrote:
> 2014-02-16 19:55 GMT+01:00 Ilia Mirkin :
>> On Sun, Feb 16, 2014 at 10:17 AM, Rafał Miłecki wrote:
>>> 2014-02-11 11:41 GMT+01:00 Ilia Mirkin :
>>>> (b) bisect. you can (almost) definitely restrict the bisect t
Signed-off-by: Ilia Mirkin
---
All the arb_texture_cube_map_array piglits pass except the sampler-cube-shadow
one. However, nva0+ appear to all fail at the non-array version of that test,
sampler-cube-shadow, so I think it's very likely to be related. Probably some
sampler setup bits ch
Signed-off-by: Ilia Mirkin
---
This applies on top of Dave Airlie's r600g-texture-gather branch. Ran piglit
with -t gather, passed all 1057 tests. Can't say I fully understand what all
the arguments to handleTEX in the Coverter are but... seems to work. Will
probably require some car
This makes it easy to compare output between different cards, especially
for ones that you don't have (and/or not in the current machine).
Signed-off-by: Ilia Mirkin
---
This currently only works for nv50+, but it'd probably be possible to split
the code paths and introduce nv30/
Signed-off-by: Ilia Mirkin
---
Perhaps there was a day when those were different, but that day is not today.
src/gallium/drivers/nouveau/nv30/nv30_context.c | 1 -
src/gallium/drivers/nouveau/nv30/nv30_context.h | 1 -
src/gallium/drivers/nouveau/nv30/nvfx_fragprog.c | 20
Signed-off-by: Ilia Mirkin
---
Were these things that didn't get quite ported over from the old nvfx? If so,
does it matter? Are they things we need? Even if they are, they can be
implemented in a way that doesn't put that state into nv30_context.
src/gallium/drivers/no
Signed-off-by: Ilia Mirkin
---
I assume this is some left-over from nvfx -> nv30? That flag certainly doesn't
do anything now...
src/gallium/drivers/nouveau/nv30/nv30_context.h | 3 +--
src/gallium/drivers/nouveau/nv30/nv30_fragprog.c | 2 +-
src/gallium/drivers/nouveau/nv30/nvfx_fr
This should pave the way to being able to use the compiler without a
context. Also leads to cleaner code.
Signed-off-by: Ilia Mirkin
---
So... there was a bit of an oops on this patch, I realized that NOUVEAU_ERR
was supplied in silly places and decided to move it to a shared
nouveau_debug
On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman wrote:
> On 9 February 2014 02:57, Ilia Mirkin wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman wrote:
>>> Interestingly, there was graphical failure booting 3.6.11, even
>>> nvidia-current fails to initi
On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman wrote:
> On 9 February 2014 02:57, Ilia Mirkin wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman wrote:
>>> Interestingly, there was graphical failure booting 3.6.11, even
>>> nvidia-current fails to initi
Signed-off-by: Ilia Mirkin
---
Note: this applies on top of airlied's r600g-texture-gather branch.
Appears to pass all 4 piglit tests. The conversion from what the instruction
outputs is the same as what the blob does.
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1 +
.../dr
Hello,
I've recently run into an unknown bit in Tesla shaders, and was hoping
you could shed some light on it. I believe they're related to clamping
of some sort. Here are 2 examples (from diff shaders):
a401 cc054780 cvt rpi f32 $r0 f32 $r2 [unknown: 0001]
a60d 8c014780
On Fri, Feb 28, 2014 at 12:01 PM, Aurélien Rivet
wrote:
> Hello,
> First, my apologies for my rubbish English .
> I come from the archlinux forum, because a user suggested me to ask here my
> question.
> I have the two following lines on boot (and into dmesg) :
>
> [ 13.673400] nouveau E[ DR
Signed-off-by: Ilia Mirkin
---
Tested on nv96 with Chris Forbes's piglit tests (on list, but not checked in
yet)... only assuming about nvc0, but it seems reasonable since all the other
attributes are the same.
docs/GL3.txt| 2 +-
src/gallium/drivers/no
This logic is borrowed from the radeon code. The transfer logic will
only get called for PIPE_BUFFER resources, so it shouldn't be necessary
to worry about them becoming render targets.
Signed-off-by: Ilia Mirkin
---
A user reported a ~30% FPS improvement with an earlier version of this
On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft wrote:
> Hello,
>
> I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
> TV-Out.
http://nouveau.freedesktop.org/wiki/FeatureMatrix/
See note #4 -- nv0x-nv2x (nv17-nv19 excluded) need an external,
third-party manufactured TV encoder. O
Hello,
I've been tracking down a regression in fbo-generatemipmap-formats
with ARB_depth_texture on nouveau (nv50 and nvc0 are affected) since
http://cgit.freedesktop.org/mesa/mesa/commit/?id=0a1479c829ed34a65e60c6619a8164e1b079aaee
FTR, the test I'm running is:
bin/fbo-generatemipmap-formats GL
Signed-off-by: Ilia Mirkin
---
Noticed by inspection, untested. Would be interesting to see if this fixes
anything.
src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++--
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a
On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach wrote:
> On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
>> On Mon, Mar 3, 2014 at 5:41 PM, Nils Krafft wrote:
>> > I have here a GeForce 2MX (NV10) with a Brooktree BT869 chip for the
>> > TV-Out.
On Wed, Mar 5, 2014 at 5:37 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> Noticed by inspection, untested. Would be interesting to see if this fixes
> anything.
I noticed that the nvc0 bit is bogus -- mt->ms_x/y aren't used to
determine ms there (it does
On Wed, Mar 5, 2014 at 2:57 PM, Nils Krafft wrote:
> Hi,
>
> Ilia Mirkin [Mi, 05.03.2014 12:46]:
>> On Wed, Mar 5, 2014 at 6:06 AM, Dirk Thierbach wrote:
>> > On Wed, Mar 05, 2014 at 12:40:34AM -0500, Ilia Mirkin wrote:
>> >> On Mon, Mar 3, 2014 at 5:41 PM
p.org/show_bug.cgi?id=75279
Signed-off-by: Ilia Mirkin
---
Should the waiting be predicated on the current fence having been emitted? I
removed that from nv30 (which would just go ahead and _leak_ that fence it it
hadn't been emitted...). I figure it doesn't really matter enough to worry
about t
This logic is borrowed from the radeon code. The transfer logic will
only get called for PIPE_BUFFER resources, so it shouldn't be necessary
to worry about them becoming render targets.
Signed-off-by: Ilia Mirkin
---
This was re-tested by someone on both nv50 and nvc0. The performance
---
So... this fixes a whole bunch of EXT_framebuffer_multisample tests, and the
ones that still fail appear to do so due to some resolve error, rather than
some "this is the wrong image" type errors. Perhaps it needs a 2d-style "move
coordinates over a sub-texel" logic. But I'm unclear what these
This fixes some unwanted scaling when the output is multisampled. Also
increases nvc0 maximum supported texture size to be able to work with a
32k texture.
Signed-off-by: Ilia Mirkin
Cc: "10.0 10.1"
---
Ran the EXT_framebuffer_multisample tests, they improve a lot. The remaining
fa
On Fri, Mar 7, 2014 at 9:11 AM, Emil Velikov wrote:
> On 06/03/14 04:01, Ilia Mirkin wrote:
>> nouveau_fence_wait has the expectation that an external entity is
>> holding onto the fence being waited on, not that it is merely held onto
>> by the current pointer. Fixe
Information for this was gathered from nvdisasm.
Signed-off-by: Ilia Mirkin
---
Entirely untested. Ben, do you think you'll be able to give this a shot?
.../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 33 +++---
1 file changed, 16 insertions(+), 17 deletions(-)
On Tue, Mar 11, 2014 at 5:57 AM, Ben Skeggs wrote:
> On Tue, Mar 11, 2014 at 7:47 PM, Ilia Mirkin wrote:
>> Information for this was gathered from nvdisasm.
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> Entirely untested. Ben, do you think you'll be a
On Tue, Mar 11, 2014 at 10:46 AM, Daniel Melo Jorge da Cunha
wrote:
> Sorry for the lame question, but is nouveau_device_wrap (...) implemented
> outside Mesa source code? (like libdrm, I don't know...)
>
> Because I searched the whole Mesa-10.0.3 source and found no
> implementation for this func
Signed-off-by: Ilia Mirkin
---
nouveau/nouveau.c | 29 -
nouveau/private.h | 3 ++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index ee7893b..72c31cf 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
On Sun, Mar 9, 2014 at 10:51 AM, Marcin Slusarz
wrote:
> [ 326.168487] ==
> [ 326.168491] [ INFO: possible circular locking dependency detected ]
> [ 326.168496] 3.13.6 #1270 Not tainted
> [ 326.168500] ---
Hello,
A user on an NVC3 card (GF106) is running into data errors on m2mf
(class 0x9039) that we haven't seen before:
http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/glean/fbo.html
http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/spec
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319
Signed-off-by: Ilia Mirkin
---
It's unclear to me whether GF11x devices actually support this, but
the disp "split" is at nvd0, so I went with that. The marketing docs
are fairly unclear. However most of them don't
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319
Signed-off-by: Ilia Mirkin
---
It's unclear to me whether GF11x devices actually support this, but
the disp "split" is at nvd0, so I went with that. The marketing docs
are fairly unclear. However most of them don't
s setups.
Signed-off-by: Ilia Mirkin
Cc: # 3.12+
---
This is as yet untested, but I wanted to send this out to the list
since I think a few people are still running into these annoying
issues.
I don't have access to an actual optimus configuration, so if someone
could give this a shot on suc
On Wed, Mar 19, 2014 at 7:45 PM, David Airlie wrote:
>
>> On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin wrote:
>> > There was a proliferation of duplicated checks for runpm == -1 &&
>> > optimus. Instead of continuing that tradition, get rid of all of them,
>
On Wed, Mar 19, 2014 at 8:08 PM, David Airlie wrote:
>
>
> - Original Message -
>> From: "Ilia Mirkin"
>> To: "David Airlie"
>> Cc: "Ben Skeggs" , "Ben Skeggs" ,
>> nouveau@lists.freedesktop.org
>> Sent: Thu
The nvc0 texfetch instruction expects the sample id to be in the second
source (usually used for the offset) rather than as part of the texture
coordinate.
This fixes all the sampler2DMS/Array tests on nvc0.
Signed-off-by: Ilia Mirkin
Cc: "10.1"
---
Tested on nvc1 with a full pigl
I've been seeing an issue, for a while now, but kept forgetting to
mention it. When I have 2 cards plugged in (and runpm=0), and I run X
on the second card, everything works fine. However, when I shut X
down, the last image remains, and the attached screen never suspends.
I've seen this esp happen
textdata bss dec hex filename
453459 159463 480 613402 95c1a drivers/gpu/drm/nouveau/nouveau.ko
NV04 + NV50 + NVC0: 1343482 bytes
textdata bss dec hex filename
579171 184264 480 763915 ba80b drivers/gpu/drm/nouveau/nouveau.ko
Signed-off-by: Ilia
On Tue, Mar 25, 2014 at 1:57 AM, Alexei Ustyuzhaninov
wrote:
> Hi!
>
> I have a rather decent notebook (Toshiba Satellite P105-S9722) with Nvidia
> GeForce Go 7900 GS video card. I installed latest debian system with kernel
> 3.13-1-amd64 on it, but unfortunately nouveau driver doesn't work. When
On Mon, Mar 24, 2014 at 10:50 PM, William Lewis
wrote:
> I hope I'm writing to people who can help me. If not you, then I have a
> serious inconvenience and am going to be at a complete loss for where to
> turn.
>
> Let me explain my setup. I have an HTPC with a GeForce GT620. It is
> connected
NULL);
for (i = 0; i < 50; i++) {
nouveau_bo_ref(NULL, &bo[i]);
}
nouveau_device_del(&dev);
return 0;
}
On Wed, Mar 12, 2014 at 10:05 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
> nouveau/nouveau.c | 29 -
> nouveau/private.h
On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres wrote:
> Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA,
Maxwell or Kepler?
> let's only use 32-bit accesses to fetch the vbios from PROM.
>
> This fixes vbios fetching on my nve7 which failed in certain specific
> condi
On Tue, Mar 25, 2014 at 6:30 PM, Martin Peres wrote:
> On 25/03/2014 23:24, Ilia Mirkin wrote:
>>
>> On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres
>> wrote:
>>>
>>> Other kind of accesses are unreliable on Maxwell cards. As advised by
>>> NVID
struct nouveau_device_priv *nvdev = calloc(1, sizeof(*nvdev));
calloc sets the entire structure to 0. so that field is implicitly set
to 0 on allocation.
On Wed, Mar 26, 2014 at 4:37 PM, Daniel Melo Jorge da Cunha
wrote:
> Hi, I am inspecting the file nouveau.c...
> In the function nouveau_clien
vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475
Signed-off-by: Ilia Mirkin
Cc: # v2.6.35+
---
Not sure if the stable CC is warranted... it's technically not a
regression. But it's a simple change that enables hardware to work.
Patrick/Claas -- please test th
I believe that ch7006 is the only external encoder that's supposed to
work, so you're in luck. It sounds like it passes the nv04_tv_identify
stage of nv04_tv_create -- perhaps it fails later? Although based on
the prints, it's even doing dpms stuff (but it hits _detect a second
time... odd). Try bo
On Tue, Apr 1, 2014 at 6:30 PM, Roger wrote:
>> On Tue, Apr 01, 2014 at 02:53:02PM -0400, Ilia Mirkin wrote:
>>I believe that ch7006 is the only external encoder that's supposed to
>>work, so you're in luck. It sounds like it passes the nv04_tv_identify
>>sta
On Wed, Apr 2, 2014 at 9:52 AM, Alexandre Courbot wrote:
> On Tue, Mar 25, 2014 at 7:34 AM, Thierry Reding
> wrote:
>> On Mon, Mar 24, 2014 at 05:42:28PM +0900, Alexandre Courbot wrote:
>> [...]
>>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/nvea.c
>>> b/drivers/gpu/drm/nouveau/core/s
On Wed, Apr 2, 2014 at 10:14 AM, Alexandre Courbot wrote:
+ /* Need to figure out how to handle sw for gk20a */
+ if (device->chipset == 0xea)
+ goto skip_sw_init;
>>>
>>> The commit message makes it sound like SW isn't needed since gk20a
>>> "lacks any display h
On Wed, Apr 2, 2014 at 5:24 PM, Roger wrote:
> After analyzing verbose nouveau & drm dmesg, I have found seemingly no more
> useful details pertaining to having no TV-1 device. The TV-1 device might be
> getting lost within DRM, by setting the TV-1 (SVIDEO, Composite) device into
> DPMS mode or F
Signed-off-by: Ilia Mirkin
---
docs/GL3.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index d9cc708..bf51e3a 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -107,7 +107,7 @@ GL 4.0:
GL_ARB_tessellation_shader not
Signed-off-by: Ilia Mirkin
---
Tested on NVE6. Very strange that it seems to use 8 bits for offsets, vs 4
bits used by texelFetch. But this passes the piglit tests.
Will test on a NVCX before checking in, in case it's different
there. (Although that'd be surprising, given the si
On Fri, Apr 4, 2014 at 1:01 PM, Ian Romanick wrote:
> On 04/03/2014 10:35 PM, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin
>> ---
>> docs/GL3.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/docs/GL3.txt b/docs/GL3.txt
&g
close it.
>
> Yours,
> Claas
>
>
> On 27.03.2014 11:54, Patrick Clara wrote:
>> I have tested this patch. I can confirm that now nouveau loads
>> correctly without errors.
>> Thank you
>>
>> 2014-03-27 0:37 GMT+01:00 Ilia Mirkin :
>>> There appear to
On Sun, Apr 6, 2014 at 7:16 PM, ~Stack~ wrote:
> Greetings,
>
> I am resending this as it doesn't appear in the archives and no one
> responded...maybe it got routed to /dev/null or something :-)
>
> I have asked this question the Scientific Linux mailing list (a few
> months ago) and got the sugg
initialized variable, and then overwrote the
> bits that mattered for the opcode it was producing, leaving uninitialized
> data in the unused bits.
Makes sense, thanks so much for looking into it!
>
> I hope that helps,
> - Andy Ritger
>
>
> On Thu, Feb 27, 2014 at 11:37:40PM -080
On Tue, Apr 8, 2014 at 11:40 AM, Thomas Schneider wrote:
> Hello!
>
> I'm using rather old hardware:
> Mainboard (Asus A7N8X)
> AGP (Asus V7700)
>
> manfred@pc1:~$ lspci -v | grep VGA
> 03:00.0 VGA compatible controller: NVIDIA Corporation NV15 [GeForce2
> GTS/Pro] (rev a3) (prog-if 00 [VGA contro
little as you needed one before.
>>
>> With regards to your question, if the system worked before...
>> Yes, the system worked well with Win XP.
> OK, good to know.
> -ilia
>
> Gesendet: Donnerstag, 10. April 2014 um 06:24 Uhr
> Von: "Ilia Mirkin"
> An
On Thu, Apr 10, 2014 at 6:08 PM, ~Stack~ wrote:
>> On 04/06/2014 08:43 PM, Ilia Mirkin wrote:
>>> On Sun, Apr 6, 2014 at 7:16 PM, ~Stack~ wrote:
> [snip]
>>> Can you test with a fresh kernel (e.g. some
>>> distro's livecd) rather than one based on a 5-yea
On Thu, Apr 10, 2014 at 10:59 PM, ~Stack~ wrote:
> On 04/10/2014 05:14 PM, Ilia Mirkin wrote:
>> You might mention what hardware you have (lspci output for the nvidia
>> card... just need the chip name), and what kernels the various distros
>> are using. (I think that Ubun
On Fri, Apr 11, 2014 at 12:36 PM, Clemens Koller wrote:
> Hi, there!
>
> Every once in a while / about once a day I have nouveau for a Quadro NVS
> 290 failing in my
> system from about kernel 3.10...up to now 3.14, so I finally decided to
> report this bug as
> it gets really annoying. After the
uses sampler2DMS to verify it.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nv50/nv50_surface.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_surface.c
b/src/gallium/drivers/nouveau/nv50/nv50_surface.c
index c28abe0
Also rework things so that if someone were to add an opcode without
adjusting the values in these arrays, there will be a compilation error.
This fixes a few quadop-related piglit regressions since commit
d5faf8e78603.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen
On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot wrote:
> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will
bytes or u32's? From the code, I'm guessing the latter. (Similar
concern about comment in the code.)
> fail to run from non-prepadded firmware files.
>
> Signed-off-
On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot wrote:
> Skip the creation of a software channel for GK20A as software methods
> are not yet supported.
How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
the 3D Controller ones, and I guess even some that come up as VGA
contr
Hello,
I've been trying to add ARB_sample_shading support to nouveau, and am
being defeated by the gl_SampleMask tests. Everything else works fine.
(And naturally the tests pass with the proprietary driver.) I'm trying
to do this for both GT21x, as well as GF100+.
In the GT21x case, it seems like
On Wed, Apr 23, 2014 at 6:22 PM, Ilia Mirkin wrote:
> Hello,
>
> I've been trying to add ARB_sample_shading support to nouveau, and am
> being defeated by the gl_SampleMask tests. Everything else works fine.
> (And naturally the tests pass with the proprietary driver.) I'
On Thu, Apr 24, 2014 at 12:11 PM, Nicolas Göddel
wrote:
> Hi there,
>
> a few days ago I installed Ubuntu Gnome 14.04 on my Thinkpad W530. It has
> the
> following specifications:
>
> Intel Core i7-3820QM
> Intel HD 4000 and nVidia Quadro K2000M
> 15,6" FHD RGB 1920x1080
>
> I selected "Optimus" i
On Thu, Apr 24, 2014 at 2:55 PM, Nicolas Göddel
wrote:
> Hi Ilia,
>
> with 'xrandr --output LVDS1 --auto --output VGA-1-2 --auto --left-of LVDS1' it
> seems to work properly. Thank you. Do you know about a tool which integrates
> well in Ubuntu? Maybe a GUI for xrandr? The other option would be to
On Sun, Apr 27, 2014 at 10:41 PM, John Jason Jordan wrote:
> Ubuntu 13.10 x86_64 up to date on laptop with nVidia GeForce GTX 765M.
>
> There were some updates that I applied last week, and ever since I have
> missing text in some menus and lists. It is especially bad in Claws Mail
> and LibreOffi
On Mon, Apr 28, 2014 at 1:33 AM, John Jason Jordan wrote:
> On Sun, 27 Apr 2014 23:01:57 -0400 Ilia Mirkin dijo:
>>On Sun, Apr 27, 2014 at 10:41 PM, John Jason Jordan
>>wrote:
> A couple of weeks ago the Update Manager announced that there were some
> updates. I do no
On Mon, Apr 28, 2014 at 3:14 PM, John Jason Jordan wrote:
> On Mon, 28 Apr 2014 14:07:56 -0400
> Ilia Mirkin dijo:
>
>>On Mon, Apr 28, 2014 at 1:33 AM, John Jason Jordan
>> wrote:
>>> On Sun, 27 Apr 2014 23:01:57 -0400 Ilia Mirkin
>>> dijo:
>>&
This fixes textureGather(2DRect) piglit tests, and does not appear to
have any adverse effects.
Signed-off-by: Ilia Mirkin
---
Not sure why the sampler would care whether it's 2D or 2DRect in the first
place. But I think the only difference between a non-linear RECT texture and a
2D one ar
look and see what I can find out.
>
> Thanks,
> - Andy
>
>
> On Wed, Apr 23, 2014 at 05:03:17PM -0700, Ilia Mirkin wrote:
>> On Wed, Apr 23, 2014 at 6:22 PM, Ilia Mirkin wrote:
>> > Hello,
>> >
>> > I've been trying to add ARB_sample_sh
oss-check with a different one. But the problem is sufficiently
restricted that it seems unlikely to be a bad part, and more likely a
driver bug.
Anyways, now that we know what to look for, it should be much easier
to identify in a command stream dump.
Thanks again,
-ilia
>
> Thanks,
&
Signed-off-by: Ilia Mirkin
---
Light testing with dolphin-emu on a G96, seems to mostly work. Saw one or two
glitches (for like 1 frame), but that could well have been a bug in the emu.
It's a little silly to have all this super-super-repetitive code, but short of
rearranging the driver
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 4 +---
src/gallium/drivers/nouveau/nouveau_context.h | 1 -
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c
b/src/gallium/drivers/nouveau/nouveau_buffer.c
Hello,
There have been some users reporting odd framebuffer and cursor
corruption on GeForce4 Ti 4200 Go cards (yeah, pretty ancient
hardware). These identify as NV28's.
Here is the full bug, with screenshots, descriptions, etc:
https://bugs.freedesktop.org/show_bug.cgi?id=54700
A user has isola
The old condition disallowed load propagation any time flags were
defined, even with e.g. set and a constbuf reference. The new condition
disallows it only with immediate propagation. (There are no opcodes that
set the condition flag and have an immediate argument.)
Signed-off-by: Ilia Mirkin
Should fix SGE/SSG instructions, which were previously getting integer
0/-1 values.
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
b/src
Different textures may be bound to each slot for each stage. So we need
to be able to upload ms parameters for each one without stages
overwriting each other.
Signed-off-by: Ilia Mirkin
Cc: "10.1 10.2"
---
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 4
s
Signed-off-by: Ilia Mirkin
Cc: "10.2 10.1"
---
Found this while tracking a regression on nvc0 for my patch which fixes
ir_unop_any to emit or's instead of dp3's. (That patch is fine, this code was
always broken.)
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 3
Need to adjust coordinates since the shader receives the array index as
depth in z, but the TEX instruction expects it to be the second
coordinate for a 1D array texture. This fixes fbo-generatemipmap-array.
Signed-off-by: Ilia Mirkin
Cc: "10.2"
---
src/gallium/drivers/no
501 - 600 of 1419 matches
Mail list logo
