[Nouveau] [Bug 88890] [nve7] Reclocking of core speed fails on non-reference ASUS GeForce GTX650
https://bugs.freedesktop.org/show_bug.cgi?id=88890 --- Comment #2 from Karol Herbst freedesk...@karolherbst.de --- do you get errors like [10913.271270] nouveau E[ CLK][:01:00.0] failed to raise voltage: -22 [10913.271273] nouveau E[ CLK][:01:00.0] error setting pstate 1: -22 after trying? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] CUDA fixed VA allocations and sparse mappings
responding to this bit of text from ben below: I guess you can probably use the start of the kernel's address space carveout for these kind of mappings actually? It's not like userspace can ever have virtual addresses there? one of the salient points of how we implement gr and compute setup is that these buffer regions (shared, global, any but for a hole 0-128MB) are allocated dynamically. an address space can be setup well in advance and as long as the gr/compute engine setup buffer allocator is playing along (i.e honoring the previously allocated regions) things work out just fine. the term we use internally is anonymous address spaces. unbound, unused as yet. now, as for how the gpu and cpu address ranges work/or don't: that's up to the user space code to work through. the cuda guys have various techniques to make it unified (some work in 64b only, some both, and almost all require specific API conditions). but, as long as we can have them tell the kernel what gpu ranges to avoid (by allocating them in advance) it's up to that code to fulfill the cpu portion. --- ken On 7/7/15, 8:18 PM, Nouveau on behalf of Ben Skeggs nouveau-boun...@lists.freedesktop.org on behalf of skeg...@gmail.com wrote: 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 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, 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 should potential conflicts with user mappings be handled? As an initial implemetation you can probably assume that the GPU offloading is in exclusive mode. Basically that the CUDA or OpenACC code has full ownership of the card. The Tesla cards don't even have a video out on them. To complicate this even more - some offloading code has very long running kernels and even worse - may critically depend on using the full available GPU ram. (Large matrix sizes and soon big Fortran arrays or complex data types) This doesn't change that, to setup the graphics engine, the driver needs to map various system-use data structures into the channel's address space *somewhere* :) I'm not sure I follow exactly what you mean, but I think the answer is - don't setup the graphics engine if you're in compute mode. Doing that, iiuc, will at least provide a start to support for compute. Anyone who argues that graphics+compute is critical to have working at the same time is probably a 1%. On NVIDIA GPUs, compute _is_ part of the graphics engine... aka PGRAPH. You can afaik setup PGRAPH without mapping memory for graphics. You just init the engine and get out of the way. But... you need to map memory to set up the engine. Not a lot, but it's gotta go *somewhere*. 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 space carveout for these kind of mappings actually? It's not like userspace can ever have virtual addresses there? Ben. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau/compiler: fix trivial compiler warnings
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 / 4]);
^
nouveau_compiler.c:215:4: warning: ‘size’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
for (i = 0; i size; i += 4) {
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/drivers/nouveau/nouveau_compiler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_compiler.c
b/src/gallium/drivers/nouveau/nouveau_compiler.c
index 8660498..ca128b5 100644
--- a/src/gallium/drivers/nouveau/nouveau_compiler.c
+++ b/src/gallium/drivers/nouveau/nouveau_compiler.c
@@ -144,7 +144,7 @@ main(int argc, char *argv[])
const char *filename = NULL;
FILE *f;
char text[65536] = {0};
- unsigned size, *code;
+ unsigned size = 0, *code = NULL;
for (i = 1; i argc; i++) {
if (!strcmp(argv[i], -a))
--
2.4.5
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90513] Odd gray and red flicker in The Talos Principle on GK104
https://bugs.freedesktop.org/show_bug.cgi?id=90513 --- Comment #4 from Gediminas Jakutis gedimi...@varciai.lt --- (In reply to Karol Herbst from comment #3) does enabling No Dynamic Lightning helps with the issue even on very high gpu settings Like Ultra? Its a customize options for the gpu speed. Oh my, yes it does. I suppose that means the dynamic lighting is responsible for it. Hmmm... previously[1], dynamic lighting used to crash the game at certain locations, but would not create any visual problems. This particular flickering started appearing after some change[2] that made the game to NOT crash anymore. I'm going to ping the game's developers and ask them to look into this particular report. Maybe by knowing their engine's internals, they can toss some [valuable] insight. [1] While the game was still in closed beta [2] Not sure if a change to the game, to Mesa or both. As far as I can recall, probably both. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/2] nouveau/compiler: fix trivial compiler warnings
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 / 4]);
^
nouveau_compiler.c:215:4: warning: ‘size’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
for (i = 0; i size; i += 4) {
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/drivers/nouveau/nouveau_compiler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_compiler.c
b/src/gallium/drivers/nouveau/nouveau_compiler.c
index 8660498..ca128b5 100644
--- a/src/gallium/drivers/nouveau/nouveau_compiler.c
+++ b/src/gallium/drivers/nouveau/nouveau_compiler.c
@@ -144,7 +144,7 @@ main(int argc, char *argv[])
const char *filename = NULL;
FILE *f;
char text[65536] = {0};
- unsigned size, *code;
+ unsigned size = 0, *code = NULL;
for (i = 1; i argc; i++) {
if (!strcmp(argv[i], -a))
--
2.4.5
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/2] nv50/ir: fix a compiler warning with debug-only code
codegen/nv50_ir_emit_nv50.cpp: In member function
‘void nv50_ir::CodeEmitterNV50::emitLOAD(const nv50_ir::Instruction*)’:
codegen/nv50_ir_emit_nv50.cpp:620:12: warning: unused variable ‘offset’
[-Wunused-variable]
int32_t offset = i-getSrc(0)-reg.data.offset;
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index 67ea6df..86b16f2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -616,8 +616,11 @@ CodeEmitterNV50::emitLoadStoreSizeCS(DataType ty)
void
CodeEmitterNV50::emitLOAD(const Instruction *i)
{
- DataFile sf = i-src(0).getFile();
+#ifdef DEBUG
int32_t offset = i-getSrc(0)-reg.data.offset;
+#endif
+
+ DataFile sf = i-src(0).getFile();
switch (sf) {
case FILE_SHADER_INPUT:
--
2.4.5
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau/compiler: fix trivial compiler warnings
On 8 July 2015 at 20:34, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: Mh i'm not aware of me ever changed the nouveau_compiler. But i'm happy to see this made you laugh, so it has something positive at least... :/ Story time: This particular compiler warning has been brought up (incl here) four or five times. Each time, Ilia feels reluctant about the fix as the (gcc) compiler gets it wrong. Personally I do not see a problem with explicitly initialising the variable at this instance, yet I'm curious for how long Ilia will say no to this (type of) patch(es) :-P No offence, I just find it funny. Emil ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH 00/11] Implement ARB_cull_distance
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:11, Marek Olšák mar...@gmail.com wrote: It's the same on Radeon. There are 2x ClipOrCullDistance output vectors and a mask saying it should clip or cull or do nothing. Marek My thinking was gallium should have a single semantic and a mask in the shader definition maybe. though it doesn't solve the does nvidia do the right thing with cull[0] and clip[0], and what is the right thing. Dave. I'm still convinced that both clip[0] and cull[0] should be possible. Plus i have written a shader_test for this a while ago which you pushed to piglit (fs-cull-and-clip-distance-different.shader_test). If i remember right nvidia passed that test just fine. My take (and note that I last read the extension many months ago) is that you're supposed to figure out the max gl_ClipDistance[] written, and then write all your cull distances above that. So if you, e.g., have something like gl_ClipDistance[5] = 1; gl_CullDistance[0] = 1; Then it would decide that there are 6 clip distances (or if there's an explicit out float gl_ClipDistance[n], then use that), and 1 cull distance. In the TGSI, I'm thinking this might look approximately like PROPERTY CULL_MASK (16) DCL OUT[0], CLIPDIST[0] DCL OUT[1], CLIPDIST[1] MOV OUT[1].y, 1 (clip distance[5]) MOV OUT[1].z, 1 (cull distance[0]) Then basically you'd have (rast-clip_enable shader-actual_clip_writes_mask) | cull_mask = the enabled distances cull_mask = cull mask This would work *very* well for nouveau, not sure how suitable it is for other hardware. Cheers, -ilia I wonder where this step should be implemented after all. It was brought up that llvmpipe already supports cull_distance (it does!), so maybe we should implement this in the drivers to evade llvmpipe breakage. Any suggestions appreciated :) Tobias I believe that the later feedback from Brian was that my approach was a bad one and we should use CULLDIST instead, which also reflects how GL has it. However it's important to specify *somewhere* how many clip distances are used since it all gets lowered into the 2x vec4. It might be annoying to derive it from writes to CLIPDIST[0/1].xyzw dest masks. Although nouveau might already do that anyways... -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau/compiler: fix trivial compiler warnings
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 aware of me ever changed the nouveau_compiler. But i'm happy to see this made you laugh, so it has something positive at least... :/ Story time: This particular compiler warning has been brought up (incl here) four or five times. Each time, Ilia feels reluctant about the fix as the (gcc) compiler gets it wrong. Personally I do not see a problem with explicitly initialising the variable at this instance, yet I'm curious for how long Ilia will say no to this (type of) patch(es) :-P No offence, I just find it funny. Emil Oh i did even answer in a thread for a patch from Martin where he propose the same change (even with the same prefix :D). Ilia maybe you should take this after all, as it seems you are haunted by this :P ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau/compiler: fix trivial compiler warnings
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 aware of me ever changed the nouveau_compiler. But i'm happy to see this made you laugh, so it has something positive at least... :/ Story time: This particular compiler warning has been brought up (incl here) four or five times. Each time, Ilia feels reluctant about the fix as the (gcc) compiler gets it wrong. Personally I do not see a problem with explicitly initialising the variable at this instance, yet I'm curious for how long Ilia will say no to this (type of) patch(es) :-P No offence, I just find it funny. Emil Oh i did even answer in a thread for a patch from Martin where he propose the same change (even with the same prefix :D). Ilia maybe you should take this after all, as it seems you are haunted by this :P ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH 00/11] Implement ARB_cull_distance
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:11, Marek Olšák mar...@gmail.com wrote: It's the same on Radeon. There are 2x ClipOrCullDistance output vectors and a mask saying it should clip or cull or do nothing. Marek My thinking was gallium should have a single semantic and a mask in the shader definition maybe. though it doesn't solve the does nvidia do the right thing with cull[0] and clip[0], and what is the right thing. Dave. I'm still convinced that both clip[0] and cull[0] should be possible. Plus i have written a shader_test for this a while ago which you pushed to piglit (fs-cull-and-clip-distance-different.shader_test). If i remember right nvidia passed that test just fine. My take (and note that I last read the extension many months ago) is that you're supposed to figure out the max gl_ClipDistance[] written, and then write all your cull distances above that. So if you, e.g., have something like gl_ClipDistance[5] = 1; gl_CullDistance[0] = 1; Then it would decide that there are 6 clip distances (or if there's an explicit out float gl_ClipDistance[n], then use that), and 1 cull distance. In the TGSI, I'm thinking this might look approximately like PROPERTY CULL_MASK (16) DCL OUT[0], CLIPDIST[0] DCL OUT[1], CLIPDIST[1] MOV OUT[1].y, 1 (clip distance[5]) MOV OUT[1].z, 1 (cull distance[0]) Then basically you'd have (rast-clip_enable shader-actual_clip_writes_mask) | cull_mask = the enabled distances cull_mask = cull mask This would work *very* well for nouveau, not sure how suitable it is for other hardware. Cheers, -ilia I wonder where this step should be implemented after all. It was brought up that llvmpipe already supports cull_distance (it does!), so maybe we should implement this in the drivers to evade llvmpipe breakage. Any suggestions appreciated :) Tobias ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/2] nv50/ir: fix a compiler warning with debug-only code
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
tobias.johannes.klausm...@mni.thm.de wrote:
On 08.07.2015 21:34, Emil Velikov wrote:
On 8 July 2015 at 19:27, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
codegen/nv50_ir_emit_nv50.cpp: In member function
‘void nv50_ir::CodeEmitterNV50::emitLOAD(const nv50_ir::Instruction*)’:
codegen/nv50_ir_emit_nv50.cpp:620:12: warning: unused variable ‘offset’
[-Wunused-variable]
int32_t offset = i-getSrc(0)-reg.data.offset;
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index 67ea6df..86b16f2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -616,8 +616,11 @@ CodeEmitterNV50::emitLoadStoreSizeCS(DataType ty)
void
CodeEmitterNV50::emitLOAD(const Instruction *i)
{
- DataFile sf = i-src(0).getFile();
+#ifdef DEBUG
int32_t offset = i-getSrc(0)-reg.data.offset;
+#endif
+
assert is (normally) guarded by NDEBUG. Mesa/gallium has an in-house
replacement, which (not 100% sure) should be fine as well.
-Emil
As far as i can see it in u_debug.h assert (debug_assert) is guarded by
DEBUG as the above change...
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] CUDA fixed VA allocations and sparse mappings
On Wed, Jul 08, 2015 at 10:51:55AM +1000, Ben Skeggs wrote: On 8 July 2015 at 10:47, Andrew Chew ac...@nvidia.com wrote: 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 are pushbuffers, which are needed to submit stuff to any engine. I guess you can probably use the start of the kernel's address space carveout for these kind of mappings actually? It's not like userspace can ever have virtual addresses there? Yeah. I'm looking into it further, but to answer your original question, I believe there is essentially an address range that nouveau would know about, which it uses for fixed address allocations (I'm referring to how the nvgpu driver does things...we may or may not come up with something different for nouveau). Although it's dangerous, AFAIK the allocator in nouveau starts allocating addresses at page 1, and as you suggested, one wouldn't ever get a CPU address that low. But having a set of addresses reserved would be much better of course. I'm thinking more about the top of the address space. As I understand it, the kernel already splits the CPU virtual address space into user/system areas (3GiB/1GiB for 32-bit IIUC), or something very similar to that. Perhaps, if we can get at that information, we can use those same definitions for GPU address space? Ah, I get what you're saying. Sure, I think that might be okay. Not sure how we would get at that information, though, and it would be horrible to just bake it in somewhere. I'm looking into how nvgpu driver does it... maybe they have good reasons to do it the way they do. Sorry if I go quiet for a little bit... After a very quick look, it looks like the kernel defines a PAGE_OFFSET macro which is the start of kernel virtual address space. You need to be carefull here, first the hardware might not have as many bit as the CPU. For instance x86-64 have a 48bits for virtual address ie only 48bits of the address is meaning full, older radeon (CI iirc) only have 40bits for the address bus. With such configuration you could not move all private kernel allocation inside the kernel zone. Second issue is thing like 32bit process on 64bit kernel, in which case you have the usual 3GB userspace, 1GB kernel space split. So instead of using PAGE_OFFSET you might want to use TASK_SIZE which is a macro that will lookup the limit using the current (process struct pointer). I think issue for nouveau is that kernel space already handle some allocation of virtual address, while for radeon the whole virtual address space is fully under the userspace control. Given this, you might want to use trick on both side (kernel and user space). For instance you could mmap a region with PROT_NONE to reserve a range of virtual address from userspace, then tell the driver about that range and have the driver initialize the GPU and use that chunk for kernel private structure allocation. Issue is that it is kind of a API violation for nouveau kernel driver. Thought i am not familiar enough, maybe you can do ioctl to nouveau before nouveau inialize and allocate the kernel private buffer (gr and other stuff). If so then problem solve i guess. Process that want to use CUDA will need to do the mmap dance and early ioctl. Hope this helps, cheers Jérôme ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/2] nv50/ir: fix a compiler warning with debug-only code
On 08.07.2015 21:34, Emil Velikov wrote:
On 8 July 2015 at 19:27, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
codegen/nv50_ir_emit_nv50.cpp: In member function
‘void nv50_ir::CodeEmitterNV50::emitLOAD(const nv50_ir::Instruction*)’:
codegen/nv50_ir_emit_nv50.cpp:620:12: warning: unused variable ‘offset’
[-Wunused-variable]
int32_t offset = i-getSrc(0)-reg.data.offset;
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
index 67ea6df..86b16f2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp
@@ -616,8 +616,11 @@ CodeEmitterNV50::emitLoadStoreSizeCS(DataType ty)
void
CodeEmitterNV50::emitLOAD(const Instruction *i)
{
- DataFile sf = i-src(0).getFile();
+#ifdef DEBUG
int32_t offset = i-getSrc(0)-reg.data.offset;
+#endif
+
assert is (normally) guarded by NDEBUG. Mesa/gallium has an in-house
replacement, which (not 100% sure) should be fine as well.
-Emil
As far as i can see it in u_debug.h assert (debug_assert) is guarded by
DEBUG as the above change...
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nouveau/ttm: fix tiled system memory with Maxwell
Add Maxwell to the switch statement that sets node-memtype, otherwise
all tiling information is ignored for buffers in system memory.
While we are at it, make that switch statement explicitly complain the
next time we meet a non-handled card family.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
drm/nouveau/nouveau_ttm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drm/nouveau/nouveau_ttm.c b/drm/nouveau/nouveau_ttm.c
index 18f449715788..69bec1058039 100644
--- a/drm/nouveau/nouveau_ttm.c
+++ b/drm/nouveau/nouveau_ttm.c
@@ -175,15 +175,24 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
node-page_shift = 12;
switch (drm-device.info.family) {
+ case NV_DEVICE_INFO_V0_TNT:
+ case NV_DEVICE_INFO_V0_CELSIUS:
+ case NV_DEVICE_INFO_V0_KELVIN:
+ case NV_DEVICE_INFO_V0_RANKINE:
+ case NV_DEVICE_INFO_V0_CURIE:
+ break;
case NV_DEVICE_INFO_V0_TESLA:
if (drm-device.info.chipset != 0x50)
node-memtype = (nvbo-tile_flags 0x7f00) 8;
break;
case NV_DEVICE_INFO_V0_FERMI:
case NV_DEVICE_INFO_V0_KEPLER:
+ case NV_DEVICE_INFO_V0_MAXWELL:
node-memtype = (nvbo-tile_flags 0xff00) 8;
break;
default:
+ NV_WARN(drm, %s: unhandled family type %x\n,
+ drm-device.info.family);
break;
}
--
2.4.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] RFC: drop glamor from nouveau ddx
On 07.07.2015 23:05, Ben Skeggs 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, and probably lots of other issues. While this could probably be fixed somehow, I doubt there's any advantage to using the nouveau DDX over something like modesetting nowadays. How would you feel about dropping glamor support from the nouveau ddx and failing to load for GPUs that don't have EXA support (unless AccelMode = none is forced for them). That way it'll fall back to loading modesetting which should be properly set up for DRI2 and so on. I have no objections to this. In fact, in Fedora at least (I floated the idea in #nouveau a while back too), in the near future I plan on having the DDX fail to load on all GPUs where modesetting+glamor can be used (unless overridden by a config option). Shouldn't the priority always be what is proven to work. NV50 works OK with the EXA. Besides, can it be set color vibrance, vibrant hue and other props via modeset? When people get hit by sunstroke, a real summer has begun. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90513] Odd gray and red flicker in The Talos Principle on GK104
https://bugs.freedesktop.org/show_bug.cgi?id=90513 --- Comment #5 from Ilia Mirkin imir...@alum.mit.edu --- I've made no progress on this bug BTW; perhaps an avenue would be to generate a super-low-resolution trace (i.e. minimum supported by the game... 320x200 or 640x480 or something) so that it plays back faster, and with the minimum number of features enabled to make the problem happen. Basically right now every run through glretrace is a minute or longer, which is too painful to analyze the draws. And I think I gave up waiting for llvmpipe. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nouveau/compiler: fix trivial compiler warnings
On 08.07.2015 20:38, Ilia Mirkin wrote:
Compiler is wrong.
So just nouveau: ... then? Anyway, change it to your liking.
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 / 4]);
^
nouveau_compiler.c:215:4: warning: ‘size’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
for (i = 0; i size; i += 4) {
Signed-off-by: Tobias Klausmann tobias.johannes.klausm...@mni.thm.de
---
src/gallium/drivers/nouveau/nouveau_compiler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_compiler.c
b/src/gallium/drivers/nouveau/nouveau_compiler.c
index 8660498..ca128b5 100644
--- a/src/gallium/drivers/nouveau/nouveau_compiler.c
+++ b/src/gallium/drivers/nouveau/nouveau_compiler.c
@@ -144,7 +144,7 @@ main(int argc, char *argv[])
const char *filename = NULL;
FILE *f;
char text[65536] = {0};
- unsigned size, *code;
+ unsigned size = 0, *code = NULL;
for (i = 1; i argc; i++) {
if (!strcmp(argv[i], -a))
--
2.4.5
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
