https://bugs.freedesktop.org/show_bug.cgi?id=90871
--- Comment #14 from Olivier Fourdan ---
(In reply to poma from comment #13)
I am not sure xfwm4 logs will help much here.
What about the test program I posted in comment 11, it does the same as xfwm4
but in a much shorter/simpler code so if yo
This is required on non-coherent architectures to ensure the value of
the fence is correct at all times. Failure to do this results in the
display freezing for a few seconds every now and then on Tegra.
The NOUVEAU_BO_COHERENT is a no-op for coherent architectures, so behavior
on x86 should not be
https://bugs.freedesktop.org/show_bug.cgi?id=91025
--- Comment #5 from anonymissi...@arcor.de ---
Sorry, I only know how to apply git c source code patches onto a git
repository, not a Linux OS.
What I was expecting needing to do is to checkout nouveau's fixed code, build
it and somehow install it
Some GPUs (e.g. GK20A, GM20B) do not embed VRAM of their own and use
the system memory as a backend instead. For such systems, allocating
objects in VRAM results in errors since the kernel will not allow
VRAM objects allocations.
This patch adds a vram_domain member to struct nouveau_screen that c
New revision of this patchset that prevents VRAM objects from being
allocated on VRAM-less systems like Tegra. This is required for Mesa
to work on such systems.
Changes since v2:
- Use vram_size to detect systems without VRAM and set the correct
domain instead of expecting each chip to set its
Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
VRAM domains for chips that do not have dedicated video memory.
Signed-off-by: Alexandre Courbot
---
src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++
src/gallium/drivers/nouveau/nv50/nv50_miptree.c|
Hi,
On 16-06-15 16:02, Ilia Mirkin wrote:
On Tue, Jun 16, 2015 at 5:34 AM, Hans de Goede wrote:
So any hints how to mvoe forward with this are appreciated.
I can only say what I would do... forget about trying to quantify
which cases work and which don't, just take the case that you can
reli
p.s.
I'm starting to think that it may eb best to just disable
vblank for nv46 hardware in the ddx and be done with it,
any opinions on this ?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
On 19/06/2015 13:02, Alexandre Courbot wrote:
New revision of this patchset that prevents VRAM objects from being
allocated on VRAM-less systems like Tegra. This is required for Mesa
to work on such systems.
Changes since v2:
- Use vram_size to detect systems without VRAM and set the correct
On 19 June 2015 at 21:51, Martin Peres wrote:
> On 19/06/2015 13:02, Alexandre Courbot wrote:
>>
>> New revision of this patchset that prevents VRAM objects from being
>> allocated on VRAM-less systems like Tegra. This is required for Mesa
>> to work on such systems.
>>
>> Changes since v2:
>> - U
On Fri, Jun 19, 2015 at 6:02 AM, Alexandre Courbot wrote:
> Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
> VRAM domains for chips that do not have dedicated video memory.
>
> Signed-off-by: Alexandre Courbot
> ---
> src/gallium/drivers/nouveau/nouveau_buffer.c
https://bugs.freedesktop.org/show_bug.cgi?id=91025
--- Comment #6 from Ilia Mirkin ---
(In reply to anonymissimus from comment #5)
> Sorry, I only know how to apply git c source code patches onto a git
> repository, not a Linux OS.
What is linux, but a git repository :) Anyways, if you're not co
This is going to be very useful for GF100+ because each GPC can
have its own domain of counters.
Signed-off-by: Samuel Pitoiset
---
drm/nouveau/include/nvif/class.h | 1 +
drm/nouveau/nvkm/engine/pm/base.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drm/nouveau/include/nvif/class.h b/
This trivial patch makes thing more consistent since hardware signals
names are prefixed by 'pcXX'.
Signed-off-by: Samuel Pitoiset
---
drm/nouveau/nvkm/engine/pm/nv40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drm/nouveau/nvkm/engine/pm/nv40.c
b/drm/nouveau/nvkm/engin
gk104_pm_ctor() is equal to gf100_pm_ctor().
Signed-off-by: Samuel Pitoiset
---
drm/nouveau/include/nvkm/engine/pm.h | 2 +-
drm/nouveau/nvkm/engine/device/gk104.c | 8 ++---
drm/nouveau/nvkm/engine/pm/gk104.c | 60 +-
3 files changed, 14 insertions(+), 56
These signals and sources have been reverse engineered from CUPTI
(Linux). Graphics signals exposed by PerfKit (Windows only) will be
added later. I need to reverse engineer them and it's a bit painful.
Signed-off-by: Samuel Pitoiset
---
drm/nouveau/nvkm/engine/pm/gf100.h | 1 +
drm/nouveau/nvk
On Fri, Jun 19, 2015 at 9:38 PM, Ben Skeggs wrote:
> On 19 June 2015 at 21:51, Martin Peres wrote:
>> On 19/06/2015 13:02, Alexandre Courbot wrote:
>>>
>>> New revision of this patchset that prevents VRAM objects from being
>>> allocated on VRAM-less systems like Tegra. This is required for Mesa
On Fri, Jun 19, 2015 at 10:55 PM, Ilia Mirkin wrote:
> On Fri, Jun 19, 2015 at 6:02 AM, Alexandre Courbot
> wrote:
>> Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative
>> VRAM domains for chips that do not have dedicated video memory.
>>
>> Signed-off-by: Alexandre Courbot
https://bugs.freedesktop.org/show_bug.cgi?id=91025
--- Comment #7 from Ilia Mirkin ---
Created attachment 116600
--> https://bugs.freedesktop.org/attachment.cgi?id=116600&action=edit
"fixed" vbios
OK, so I've manually touched up the vbios. I had to do one slightly dodgy
thing, but... it should
https://bugs.freedesktop.org/show_bug.cgi?id=90871
--- Comment #15 from poma ---
(In reply to Olivier Fourdan from comment #14)
> (In reply to poma from comment #13)
>
> I am not sure xfwm4 logs will help much here.
>
> What about the test program I posted in comment 11, it does the same as
> x
https://bugs.freedesktop.org/show_bug.cgi?id=91025
--- Comment #8 from anonymissi...@arcor.de ---
Created attachment 116602
--> https://bugs.freedesktop.org/attachment.cgi?id=116602&action=edit
dmesg > kernel_log.txt with kernel boot parameters log_buf_len=1M
nouveau.config=NvBios=vbios-bug-9102
https://bugs.freedesktop.org/show_bug.cgi?id=91025
--- Comment #9 from Ilia Mirkin ---
(In reply to anonymissimus from comment #8)
> Created attachment 116602 [details]
> dmesg > kernel_log.txt with kernel boot parameters log_buf_len=1M
> nouveau.config=NvBios=vbios-bug-91025-fixed.rom
Seems hap
https://bugs.freedesktop.org/show_bug.cgi?id=91025
--- Comment #10 from anonymissi...@arcor.de ---
I'm kind of used to building applications such as envytools, but a kernel is
likely too much (for the CPU/RAM especially).
Yes, thanks a lot, much better. nouveau is in use according to lspci and I
23 matches
Mail list logo
