Re: [Nouveau] [PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized
Samuel Pitoiset <samuel.pitoi...@gmail.com> writes:
> On 03/14/2016 02:29 PM, Samuel Pitoiset wrote:
>>
>>
>> On 03/14/2016 02:26 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 14-03-16 14:01, Samuel Pitoiset wrote:
>>>>
>>>>
>>>> On 03/14/2016 01:50 PM, Hans de Goede wrote:
>>>>> After pipe_grid_info.indirect was introduced, clover was not modified
>>>>> to set it causing it to pass uninitialized memory for it to
>>>>> launch_grid.
>>>>>
>>>>> This commit fixes this by zero-ing the entire pipe_grid_info struct
>>>>> when
>>>>> declaring it, to avoid similar problems popping-up in the future.
>>>>>
>>>>> Signed-off-by: Hans de Goede <hdego...@redhat.com>
>>>>> ---
>>>>> src/gallium/state_trackers/clover/core/kernel.cpp | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/gallium/state_trackers/clover/core/kernel.cpp
>>>>> b/src/gallium/state_trackers/clover/core/kernel.cpp
>>>>> index 8396be9..dad66aa 100644
>>>>> --- a/src/gallium/state_trackers/clover/core/kernel.cpp
>>>>> +++ b/src/gallium/state_trackers/clover/core/kernel.cpp
>>>>> @@ -55,7 +55,7 @@ kernel::launch(command_queue ,
>>>>> const auto reduced_grid_size =
>>>>> map(divides(), grid_size, block_size);
>>>>> void *st = exec.bind(, grid_offset);
>>>>> - struct pipe_grid_info info;
>>>>> + struct pipe_grid_info info = { 0, };
>>>>
>>>> Right, good catch, it's my fault.
>>>>
>>>> = { 0 }; is enough btw.
>>>
>>> I prefer to add the "," to make clear that we are initializing the
>>> entire struct,
>>> I read it as ", ...".
>>
>> Well, usually we use { 0 } in mesa, try to grep and you will see. :-)
>> There is only 3 occurrences of { 0, }, but I think they are quite old.
>
> Of course, I'm not really against this ",", but I just want consistency
> with the other parts.
>
In C++ '{}' is standard, more concise, and works for a wider range of
types regardless of their layout ('{ 0 }' is valid or not depending on
what the first member of the struct is, while '{}' works regardless, in
C++11 it can even be used to initialize non-POD types with custom
constructors), so it should be generally preferred instead.
Don't bother to resend just because of my nitpicking, I'll fix it up
before I push the last revision of your change, which is:
Reviewed-by: Francisco Jerez <curroje...@riseup.net>
>>
>>>
>>>> This should be backported to mesa 11.2 I guess, could you please send
>>>> a v2 with this minor fix and add the cc thing?
>>>
>>> Sure, as soon as we're done bikeshedding on the "," :)
>>>
>>> Regards,
>>>
>>> Hans
>>
>
> --
> -Samuel
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: fix glCompressedTexImage
Ilia Mirkin imir...@alum.mit.edu writes:
mesa_texstore expects pixel data, not compressed data. For compressed
textures, we want to just copy the bits in without any conversion.
Any reason we cannot use _mesa_store_compressed_*image for this instead
of rolling our own?
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 65
--
1 file changed, 52 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
index 4626cc3..dc5699c 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
@@ -413,6 +413,31 @@ get_teximage_placement(struct gl_texture_image *ti)
}
static void
+nouveau_compressed_copy(struct gl_context *ctx, GLint dims,
+ struct gl_texture_image *ti,
+ GLsizei width, GLsizei height, GLsizei depth,
+ const GLvoid *src, GLvoid *dst, int row_stride)
+{
+ struct compressed_pixelstore store;
+ int i;
+
+ _mesa_compute_compressed_pixelstore(dims, ti-TexFormat,
+ width, height, depth,
+ ctx-Unpack, store);
+
+ src += store.SkipBytes;
+
+ assert(store.CopySlices == 1);
+
+ /* copy rows of blocks */
+ for (i = 0; i store.CopyRowsPerSlice; i++) {
+ memcpy(dst, src, store.CopyBytesPerRow);
+ dst += row_stride;
+ src += store.TotalBytesPerRow;
+ }
+}
+
+static void
nouveau_teximage(struct gl_context *ctx, GLint dims,
struct gl_texture_image *ti,
GLsizei imageSize,
@@ -451,13 +476,19 @@ nouveau_teximage(struct gl_context *ctx, GLint dims,
GL_MAP_WRITE_BIT,
map, row_stride);
- ret = _mesa_texstore(ctx, dims, ti-_BaseFormat,
- ti-TexFormat,
- row_stride,
- map,
- ti-Width, ti-Height, depth,
- format, type, pixels, packing);
- assert(ret);
+ if (compressed) {
+ nouveau_compressed_copy(ctx, dims, ti,
+ ti-Width, ti-Height, depth,
+ pixels, map, row_stride);
+ } else {
+ ret = _mesa_texstore(ctx, dims, ti-_BaseFormat,
+ ti-TexFormat,
+ row_stride,
+ map,
+ ti-Width, ti-Height, depth,
+ format, type, pixels, packing);
+ assert(ret);
+ }
nouveau_unmap_texture_image(ctx, ti, 0);
_mesa_unmap_teximage_pbo(ctx, packing);
@@ -502,7 +533,8 @@ static GLboolean
nouveau_teximage_alloc(struct gl_context *ctx, struct gl_texture_image *ti)
{
nouveau_teximage(ctx, 3, ti, 0, 0, 0, NULL,
- ctx-DefaultPacking, GL_FALSE);
+ ctx-DefaultPacking,
+ _mesa_is_format_compressed(ti-TexFormat));
return GL_TRUE;
}
@@ -535,11 +567,18 @@ nouveau_texsubimage(struct gl_context *ctx, GLint dims,
xoffset, yoffset, width, height,
GL_MAP_WRITE_BIT, map, row_stride);
- ret = _mesa_texstore(ctx, dims, ti-_BaseFormat, ti-TexFormat,
- row_stride, map,
- width, height, depth,
- format, type, pixels, packing);
- assert(ret);
+ if (compressed) {
+ nouveau_compressed_copy(ctx, dims, ti,
+ width, height, depth,
+ pixels, map, row_stride);
+ } else {
+ ret = _mesa_texstore(ctx, dims, ti-_BaseFormat,
+ ti-TexFormat,
+ row_stride, map,
+ width, height, depth,
+ format, type, pixels, packing);
+ assert(ret);
+ }
nouveau_unmap_texture_image(ctx, ti, 0);
_mesa_unmap_teximage_pbo(ctx, packing);
--
1.8.5.5
pgpqBzt8Dmi57.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
Re: [Nouveau] TV-Out on a GeForce 2MX supported?
Dirk Thierbach dthierb...@gmx.de writes: [...] The stuff about overscan/etc are exposed as KMS properties (which in turn appear in xrandr) and not specific to the BT869. The problem is that there's no good way to just say I want this overscan and then get a valid set of register values, because of the timing constraints. Nvtv includes a sort of calculator that tries to calculate a collection of sets of sensible values as close to a desired overscan as possible, but you still have to check (and tweak, if necessary) every of those sets to see if it actually works. It's been quite a while since the last time I messed about with this code, but the TV encoders we already support (chrontel and nvidia's) have similar limitations, and IIRC we solve it by doing two different things: 1. We don't actually set the exact mode passed by the user. Instead, the mode (both the CRTC mode and the final output mode) can be adjusted to the closest supported mode compatible with the hardware, given the specified properties. 2. For some properties (e.g. the TV standard) where making small adjustments to the virtual mode exposed to the user wouldn't work, (e.g. because the changes would involve changing the display width/height), we change the list of supported modes which is returned to userspace in response to a property change. The i2c driver is supposed to expose a -mode_set() function, which takes a drm_display_mode. We had this discussion on the xorg mailing list back then, I think even before there was kernel mode setting. In short, xrandr properties and X-style modelines are just not enough to be able to program the BT/CX chip sensibly. You need a different infrastructure. As I said, as a workaround one can use a number of predefined modes baked into the kernel. That's better than no support at all, but not as good as being able to program the BT/CX chip freely. The current model doesn't require the encoder driver to have a predefined list of modes -- it's just highly recommended if you don't want to force the user to input mode lines manually. You just need some means to compute the optimal timings algorithmically given the connector properties and a rough description of the mode. Sure, using a fixed list of modes from which you pick the closest to the user's settings might be the easiest way to achieve that on some chips [ch7006 does precisely that IIRC], and that might be a slight underuse of the flexibility of some hardware, but the API doesn't force you to do that. And then there's the Philips TV encoder chip, which has a similar freedom in programming. Of course, given that analog TVs are dying out, the question is how much effort one should put into this whole thing in the first place. - Dirk ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgpoOL9pOgZUG.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: fix chipset checks for nv1a by using the oclass instead
Ilia Mirkin imir...@alum.mit.edu writes:
Commit f4ebcd133b9 (dri/nouveau: NV17_3D class is not available for
NV1a chipset) fixed this partially by using the correct 3d class.
However there were a lot of checks left over comparing against the
chipset.
Reported-and-tested-by: John F. Godfrey jfgodf...@gmail.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
I guess I didn't have to change the = 0x11 checks, but seemed nicer for
consistency.
Looks good to me,
Reviewed-by: Francisco Jerez curroje...@riseup.net
src/mesa/drivers/dri/nouveau/nv10_context.c | 8
src/mesa/drivers/dri/nouveau/nv10_state_fb.c | 4 ++--
src/mesa/drivers/dri/nouveau/nv10_state_raster.c | 3 ++-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv10_context.c
b/src/mesa/drivers/dri/nouveau/nv10_context.c
index 8582cb2..4773014 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_context.c
@@ -63,7 +63,7 @@ nv10_use_viewport_zclear(struct gl_context *ctx)
struct gl_framebuffer *fb = ctx-DrawBuffer;
struct gl_renderbuffer *depthRb =
fb-Attachment[BUFFER_DEPTH].Renderbuffer;
- return context_chipset(ctx) 0x17
+ return context_eng3d(ctx)-oclass NV17_3D_CLASS
!nctx-hierz.clear_blocked depthRb
(_mesa_get_format_bits(depthRb-Format,
GL_DEPTH_BITS) = 24);
@@ -184,7 +184,7 @@ nv10_clear(struct gl_context *ctx, GLbitfield buffers)
}
if ((buffers BUFFER_BIT_DEPTH) ctx-Depth.Mask) {
- if (context_chipset(ctx) = 0x17)
+ if (context_eng3d(ctx)-oclass = NV17_3D_CLASS)
nv17_zclear(ctx, buffers);
else
nv10_zclear(ctx, buffers);
@@ -245,7 +245,7 @@ nv10_hwctx_init(struct gl_context *ctx)
BEGIN_NV04(push, NV04_GRAPH(3D, NOP), 1);
PUSH_DATA (push, 0);
- if (context_chipset(ctx) = 0x17) {
+ if (context_eng3d(ctx)-oclass = NV17_3D_CLASS) {
BEGIN_NV04(push, NV17_3D(UNK01AC), 2);
PUSH_DATA (push, fifo-vram);
PUSH_DATA (push, fifo-vram);
@@ -257,7 +257,7 @@ nv10_hwctx_init(struct gl_context *ctx)
PUSH_DATA (push, 1);
}
- if (context_chipset(ctx) = 0x11) {
+ if (context_eng3d(ctx)-oclass = NV15_3D_CLASS) {
BEGIN_NV04(push, SUBC_3D(0x120), 3);
PUSH_DATA (push, 0);
PUSH_DATA (push, 1);
diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
b/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
index 19769e5..fb66b2d 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
@@ -106,7 +106,7 @@ nv10_emit_framebuffer(struct gl_context *ctx, int emit)
/* At least nv11 seems to get sad if we don't do this before
* swapping RTs.*/
- if (context_chipset(ctx) 0x17) {
+ if (context_eng3d(ctx)-oclass NV17_3D_CLASS) {
int i;
for (i = 0; i 6; i++) {
@@ -140,7 +140,7 @@ nv10_emit_framebuffer(struct gl_context *ctx, int emit)
PUSH_MTHDl(push, NV10_3D(ZETA_OFFSET), BUFCTX_FB,
s-bo, 0, bo_flags);
- if (context_chipset(ctx) = 0x17) {
+ if (context_eng3d(ctx)-oclass = NV17_3D_CLASS) {
setup_hierz_buffer(ctx);
context_dirty(ctx, ZCLEAR);
}
diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
index bd4a78e..da414a0 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_state_raster.c
@@ -28,6 +28,7 @@
#include nouveau_context.h
#include nouveau_gldefs.h
#include nouveau_util.h
+#include nv_object.xml.h
#include nv10_3d.xml.h
#include nv10_driver.h
@@ -120,7 +121,7 @@ nv10_emit_logic_opcode(struct gl_context *ctx, int emit)
struct nouveau_pushbuf *push = context_push(ctx);
assert(!ctx-Color.ColorLogicOpEnabled
-|| context_chipset(ctx) = 0x11);
+|| context_eng3d(ctx)-oclass = NV15_3D_CLASS);
BEGIN_NV04(push, NV11_3D(COLOR_LOGIC_OP_ENABLE), 2);
PUSH_DATAb(push, ctx-Color.ColorLogicOpEnabled);
--
1.8.3.2
pgptN6uESG4_S.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2] nouveau: add framebuffer validation callback
Ilia Mirkin imir...@alum.mit.edu writes:
Fixes assertions when trying to attach textures to fbs with formats not
supported by the render engines.
See https://bugs.freedesktop.org/show_bug.cgi?id=73459
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Francisco, thanks for the review. Is this more like what you had in mind?
Interesting that nv10/nv20 support different-bitness color/depth -- that
requirement came back for nv30/nv40.
Looks good to me,
Reviewed-by: Francisco Jerez curroje...@riseup.net
Thanks.
src/mesa/drivers/dri/nouveau/nouveau_context.c | 1 +
src/mesa/drivers/dri/nouveau/nouveau_fbo.c | 52
++
2 files changed, 53 insertions(+)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c
b/src/mesa/drivers/dri/nouveau/nouveau_context.c
index 181c9d0..ec474d4 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_context.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c
@@ -187,6 +187,7 @@ nouveau_context_init(struct gl_context *ctx, struct
nouveau_screen *screen,
ctx-Extensions.EXT_framebuffer_blit = true;
ctx-Extensions.EXT_texture_filter_anisotropic = true;
ctx-Extensions.NV_texture_env_combine4 = true;
+ ctx-Const.MaxColorAttachments = 1;
return GL_TRUE;
}
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
index 25543e4..427eb00 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
@@ -268,6 +268,57 @@ nouveau_finish_render_texture(struct gl_context *ctx,
texture_dirty(rb-TexImage-TexObject);
}
+static int
+validate_format_bpp(gl_format format)
+{
+ switch (format) {
+ case MESA_FORMAT_XRGB:
+ case MESA_FORMAT_ARGB:
+ case MESA_FORMAT_Z24_S8:
+ return 32;
+ case MESA_FORMAT_RGB565:
+ case MESA_FORMAT_Z16:
+ return 16;
+ default:
+ return 0;
+ }
+}
+
+static void
+nouveau_check_framebuffer_complete(struct gl_context *ctx,
+struct gl_framebuffer *fb)
+{
+ const struct nouveau_driver *drv = context_drv(ctx);
+ struct gl_renderbuffer_attachment *color =
+ fb-Attachment[BUFFER_COLOR0];
+ struct gl_renderbuffer_attachment *depth =
+ fb-Attachment[BUFFER_DEPTH];
+ int color_bpp = 0, zeta_bpp;
+
+ if (color-Type == GL_TEXTURE) {
+ color_bpp = validate_format_bpp(
+ color-Renderbuffer-TexImage-TexFormat);
+ if (!color_bpp)
+ goto err;
+ }
+
+ if (depth-Type == GL_TEXTURE) {
+ zeta_bpp = validate_format_bpp(
+ depth-Renderbuffer-TexImage-TexFormat);
+ if (!zeta_bpp)
+ goto err;
+ /* NV04/NV05 requires same bpp-ness for color/zeta */
+ if (context_chipset(ctx) 0x10
+ color_bpp color_bpp != zeta_bpp)
+ goto err;
+ }
+
+ return;
+err:
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ return;
+}
+
void
nouveau_fbo_functions_init(struct dd_function_table *functions)
{
@@ -279,4 +330,5 @@ nouveau_fbo_functions_init(struct dd_function_table
*functions)
functions-FramebufferRenderbuffer = nouveau_framebuffer_renderbuffer;
functions-RenderTexture = nouveau_render_texture;
functions-FinishRenderTexture = nouveau_finish_render_texture;
+ functions-ValidateFramebuffer = nouveau_check_framebuffer_complete;
}
--
1.8.3.2
pgp8nIZ290m0N.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: add framebuffer validation callback
Ilia Mirkin imir...@alum.mit.edu writes:
Fixes assertions when trying to attach textures to fbs with formats not
supported by the render engines.
See https://bugs.freedesktop.org/show_bug.cgi?id=73459
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
Hi Ilia,
In a perfect world I'd have separate callbacks for depth and color, but given
the list of supported values, I don't think this matters. Also I used
st_validate_framebuffer as a template, but I don't know if there can actually
be many attachments. Should MaxColorAttachments be set to 1? I think it's set
to 8 right now.
Yes, we should probably set that to one, and that will make the loop in
your nouveau_framebuffer_validate() code unnecessary.
And there's also an odd nouveau_validate_framebuffer thing in
nouveau_context.c, but I think that's related to actually
rendering/invalidating the fb displayed to the screen.
That's called before any rendering happens to check if we need to renew
any of the render buffers, e.g. in case the window was resized or
SwapBuffers() was called. It's rather unfortunate that the name of your
new function is just a permutation of the old one, how about
'nouveau_check_framebuffer_completeness'?
src/mesa/drivers/dri/nouveau/nouveau_driver.h | 1 +
src/mesa/drivers/dri/nouveau/nouveau_fbo.c| 38
+++
src/mesa/drivers/dri/nouveau/nv04_context.c | 14 ++
src/mesa/drivers/dri/nouveau/nv10_context.c | 16 +++
src/mesa/drivers/dri/nouveau/nv20_context.c | 16 +++
5 files changed, 85 insertions(+)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_driver.h
b/src/mesa/drivers/dri/nouveau/nouveau_driver.h
index e03b2c1..84953da 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_driver.h
+++ b/src/mesa/drivers/dri/nouveau/nouveau_driver.h
@@ -60,6 +60,7 @@ struct nouveau_driver {
struct nouveau_surface *dst,
unsigned mask, unsigned value,
int dx, int dy, int w, int h);
+ bool (*is_rt_format_supported)(gl_format format);
nouveau_state_func *emit;
int num_emit;
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
index 25543e4..fba0d52 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
@@ -268,6 +268,43 @@ nouveau_finish_render_texture(struct gl_context *ctx,
texture_dirty(rb-TexImage-TexObject);
}
+static void
+nouveau_framebuffer_validate(struct gl_context *ctx,
+ struct gl_framebuffer *fb)
+{
+ const struct nouveau_driver *drv = context_drv(ctx);
+ int i, count = 0;
+
+ for (i = 0; i ctx-Const.MaxColorAttachments; i++) {
+ struct gl_renderbuffer_attachment *rba =
+ fb-Attachment[BUFFER_COLOR0 + i];
+ if (rba-Type == GL_NONE)
+ continue;
+
+ count++;
+ if (rba-Type != GL_TEXTURE)
+ continue;
+
+ if (!drv-is_rt_format_supported(
+ rba-Renderbuffer-TexImage-TexFormat))
+ goto err;
+ }
+ if (count 1)
+ goto err;
+
+ if (fb-Attachment[BUFFER_DEPTH].Type == GL_TEXTURE) {
+ struct gl_texture_image *ti =
+ fb-Attachment[BUFFER_DEPTH].Renderbuffer-TexImage;
+ if (!drv-is_rt_format_supported(ti-TexFormat))
+ goto err;
+ }
+
+ return;
+err:
+ fb-_Status = GL_FRAMEBUFFER_UNSUPPORTED_EXT;
+ return;
+}
+
void
nouveau_fbo_functions_init(struct dd_function_table *functions)
{
@@ -279,4 +316,5 @@ nouveau_fbo_functions_init(struct dd_function_table
*functions)
functions-FramebufferRenderbuffer = nouveau_framebuffer_renderbuffer;
functions-RenderTexture = nouveau_render_texture;
functions-FinishRenderTexture = nouveau_finish_render_texture;
+ functions-ValidateFramebuffer = nouveau_framebuffer_validate;
}
diff --git a/src/mesa/drivers/dri/nouveau/nv04_context.c
b/src/mesa/drivers/dri/nouveau/nv04_context.c
index c198c03..665cadd 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_context.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_context.c
@@ -199,11 +199,25 @@ fail:
return NULL;
}
+static bool
+nv04_is_rt_format_supported(gl_format format)
+{
+ switch (format) {
+ case MESA_FORMAT_XRGB:
+ case MESA_FORMAT_ARGB:
+ case MESA_FORMAT_RGB565:
+ return true;
+ default:
+ return false;
+ }
+}
+
You're missing the depth/stencil formats here. nv04 is kind of annoying
because the depth and color buffers have to be of the same bpp, so if
the color buffer is 32bpp we should only accept MESA_FORMAT_Z24_S8, if
it's 16bpp MESA_FORMAT_Z16. You probably want to implement that logic
in
Re: [Nouveau] [PATCH] nouveau_vieux: add AllocTextureImageBuffer implementation
Ilia Mirkin imir...@alum.mit.edu writes:
This fixes issues where get_rt_format would see a 0 format because the
nouveau_surface had not been properly initialized. Fixes crash on
supertuxkart startup (which still fails due to out-of-vram issues).
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Thanks, pushed.
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
index da74e8f..8904389 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
@@ -494,6 +494,14 @@ nouveau_compressed_teximage(struct gl_context *ctx,
GLuint dims,
ctx-Unpack, GL_TRUE);
}
+static GLboolean
+nouveau_teximage_alloc(struct gl_context *ctx, struct gl_texture_image *ti)
+{
+ nouveau_teximage(ctx, 3, ti, 0, 0, 0, NULL,
+ ctx-DefaultPacking, GL_FALSE);
+ return GL_TRUE;
+}
+
static void
nouveau_texsubimage(struct gl_context *ctx, GLint dims,
struct gl_texture_image *ti,
@@ -634,6 +642,7 @@ nouveau_texture_functions_init(struct dd_function_table
*functions)
functions-DeleteTexture = nouveau_texture_free;
functions-NewTextureImage = nouveau_teximage_new;
functions-FreeTextureImageBuffer = nouveau_teximage_free;
+ functions-AllocTextureImageBuffer = nouveau_teximage_alloc;
functions-ChooseTextureFormat = nouveau_choose_tex_format;
functions-TexImage = nouveau_teximage_123d;
functions-TexSubImage = nouveau_texsubimage_123d;
--
1.8.1.5
pgp6MsHQUoTfn.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [PATCH 10/21] nouveau: Add support for ARB_sampler_object
Pauli Nieminen pauli.niemi...@linux.intel.com writes:
ARB_sampler_object is very simple software only extension to support.
I want to make it mandator extension for Mesa drivers to allow meta
module to use it.
This patch add support for the extension to nouveau. It is completely
untested search and replace patch. I hope someone with old NV hardware
could give a try that there is no regressions and ARB_sampler_object
tests passes.
Hey,
I don't think this patch is enough to get ARB_sampler_objects working.
First you need some way to find out that the current sampler has changed
so the nvXX_emit_tex_obj() hooks are re-executed before rendering.
Ideally it would be done using some kind of driver hook that would be
called when a new sampler is bound (the implementation would be a
one-liner, see nouveau_tex_parameter() in nouveau_state.c). Apparently
glBindSampler() already sets the _NEW_TEXTURE flag so I guess another
option could be to re-validate all the texture context for all texture
units anytime it's seen set, though I'm not sure that would be a good
idea.
Signed-off-by: Pauli Nieminen pauli.niemi...@linux.intel.com
CC: nouveau@lists.freedesktop.org
---
src/mesa/drivers/dri/nouveau/nv04_state_tex.c | 22 --
src/mesa/drivers/dri/nouveau/nv10_state_tex.c | 23 +--
src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 25
++---
3 files changed, 39 insertions(+), 31 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_tex.c
b/src/mesa/drivers/dri/nouveau/nv04_state_tex.c
index 807e2f3..e4d695a 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_state_tex.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_state_tex.c
@@ -32,6 +32,7 @@
#include nv_object.xml.h
#include nv04_3d.xml.h
#include nv04_driver.h
+#include main/samplerobj.h
static uint32_t
get_tex_format(struct gl_texture_image *ti)
@@ -67,6 +68,7 @@ nv04_emit_tex_obj(struct gl_context *ctx, int emit)
if (ctx-Texture.Unit[i]._ReallyEnabled) {
struct gl_texture_object *t = ctx-Texture.Unit[i]._Current;
struct gl_texture_image *ti = t-Image[0][t-BaseLevel];
+ const struct gl_sampler_object *sa = _mesa_get_samplerobj(ctx,
i);
int lod_max = 1, lod_bias = 0;
if (!nouveau_texture_validate(ctx, t))
@@ -74,26 +76,26 @@ nv04_emit_tex_obj(struct gl_context *ctx, int emit)
s = to_nouveau_texture(t)-surfaces[t-BaseLevel];
- if (t-Sampler.MinFilter != GL_NEAREST
- t-Sampler.MinFilter != GL_LINEAR) {
- lod_max = CLAMP(MIN2(t-Sampler.MaxLod, t-_MaxLambda),
+ if (sa-MinFilter != GL_NEAREST
+ sa-MinFilter != GL_LINEAR) {
+ lod_max = CLAMP(MIN2(sa-MaxLod, t-_MaxLambda),
0, 15) + 1;
lod_bias = CLAMP(ctx-Texture.Unit[i].LodBias +
- t-Sampler.LodBias, -16, 15) * 8;
+ sa-LodBias, -16, 15) * 8;
}
- format |= nvgl_wrap_mode(t-Sampler.WrapT) 28 |
- nvgl_wrap_mode(t-Sampler.WrapS) 24 |
+ format |= nvgl_wrap_mode(sa-WrapT) 28 |
+ nvgl_wrap_mode(sa-WrapS) 24 |
ti-HeightLog2 20 |
ti-WidthLog2 16 |
lod_max 12 |
get_tex_format(ti);
- filter |= log2i(t-Sampler.MaxAnisotropy) 31 |
- nvgl_filter_mode(t-Sampler.MagFilter) 28 |
- log2i(t-Sampler.MaxAnisotropy) 27 |
- nvgl_filter_mode(t-Sampler.MinFilter) 24 |
+ filter |= log2i(sa-MaxAnisotropy) 31 |
+ nvgl_filter_mode(sa-MagFilter) 28 |
+ log2i(sa-MaxAnisotropy) 27 |
+ nvgl_filter_mode(sa-MinFilter) 24 |
(lod_bias 0xff) 16;
} else {
diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_tex.c
b/src/mesa/drivers/dri/nouveau/nv10_state_tex.c
index b467bb3..3b76d66 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_state_tex.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_state_tex.c
@@ -31,6 +31,7 @@
#include nv10_3d.xml.h
#include nouveau_util.h
#include nv10_driver.h
+#include main/samplerobj.h
void
nv10_emit_tex_gen(struct gl_context *ctx, int emit)
@@ -159,6 +160,7 @@ nv10_emit_tex_obj(struct gl_context *ctx, int emit)
struct gl_texture_object *t;
struct nouveau_surface *s;
struct gl_texture_image *ti;
+ const struct gl_sampler_object *sa;
uint32_t tx_format, tx_filter, tx_enable;
PUSH_RESET(push, BUFCTX_TEX(i));
@@ -172,22 +174,23 @@ nv10_emit_tex_obj(struct gl_context *ctx, int emit)
t = ctx-Texture.Unit[i]._Current;
s =
Re: [Nouveau] [PATCH] nouveau/dri2: don't try to page flip pixmaps
Marcin Slusarz marcin.slus...@gmail.com writes:
Port of commit ae45d7e6d8e6844cd4586c9ee97c21b257fa788f in xf86-video-ati.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=49351
(Additionally, don't try to pageflip if user disabled it in xorg.conf.
Currently this change is a no-op, because can_exchange returns true only when
page flipping is enabled, but commit 169512fbe91f0671a90dfee5e280357f0a4ef701
-
which changed can_exchange behavior - is due to be reverted)
---
src/nouveau_dri2.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index 588735f..3d8d22f 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -328,7 +328,8 @@ nouveau_dri2_finish_swap(DrawablePtr draw, unsigned int
frame,
type = DRI2_EXCHANGE_COMPLETE;
DamageRegionAppend(draw, reg);
- if (DRI2CanFlip(draw)) {
+ if (DRI2CanFlip(draw) pNv-has_pageflip
+ draw-type == DRAWABLE_WINDOW) {
Hey,
How about 'if (nouveau_exa_pixmap_is_onscreen(dst_pix)) {...'? We
should really never get to that point unless we know for sure that we
can either flip or exchange, so the 'has_pageflip' check is redundant.
type = DRI2_FLIP_COMPLETE;
ret = drmmode_page_flip(draw, src_pix,
violate_oml(draw) ? NULL : s,
pgp5jLBUh34ld.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau/dri2: don't try to page flip pixmaps
Marcin Slusarz marcin.slus...@gmail.com writes:
On Thu, May 03, 2012 at 03:15:51PM +0200, Francisco Jerez wrote:
Marcin Slusarz marcin.slus...@gmail.com writes:
Port of commit ae45d7e6d8e6844cd4586c9ee97c21b257fa788f in xf86-video-ati.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=49351
(Additionally, don't try to pageflip if user disabled it in xorg.conf.
Currently this change is a no-op, because can_exchange returns true only
when
page flipping is enabled, but commit
169512fbe91f0671a90dfee5e280357f0a4ef701 -
which changed can_exchange behavior - is due to be reverted)
---
src/nouveau_dri2.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index 588735f..3d8d22f 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -328,7 +328,8 @@ nouveau_dri2_finish_swap(DrawablePtr draw, unsigned
int frame,
type = DRI2_EXCHANGE_COMPLETE;
DamageRegionAppend(draw, reg);
- if (DRI2CanFlip(draw)) {
+ if (DRI2CanFlip(draw) pNv-has_pageflip
+ draw-type == DRAWABLE_WINDOW) {
Hey,
How about 'if (nouveau_exa_pixmap_is_onscreen(dst_pix)) {...'? We
should really never get to that point unless we know for sure that we
can either flip or exchange, so the 'has_pageflip' check is redundant.
I see your point, but it's all non obvious. How about this patch instead?
:)
I guess the confusion stems from the meaning of exchange: Do you
exchange as well as you flip or does one exclude the other? This code
only (used to) make sense if you read it the first way, i.e. as if
flip were the subset of exchange you use with on-screen windows. :P
That said, I'm OK with changing the name of can_exchange to
can_exchange_or_flip if that makes its meaning clearer. TBH the rest
of the changes in this patch don't really look to me like they're making
anything easier to understand. That's quite a personal matter though.
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] dri2: don't try to page flip pixmaps
Based on commit ae45d7e6d8e6844cd4586c9ee97c21b257fa788f in xf86-video-ati.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=49351
---
src/nouveau_dri2.c | 31 ---
1 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index 588735f..86039ef 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -178,12 +178,14 @@ update_front(DrawablePtr draw, DRI2BufferPtr front)
}
static Bool
-can_exchange(DrawablePtr draw, PixmapPtr dst_pix, PixmapPtr src_pix)
+can_exchange_or_flip(DrawablePtr draw, PixmapPtr dst_pix, PixmapPtr src_pix,
+ Bool *flip)
{
ScrnInfoPtr scrn = xf86Screens[draw-pScreen-myNum];
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
NVPtr pNv = NVPTR(scrn);
int i;
+ Bool dst_is_screen;
for (i = 0; i xf86_config-num_crtc; i++) {
xf86CrtcPtr crtc = xf86_config-crtc[i];
@@ -192,11 +194,17 @@ can_exchange(DrawablePtr draw, PixmapPtr dst_pix,
PixmapPtr src_pix)
}
- return ((DRI2CanFlip(draw) pNv-has_pageflip))
- dst_pix-drawable.width == src_pix-drawable.width
- dst_pix-drawable.height == src_pix-drawable.height
- dst_pix-drawable.bitsPerPixel ==
src_pix-drawable.bitsPerPixel
- dst_pix-devKind == src_pix-devKind;
+ if (dst_pix-drawable.width != src_pix-drawable.width ||
+ dst_pix-drawable.height != src_pix-drawable.height ||
+ dst_pix-drawable.bitsPerPixel !=
src_pix-drawable.bitsPerPixel ||
+ dst_pix-devKind != src_pix-devKind)
+ return FALSE;
+
+ dst_is_screen = nouveau_exa_pixmap_is_onscreen(dst_pix);
+ *flip = dst_is_screen pNv-has_pageflip DRI2CanFlip(draw);
+
+ /* Exchange path is currently disabled, see fdo bug 35930 */
+ return *flip /*|| !dst_is_screen*/;
}
static Bool
@@ -280,7 +288,7 @@ nouveau_dri2_finish_swap(DrawablePtr draw, unsigned int
frame,
struct nouveau_pushbuf *push = pNv-pushbuf;
RegionRec reg;
int type, ret;
- Bool front_updated;
+ Bool front_updated, flip;
REGION_INIT(0, reg, ((BoxRec){ 0, 0, draw-width, draw-height }), 0);
REGION_TRANSLATE(0, reg, draw-x, draw-y);
@@ -324,17 +332,18 @@ nouveau_dri2_finish_swap(DrawablePtr draw, unsigned int
frame,
nouveau_pushbuf_kick(push, push-channel);
}
- if (front_updated can_exchange(draw, dst_pix, src_pix)) {
- type = DRI2_EXCHANGE_COMPLETE;
+ if (front_updated can_exchange_or_flip(draw, dst_pix, src_pix,
flip)) {
DamageRegionAppend(draw, reg);
- if (DRI2CanFlip(draw)) {
+ if (flip) {
type
Re: [Nouveau] [PATCH v2 0/2] S3TC support for nv10-20
Viktor Novotný novik...@seznam.cz writes: Hi, thanks for feedback, I finally got to get through your comments - I hope it's OK now. Hey, thanks, both patches pushed. BTW if you are going to test this, it seems to me that 784dd51198 have broken piglit's fbo-generatemipmap-formats and s3tc-teximage tests, could you confirm? Yeah, those also fail for me here. Viktor pgpd6lLOvDfbq.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau/vieux: only advertise supported texture formats
Lucas Stach d...@lynxeye.de writes: Fixes an assertion seen by users. Signed-off-by: Lucas Stach d...@lynxeye.de Tested-by: JohnDoe_71Rus on irc --- src/mesa/drivers/dri/nouveau/nouveau_context.c |9 + 1 file changed, 9 insertions(+) diff --git a/src/mesa/drivers/dri/nouveau/nouveau_context.c b/src/mesa/drivers/dri/nouveau/nouveau_context.c index 4845767..46c0d70 100644 --- a/src/mesa/drivers/dri/nouveau/nouveau_context.c +++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c @@ -117,6 +117,15 @@ nouveau_context_init(struct gl_context *ctx, struct nouveau_screen *screen, nouveau_span_functions_init(ctx); _mesa_allow_light_in_model(ctx, GL_FALSE); + /* only advertise supported texture formats */ + memset(ctx-TextureFormatSupported, 0, +sizeof(ctx-TextureFormatSupported)); + ctx-TextureFormatSupported[MESA_FORMAT_XRGB] = true; + ctx-TextureFormatSupported[MESA_FORMAT_ARGB] = true; + ctx-TextureFormatSupported[MESA_FORMAT_RGB565] = true; + ctx-TextureFormatSupported[MESA_FORMAT_Z16] = true; + ctx-TextureFormatSupported[MESA_FORMAT_Z24_S8] = true; + Hi Lucas, It's not obvious to me how this works. AFAIK nouveau doesn't make use of this array. And even if it did, the texture formats you're listing aren't the supported ones. /* Allocate a hardware channel. */ ret = nouveau_object_new(context_dev(ctx)-object, 0xbeef, NOUVEAU_FIFO_CHANNEL_CLASS, pgpxt0xH32Krg.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau/vieux: only advertise supported texture formats
Lucas Stach d...@lynxeye.de writes: Am Montag, den 30.04.2012, 20:08 +0200 schrieb Francisco Jerez: Lucas Stach d...@lynxeye.de writes: [...] + /* only advertise supported texture formats */ + memset(ctx-TextureFormatSupported, 0, + sizeof(ctx-TextureFormatSupported)); + ctx-TextureFormatSupported[MESA_FORMAT_XRGB] = true; + ctx-TextureFormatSupported[MESA_FORMAT_ARGB] = true; + ctx-TextureFormatSupported[MESA_FORMAT_RGB565] = true; + ctx-TextureFormatSupported[MESA_FORMAT_Z16] = true; + ctx-TextureFormatSupported[MESA_FORMAT_Z24_S8] = true; + Hi Lucas, It's not obvious to me how this works. AFAIK nouveau doesn't make use of this array. And even if it did, the texture formats you're listing aren't the supported ones. Hello Francisco, The core mesa code decides what texture formats to advertise based on this array. Are you sure? TextureFormatSupported doesn't seem to have any effect except in drivers that use mesa's default for the ChooseTextureFormat hook. And obviously someone thought it would be a good idea to init this array to everything supported if the driver doesn't overrides this. I opted to only advertise renderable texture formats, for reasons explained in my mail a minute ago. pgpa2eDJ9neIn.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [WIP PATCH] dri/nouveau: Add S3TC support for nv20.
Ben Skeggs skeg...@gmail.com writes:
On Fri, 2012-04-06 at 17:40 +0200, Viktor Novotný wrote:
---
Hi,
Hey Viktor!
Thanks for the patch!
Hey,
this is still WIP, but already passes piglit's s3tc-teximage,
s3tc-texsubimage and fbo-generatemipmap-formats(s3tc tests)
and even Wolfenstein:Enemy-Territory works on my nv25. It's based on Ben's
newlib branch. I have few issues though:
1) So far it needs libtxc_dxtn, but I might expose the s3tc extensions even
without encoder using driconf option -
Is that desirable?
2) Looking at blob's dedma'd valgrind-mmt dumps it seems blob uses pitch no
smaller than 64 in miptree,
but for me everything works as it is. Does it make any difference?
2) I am not sure about computing the offsets in teximage_map - it works like
this, but can somebody confirm it's ok?
3) If somebody can give me some feedback on the style etc., please do.
4) S3TC texture seem to be supported also on nv10, I have nv11 somewhere so
I might be able to add support to it too,
Yeah, it should be trivial to add support for it on nv10 now that you've
got the generic support code working.
Curro, are you able to take a look over this and give Viktor some
feedback? You're probably best acquainted with the vieux code :)
Ben.
but I don't have nv04, then again, I think it might not support S3TC?
No, it doesn't.
If I you think the patch is mostly OK, I will process your feedback, split
generic and nv20 specific part and resend it.
Yes, it's mostly fine aside from a few style issues. See the comments
inline.
Regards
Viktor
src/mesa/drivers/dri/nouveau/nouveau_surface.c | 14 ++-
src/mesa/drivers/dri/nouveau/nouveau_texture.c | 143
++-
src/mesa/drivers/dri/nouveau/nouveau_util.h| 19 +++
src/mesa/drivers/dri/nouveau/nv04_surface.c| 17 +++-
src/mesa/drivers/dri/nouveau/nv20_context.c|4 +
src/mesa/drivers/dri/nouveau/nv20_state_tex.c | 10 ++
6 files changed, 172 insertions(+), 35 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_surface.c
b/src/mesa/drivers/dri/nouveau/nouveau_surface.c
index f252114..349000a 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_surface.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_surface.c
@@ -28,6 +28,8 @@
#include nouveau_context.h
#include nouveau_util.h
+#include main/formats.h
+
void
nouveau_surface_alloc(struct gl_context *ctx, struct nouveau_surface *s,
enum nouveau_surface_layout layout,
@@ -36,6 +38,8 @@ nouveau_surface_alloc(struct gl_context *ctx, struct
nouveau_surface *s,
{
union nouveau_bo_config config = {};
int ret, cpp = _mesa_get_format_bytes(format);
+int pitch = _mesa_format_row_stride(format, width);
+unsigned size;
nouveau_bo_ref(NULL, s-bo);
@@ -45,7 +49,7 @@ nouveau_surface_alloc(struct gl_context *ctx, struct
nouveau_surface *s,
.width = width,
.height = height,
.cpp = cpp,
-.pitch = width * cpp,
+.pitch = pitch,
No need for the additional local variables:
| .pitch = _mesa_format_row_stride(format, width),
};
if (layout == TILED) {
@@ -64,8 +68,12 @@ nouveau_surface_alloc(struct gl_context *ctx, struct
nouveau_surface *s,
s-pitch = align(s-pitch, 64);
}
-ret = nouveau_bo_new(context_dev(ctx), flags, 0, s-pitch * height,
- config, s-bo);
+if (_mesa_is_format_compressed(format))
+size = s-pitch * nouveau_format_get_nblocksy(format, height);
+else
+size = s-pitch * height;
+
+ret = nouveau_bo_new(context_dev(ctx), flags, 0, size, config, s-bo);
No need for the conditional here:
| ret = nouveau_bo_new(context_dev(ctx), flags, 0,
| s-pitch * get_format_blocksy(format, height),
| config, s-bo);
assert(!ret);
}
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
index 643b890..52f0259 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_texture.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_texture.c
@@ -91,6 +91,7 @@ nouveau_teximage_map(struct gl_context *ctx, struct
gl_texture_image *ti,
if (s-bo) {
if (!(access GL_MAP_READ_BIT)
nouveau_pushbuf_refd(context_push(ctx), s-bo)) {
+unsigned size;
/*
* Heuristic: use a bounce buffer to pipeline
* teximage transfers.
@@ -104,7 +105,8 @@ nouveau_teximage_map(struct gl_context *ctx, struct
gl_texture_image *ti,
nti-transfer.x = x;
nti-transfer.y = y;
-nti-base.Map = nouveau_get_scratch(ctx, st-pitch * h,
+size = nouveau_format_get_nblocksx(st-format, h) *
st-pitch;
+
Re: [Nouveau] Older Nvidia hardware driver state
Patrick Baggett baggett.patr...@gmail.com writes: Hi all! Hi, I read that the older Nvidia hardware (maybe GF8) is in a different driver and no longer maintained. Is that the case? Yes and no. If you're talking about the 3d drivers, I've done pretty much nothing as maintainer of the nv04-nv20 driver in the last few months, and the same goes for the nv30-nv40 driver, mostly because of lack of time of the people involved. If you're talking about 2d, the situation is considerably better. And of course there's hardware-specific code different for each card generation, but IMHO calling them different separate drivers would be wrong, there's a significant amount of shared code. I have a GeForce 4000 MX that I'm trying to get to work on debian/sparc64, which I admit is a bit of longshot, but I was wondering how much effort it would take to even get the driver to build, and then to function. I'm very proficient in C but don't have much experience writing drivers. It *should* be functional to a large extent, it's just that it might have bred a few bugs while we weren't looking :). In any case your help is very welcome if you know how to program, feel free to address any questions to this mailing list or to the #nouveau IRC channel. Patrick Baggett ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgpiaM6qFkcvh.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nv10: disable perf hack on low memory cards
Marcin Slusarz marcin.slus...@gmail.com writes:
On 16MB cards it's too easy to hit ENOMEM with 2D use when this
perf hack is enabled.
AFAIK the hack still makes sense on such low memory cards. I guess
the right way to fix this corner case would be to have fall-back
placement ranges in TTM the same way there's a list of allowed placement
types right now.
But, it's probably not worth the effort. For now I've just pushed a
patch changing the BO size threshold that determines whether to set the
placement range or not. That's likely to behave better than a hard
memory limit of this kind, both when you have a 32MB card with small
enough render buffers or a 32MB card with huge render buffers that
would otherwise hit the same bug.
This should fix https://bugs.freedesktop.org/show_bug.cgi?id=42384
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Francisco Jerez curroje...@riseup.net
---
drivers/gpu/drm/nouveau/nouveau_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7226f41..a692648 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -148,6 +148,7 @@ set_placement_range(struct nouveau_bo *nvbo, uint32_t
type)
if (dev_priv-card_type == NV_10
nvbo-tile_mode (type TTM_PL_FLAG_VRAM)
+ dev_priv-vram_size = 32 * 1024 * 1024
nvbo-bo.mem.num_pages vram_pages / 2) {
/*
* Make sure that the color and depth buffers are handled
pgpGplBFlt7xG.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] dri2: Implement handling of pageflip completion events.
Mario Kleiner mario.klei...@tuebingen.mpg.de writes: On 09/09/2011 11:05 PM, Francisco Jerez wrote: Mario Kleinermario.klei...@tuebingen.mpg.de writes: [...] Hi, thanks for the comments. Thank you for looking into this :) Sorry for the late reply. I'm a bit slow at the moment. No worries, right now I have my mind somewhere else as well... I see your point, but at least as a starting point for the first iteration i don't think the current dri2 implementation of pageflips was a dumb decision. It is the same default double buffer behaviour that the binary drivers on Linux and also on other os'es (OS/X and Windows) expose. Not the nvidia one, last time I checked. It doesn't neccessarily block glXXX drawing command submission, but it doesn't do triple-buffering by default. It blocks rendering until swap completion, probably just queueing up drawing commands internally. I didn't mean it does (real) triple-buffering, but rather that it doesn't block command submission to the new back buffer after glXSwapBuffers() is called (which for most practical purposes gives a similar effect to triple-buffering where the command buffer acts as third buffer). Here is how my toolkit waits for swap completion with the binary blob on linux, os/x and windows: 1. glXSwapBuffers() (aka SwapBuffers() on Windows aka CGLFlushDrawable()) on OS/X). 2. glBegin(GL_POINTS); glVertex2i(10,10); glEnd(); 3. glFinish(); 4. Read clock, scanout position etc. compute swap completion timestamp. On any tested binary NVidia, ATI or Intel drivers on any tested Windows, OS/X or Linux version this blocks in glFinish() until swap completion, at least for page-flipped fullscreen swaps if the optional triple buffering option is not selected in the driver control panel. This method is successfully tested on multiple ten thousand users setups over at least the last six years. So glFinish() waits for draw completion and drawing apparently waits for swap completion - strictly double-buffered with the drivers default settings. Or at least the observable behaviour of the drivers is consistent with this assumption. AFAICT you'd still get the same effect even if it were using something different to double-buffering. [...] With the current implementation (and IIRC it's the same on both radeon and intel) the divisor/remainder relation is ignored in the case where the gpu is too busy to finish its rendering in time for the predicted MSC; the flip is carried out as soon as the GPU finishes, possibly a few vblank periods later. To fix this properly in nouveau, I think it would be good to push the divisor/remainder calculation down to the kernel (second reason so far to extend the kernel interface), but once it's done we'll get the divisor/remainder relation right no matter if multibuffering is being used or not. Agreed on that. The current fix only fixes the easy case where the client submits a swap request too late to satisfy the divisor/remainder relation, or where the relation is easily satisfiable. E.g., my toolkit uses it to make sure that a swap happens after a user specified deadline, but only on, e.g., odd numbered video refresh cycles, for the purpose of getting frame-sequential stereo right. None of the current ddx handles the case where the backbuffer is still busy at the target vblank. Imho there are a couple of things a pageflip ioctl() v2 should provide: * Some support for frame-sequential stereo. * 64 bit target_msc. * Divisor/remainder in kernel. Personally I'd like a more stupid pageflip IOCTL instead of a smarter one... We could split the sync-to-vblank functionality into a different, orthogonal IOCTL that: * takes a GEM object, a CRTC number, and a sync target/divisor/remainder. * makes sure that any further references (including command submission and page-flipping) to the given GEM object are synchronized to the given CRTC according to the given sync parameters. * optionally sends an event back to userspace once the sync target is reached. This would get us a standard interface for: * Standard page-flipping respecting the divisor/remainder relation. * Tear-free multihead flipping (if done correctly). * Tear-free blitting with completion notification. * Tearful but fast non-vsync'ed pageflip. [...] IMHO getting a small (and required) fix (the swaplimit API) into one software component is more advisable from the maintainership standpoint than putting in place two different codepaths in another software component, both of which are broken in its own way. I totally agree with you. But assume we finally manage to persuade Keith to integrate that API into 1.12, it would still be nice - at least for my users - if the nouveau ddx could optionally support a double-buffered mode with correct timestamps on current servers, e.g., 1.9 - 1.11. I think the proposed patch should work for n-buffering on future servers with a swaplimit api
Re: [Nouveau] [PATCH 3/3] dri2: Fixes to swap scheduling, especially for copy-swaps.
Mario Kleiner mario.klei...@tuebingen.mpg.de writes: On 09/09/2011 11:14 PM, Francisco Jerez wrote: Mario Kleinermario.klei...@tuebingen.mpg.de writes: [...] But the current implementation under a compositor is not great. You get glxgears reporting that vsync is on and the redraw rate should equal the refresh rate but see 2900 fps reported on a 60 Hz display, with apparently 60 Hz animation. And, in my use case, toolkits that care about timing and do some consistency checks on their swapbuffers execution bail out immediately, telling you to fix your totally broken graphics driver setup. It's a pure better than nothing change for the redirected case, which seems to behave less confusing, at least as no fancy transformations are used, e.g., during desktop transitions. OK, fair enough. So, you're ok with that better than nothing change? Yeah, but it probably deserves its own separate patch. [...] Oh ok, thanks. I have special measurement equipment here to test pageflipped swaps for timing, but can't test the copyswap case easily. My toolkit was complaining loudly about inconsistencies, so i was just assuming it is due to the same logic as on other gpu's + missing code in the ddx. If copy-swaps are intentionally scheduled one frame ahead, then DRI2SwapComplete timestamps would need to be corrected for that. Currently you get the puzzling result from the timestamps that swaps complete before they were even scheduled by the client, typically a clear indication of broken vsync support in the driver. Heh, yeah... I will change the patch to remove the unneccessary bits and try if the DRI2SwapComplete timestamps for the copy-swap case can be fixed instead. We should probably fix the kernel interface for that, instead of adding more band-aids to userspace. Do you know how this is done at the hardware level? Exactly as with pageflips? The gpu programming seems to be the same in the ddx. Yes, we use the same synchronization mechanism for pageflips and blits. Hm. Then would it be easily possible for the kms-driver to emit pageflip completion events for blits as well, e.g., when the drawing engine continues or the main x server channel submits the blit? That would be a simple and reliable way to timestamp blit-swaps on nouveau as well. I've come up with some sketchy ideas to do this on intel and ati, but didn't get around to test them so far. Their implementation will be quite a bit more involved. Yes, the implementation would be exactly the same as what we use to get pageflip completion events, we're just missing the interface to expose it to the user. Is the blip operation started at leading edge of the vblank interval? Or anywhere inside the vblank interval (level triggered)? Are such blits submitted on a separate fifo (or even dma engine?) in the gpu to avoid stalling the rest of the command stream until vblank? It depends, right now we have two completely different implementations and we use one or the other depending on the card generation: On nv11-nv4x, we use the PGRAPH vsync methods (0x120-0x134), that means it's the drawing engine that waits. Basically you have a counter that's incremented by a CRTC of your choice when it reaches a scanline range of your choice, wrapping around at a configurable value; you can put the drawing engine to sleep until the counter reaches a given value. Right now we make it wait until somewhere between vdisplay-3 and vdisplay-1 before going on with the swap. Interesting, thanks for the explanation. Maybe that counter could also be used to implement a hardware vblank counter on pre-NV50? Currently the .get_vblank_counter hook is not correctly implemented in the nouveau-kms driver. It currently hooks up to drm_vblank_count(), i.e., it uses the value of the software drm counter which it is supposed to reinitialize from scratch with fresh and independent values from the hardware. At the moment this is basically a no-op and the drm will lose vblank counts whenever it disables vblank irq's for power saving. I wanted to prepare a patch for this. For NV-50 there is a hardware vblank counter. For earlier cards i couldn't find one, last time i searched six month ago? I'm almost certain that you couldn't because there isn't one... From nv5x on, we use PFIFO semaphores to suspend the execution of the channel (right now the main X server channel but this could be changed) until a pre-allocated memory location gets a given value, which is written there manually by the PDISPLAY vblank interrupt handler. I'm not sure when exactly this IRQ happens, most likely it can be configured, but I have reasons to believe that in some set-ups it happens at the end of the vblank period causing the tearing I've seen a few times. I've observed something similar on my QuadroFX-570 here with pageflips as well. The kms-pageflip seems to always happen in scanline 5 of the active scanout, instead of inside the vblank
Re: [Nouveau] [PATCH 3/3] dri2: Fixes to swap scheduling, especially for copy-swaps.
Francisco Jerez curroje...@riseup.net writes: Mario Kleiner mario.klei...@tuebingen.mpg.de writes: On 09/09/2011 11:14 PM, Francisco Jerez wrote: Mario Kleinermario.klei...@tuebingen.mpg.de writes: [...] Is the blip operation started at leading edge of the vblank interval? Or anywhere inside the vblank interval (level triggered)? Are such blits submitted on a separate fifo (or even dma engine?) in the gpu to avoid stalling the rest of the command stream until vblank? It depends, right now we have two completely different implementations and we use one or the other depending on the card generation: On nv11-nv4x, we use the PGRAPH vsync methods (0x120-0x134), that means it's the drawing engine that waits. Basically you have a counter that's incremented by a CRTC of your choice when it reaches a scanline range of your choice, wrapping around at a configurable value; you can put the drawing engine to sleep until the counter reaches a given value. Right now we make it wait until somewhere between vdisplay-3 and vdisplay-1 before going on with the swap. Interesting, thanks for the explanation. Maybe that counter could also be used to implement a hardware vblank counter on pre-NV50? I forgot to answer to this question... Not really, these counters are (IIRC) only 3 bits wide, and they need PGRAPH intervention to get incremented, so they're quite useless for anything more sophisticated than what we're doing right now. [...] pgp662jjNCIP8.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/3] dri2: Implement handling of pageflip completion events.
Mario Kleiner mario.klei...@tuebingen.mpg.de writes:
Requests pageflip completion events from the kernel.
Implements pageflip completion handler to finalize
and timestamp swaps.
Completion handler includes a consistency check, and
disambiguation if multiple crtc's are involved in a
pageflip (e.g., clone mode, extendend desktop). Only
the timestamp of the crtc whose vblank event initially
triggered the swap is used, but handler waits for flip
completion on all involved crtc's before completing the
swap and releasing the old framebuffer.
This code is almost identical to the code used in the
ati/radeon ddx and intel ddx.
There's a good reason that I held myself back from doing this when I
wrote the rest of the SwapBuffers stuff; right now the X server assumes
that the DDX can't handle more than one SwapBuffers request in flight at
any given time, so, after a SwapBuffers request has been received, the
client is prevented from doing anything until the swap (and,
consequently, the whole rendering of the previous frame) has been
completed, that means that the client is forced to render each frame in
lock-step, and it leads to a considerable performance loss.
In my judgment it seemed quite dumb to wire up all the page-flipping
infrastructure together, only to notice that it was slowing things down
even further (since performance was the main point I had for it...). As
the ability to report accurate swap completion events seemed to be of
comparatively limited usefulness, I made the DDX pretend the buffers are
swapped one frame before they actually are as a temporary workaround
(see the comment at the end of nouveau_dri2_finish_swap()).
So, IMHO, this change depends on the X server N-buffering changes going
in - actually the DRI2SwapLimit() API that (IIRC) Pauli Nieminen
proposed some time ago was all we needed, but it hasn't been accepted
upstream for some reason.
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
src/drmmode_display.c | 105
+++--
src/nouveau_dri2.c| 89 +++--
src/nv_proto.h|5 ++-
3 files changed, 189 insertions(+), 10 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 3afef66..bcb2a94 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -83,6 +83,21 @@ typedef struct {
drmmode_prop_ptr props;
} drmmode_output_private_rec, *drmmode_output_private_ptr;
+typedef struct {
+drmmode_ptr drmmode;
+unsigned old_fb_id;
+int flip_count;
+void *event_data;
+unsigned int fe_frame;
+unsigned int fe_tv_sec;
+unsigned int fe_tv_usec;
+} drmmode_flipdata_rec, *drmmode_flipdata_ptr;
+
+typedef struct {
+drmmode_flipdata_ptr flipdata;
+Bool dispatch_me;
+} drmmode_flipevtcarrier_rec, *drmmode_flipevtcarrier_ptr;
+
static void drmmode_output_dpms(xf86OutputPtr output, int mode);
static drmmode_ptr
@@ -1246,13 +1261,17 @@ drmmode_cursor_init(ScreenPtr pScreen)
}
Bool
-drmmode_page_flip(DrawablePtr draw, PixmapPtr back, void *priv)
+drmmode_page_flip(DrawablePtr draw, PixmapPtr back, void *priv,
+ unsigned int ref_crtc_hw_id)
{
ScrnInfoPtr scrn = xf86Screens[draw-pScreen-myNum];
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
drmmode_crtc_private_ptr crtc = config-crtc[0]-driver_private;
drmmode_ptr mode = crtc-drmmode;
int ret, i, old_fb_id;
+ int emitted = 0;
+ drmmode_flipdata_ptr flipdata;
+ drmmode_flipevtcarrier_ptr flipcarrier;
old_fb_id = mode-fb_id;
ret = drmModeAddFB(mode-fd, scrn-virtualX, scrn-virtualY,
@@ -1265,24 +1284,64 @@ drmmode_page_flip(DrawablePtr draw, PixmapPtr back,
void *priv)
return FALSE;
}
+ flipdata = calloc(1, sizeof(drmmode_flipdata_rec));
+ if (!flipdata) {
+ xf86DrvMsg(scrn-scrnIndex, X_WARNING,
+ flip queue: data alloc failed.\n);
+ goto error_undo;
+ }
+
+ flipdata-event_data = priv;
+ flipdata-drmmode = mode;
+
for (i = 0; i config-num_crtc; i++) {
crtc = config-crtc[i]-driver_private;
if (!config-crtc[i]-enabled)
continue;
+ flipdata-flip_count++;
+
+ flipcarrier = calloc(1, sizeof(drmmode_flipevtcarrier_rec));
+ if (!flipcarrier) {
+ xf86DrvMsg(scrn-scrnIndex, X_WARNING,
+flip queue: carrier alloc failed.\n);
+ if (emitted == 0)
+ free(flipdata);
+ goto error_undo;
+ }
+
+ /* Only the reference crtc will finally deliver its page flip
+ * completion event. All other crtc's events will be discarded.
+ */
+ flipcarrier-dispatch_me = ((1 i) ==
Re: [Nouveau] [PATCH 3/3] dri2: Fixes to swap scheduling, especially for copy-swaps.
Mario Kleiner mario.klei...@tuebingen.mpg.de writes:
Treats vblank event scheduling for the non-pageflip swap
case correctly. Allows vblank controlled swaps for redirected
windows. Fixes some corner-cases in OML_sync_control scheduling
when divisor and remainder parameters are used.
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
src/nouveau_dri2.c | 71 ---
1 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index 9f0ee97..f14dea4 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -196,10 +196,8 @@ can_sync_to_vblank(DrawablePtr draw)
{
ScrnInfoPtr scrn = xf86Screens[draw-pScreen-myNum];
NVPtr pNv = NVPTR(scrn);
- PixmapPtr pix = NVGetDrawablePixmap(draw);
return pNv-glx_vblank
- nouveau_exa_pixmap_is_onscreen(pix)
I'm not sure that this is the right way to fix this problem, depending
on the kind of transformations that the compositing manager is doing
you're likely to end up picking a CRTC at random... I just have the
impression that for redirected windows syncing to vblank is no longer
our responsibility, but rather the compositing manager's.
nv_window_belongs_to_crtc(scrn, draw-x, draw-y,
draw-width, draw-height);
}
@@ -344,9 +342,40 @@ nouveau_dri2_schedule_swap(ClientPtr client, DrawablePtr
draw,
CARD64 *target_msc, CARD64 divisor, CARD64 remainder,
DRI2SwapEventPtr func, void *data)
{
+ PixmapPtr dst_pix;
+ PixmapPtr src_pix = nouveau_dri2_buffer(src)-ppix;
struct nouveau_dri2_vblank_state *s;
CARD64 current_msc, expect_msc;
- int ret;
+ int ret, flip = 0;
+ Bool front_updated;
+
+ /* Truncate to match kernel interfaces; means occasional overflow
+ * misses, but that's generally not a big deal.
+ */
+ *target_msc = 0x;
+ divisor = 0x;
+ remainder = 0x;
+
This doesn't really fix the problem with our 32bit counters wrapping
around, but, as the comment says, it's not a big deal...
+ /* Update frontbuffer pixmap and name: Could have changed due to
+ * window (un)redirection as part of compositing.
+ */
+ front_updated = update_front(draw, dst);
+
+ /* Assign frontbuffer pixmap, after update in update_front() */
+ dst_pix = nouveau_dri2_buffer(dst)-ppix;
+
+ /* Flips need to be submitted one frame before */
+ if (DRI2CanFlip(draw) front_updated
+ can_exchange(draw, dst_pix, src_pix)) {
+ flip = 1;
+ }
+
+ /* Correct target_msc by 'flip' if this is a page-flipped swap.
+ * Do it early, so handling of different timing constraints
+ * for divisor, remainder and msc vs. target_msc works.
+ */
+ if (*target_msc 0)
+ *target_msc -= (CARD64) flip;
We don't need the code above, blits are submitted one frame before as
well - the wait for the final vblank is done in hardware by the GPU
itself, that way we don't have to worry about tearing caused by the GPU
being too busy to finish all its previous work in time for the specified
vblank interval.
/* Initialize a swap structure */
s = malloc(sizeof(*s));
@@ -363,19 +392,34 @@ nouveau_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
if (ret)
goto fail;
- /* Calculate a swap target if we don't have one */
- if (current_msc = *target_msc divisor)
+ /* Calculate a swap target if we don't have one or if
+ * divisor/remainder relationship must be satisfied.
+ */
Hm, the divisor/remainder relationship having to be satisfied is just
what one has to do when we don't have one.
+ if (current_msc = *target_msc divisor) {
*target_msc = current_msc + divisor
- (current_msc - remainder) % divisor;
- /* Request a vblank event one frame before the target */
+ /* Account for extra pageflip delay if flip 0 */
+ *target_msc -= (CARD64) flip;
+ }
+
+ /* Request a vblank event one frame before the target, unless
+ * this is a copy-swap, in which case we need to make sure
+ * it is only dispatched at the target frame or later.
+ */
ret = nouveau_wait_vblank(draw, DRM_VBLANK_ABSOLUTE |
- DRM_VBLANK_EVENT,
- max(current_msc, *target_msc - 1),
+ DRM_VBLANK_EVENT |
+ ((flip) ? 0 : DRM_VBLANK_NEXTONMISS),
+ max(current_msc, *target_msc),
Re: [Nouveau] [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks
Pekka Paalanen p...@iki.fi writes: On Mon, 18 Jul 2011 08:09:17 -0600 Brian Paul bri...@vmware.com wrote: On 07/15/2011 02:59 PM, Pekka Paalanen wrote: On Fri, 15 Jul 2011 12:22:41 -0600 Brian Paulbri...@vmware.com wrote: On 07/15/2011 10:07 AM, Dave Airlie wrote: On Fri, Jul 15, 2011 at 4:10 AM, Brian Paulbrian.e.p...@gmail.com wrote: The map-texture-image-v4 branch that I just pushed implements this change. It really cleaned things up for the better and will lead to a few more follow-on improvements. There's no obvious regressions with swrast or the gallium drivers. I updated the intel driver code and tested i915 and it seems OK too, but I didn't do a full piglit run on it. I also updated the legacy r600 driver in case anyone cares but didn't do any testing of it. I didn't update any of the other legacy DRI drivers. Would anyone object if we simply stop building mach64, r128, unichrome, sis, etc? I'd be happy to remove those drivers altogether for that matter. we could EOL those in 7.11, and if anyone wants to ship them, they can just build 7.11 for them. Sounds good to me. I think we'd only keep the swrast, intel and maybe r300/r600 drivers. Opinions? Um, don't kill nouveau_vieux, please. Does the old nouveau driver support some GPUs that the gallium nv50/nvc0 drivers don't support? Yes. Like Corbin said, 'nouveau_vieux' is for NV04-NV2x, while the gallium driver 'nouveau' supports NV30 and later. http://nouveau.freedesktop.org/wiki/MesaDrivers I run a couple of machines with that driver and have to disagree with that decision as well. If we want to keep the older driver someone will need to volunteer to update the code to support the new driver hooks. Sorry, I cannot promise that. Nouveau_vieux seems to have been missing a maintainer for some time now. That would be me. I admit that because of personal/work reasons I've had to keep myself somewhat out of the loop during the last couple of months, that doesn't mean that I've disappeared or stopped answering my mail. Coincidentally nouveau's texture handling has always been structured around two teximage map/unmap hooks (e.g. compare nouveau_teximage() and the look of _mesa_store_teximage2d() after the API change), and AFAICT the changes would be for the most part trivial, but still, if no-one else wants or knows how to do it (isn't fixing up the drivers the responsibility of whoever changes the API?), I'll get back to it as soon as I can. Thanks. pgpSwVvpTVHIM.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/5] nouveau: Fix checkpatch.pl error messages
Emil Velikov emil.l.veli...@gmail.com writes:
Fix the following message
'ERROR: trailing statements should be on next line'
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_display.c | 20 +++--
drivers/gpu/drm/nouveau/nouveau_mem.c | 12 --
drivers/gpu/drm/nouveau/nouveau_object.c |8 +++-
drivers/gpu/drm/nouveau/nv50_display.c| 64 +---
drivers/gpu/drm/nouveau/nv50_fb.c |9 +++-
drivers/gpu/drm/nouveau/nv50_grctx.c |3 +-
drivers/gpu/drm/nouveau/nvc0_grctx.c |4 +-
7 files changed, 88 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 764c15d..2dca746 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -91,12 +91,22 @@ nouveau_framebuffer_init(struct drm_device *dev,
nv_fb-r_dma = NvEvoVRAM_LP;
switch (fb-depth) {
- case 8: nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_8; break;
- case 15: nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_15; break;
- case 16: nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_16; break;
+ case 8:
+ nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_8;
+ break;
+ case 15:
+ nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_15;
+ break;
+ case 16:
+ nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_16;
+ break;
case 24:
- case 32: nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_24; break;
- case 30: nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_30; break;
+ case 32:
+ nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_24;
+ break;
+ case 30:
+ nv_fb-r_format = NV50_EVO_CRTC_FB_DEPTH_30;
+ break;
default:
NV_ERROR(dev, unknown depth %d\n, fb-depth);
return -EINVAL;
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index 8af07c4..12f511e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -432,10 +432,14 @@ nouveau_mem_vram_init(struct drm_device *dev)
u32 rsvd;
/* estimate grctx size, the magics come from nv40_grctx.c */
- if (dev_priv-chipset == 0x40) rsvd = 0x6aa0 * vs;
- else if (dev_priv-chipset 0x43) rsvd = 0x4f00 * vs;
- else if (nv44_graph_class(dev)) rsvd = 0x4980 * vs;
- elsersvd = 0x4a40 * vs;
+ if (dev_priv-chipset == 0x40)
+ rsvd = 0x6aa0 * vs;
+ else if (dev_priv-chipset 0x43)
+ rsvd = 0x4f00 * vs;
+ else if (nv44_graph_class(dev))
+ rsvd = 0x4980 * vs;
+ else
+ rsvd = 0x4a40 * vs;
rsvd += 16 * 1024;
rsvd *= dev_priv-engine.fifo.channels;
diff --git a/drivers/gpu/drm/nouveau/nouveau_object.c
b/drivers/gpu/drm/nouveau/nouveau_object.c
index 823800d..a89256e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_object.c
+++ b/drivers/gpu/drm/nouveau/nouveau_object.c
@@ -416,9 +416,13 @@ nv50_gpuobj_dma_init(struct nouveau_gpuobj *obj, u32
offset, int class,
flags0 |= 0x0010;
switch (access) {
- case NV_MEM_ACCESS_RO: flags0 |= 0x0004; break;
+ case NV_MEM_ACCESS_RO:
+ flags0 |= 0x0004;
+ break;
case NV_MEM_ACCESS_RW:
- case NV_MEM_ACCESS_WO: flags0 |= 0x0008; break;
+ case NV_MEM_ACCESS_WO:
+ flags0 |= 0x0008;
+ break;
default:
break;
}
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index 75a376c..031116c 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -629,8 +629,12 @@ nv50_display_unk10_handler(struct drm_device *dev)
continue;
switch ((mc 0x0f00) 8) {
- case 0: type = OUTPUT_ANALOG; break;
- case 1: type = OUTPUT_TV; break;
+ case 0:
+ type = OUTPUT_ANALOG;
+ break;
+ case 1:
+ type = OUTPUT_TV;
+ break;
default:
NV_ERROR(dev, invalid mc, DAC-%d: 0x%08x\n, i, mc);
goto ack;
@@ -652,12 +656,24 @@ nv50_display_unk10_handler(struct drm_device *dev)
continue;
switch ((mc 0x0f00) 8) {
-
Re: [Nouveau] [PATCH] drm/nouveau: fix oops on unload with disabled LVDS panel
Marcin Slusarz marcin.slus...@gmail.com writes:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35135
BUG: unable to handle kernel NULL pointer dereference at 02d8
IP: [f83694af] nv04_dfp_restore+0x7f/0xd0 [nouveau]
(...)
Call Trace:
[f8372208] nv04_display_destroy+0xa8/0x140 [nouveau]
[f830344a] nouveau_unload+0x2a/0x160 [nouveau]
[f80d98fb] drm_put_dev+0xbb/0x1b0 [drm]
[f8301025] nouveau_pci_remove+0x15/0x20 [nouveau]
[c1292ad4] pci_device_remove+0x44/0xf0
[c13339d1] __device_release_driver+0x51/0xb0
[c133401f] driver_detach+0x8f/0xa0
[c13338a3] bus_remove_driver+0x63/0xa0
[c13340a9] driver_unregister+0x49/0x80
[c1182f84] ? sysfs_remove_file+0x14/0x20
[c1292bb2] pci_unregister_driver+0x32/0x90
[c109b1da] ? __stop_machine+0x5a/0x70
[f80d3f93] drm_exit+0x83/0x90 [drm]
[f837875d] nouveau_exit+0x1b/0x8be [nouveau]
[c1087b5b] sys_delete_module+0x13b/0x1f0
[c1104c3e] ? do_munmap+0x1fe/0x280
[c1104780] ? arch_unmap_area_topdown+0x0/0x20
[c15096f4] syscall_call+0x7/0xb
Reported-by: Francesco Marella francesco.mare...@gmail.com
Tested-by: Francesco Marella francesco.mare...@gmail.com
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nv04_dfp.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv04_dfp.c
b/drivers/gpu/drm/nouveau/nv04_dfp.c
index c82db37..b985ab3 100644
--- a/drivers/gpu/drm/nouveau/nv04_dfp.c
+++ b/drivers/gpu/drm/nouveau/nv04_dfp.c
@@ -579,15 +579,24 @@ static void nv04_dfp_restore(struct drm_encoder
*encoder)
struct drm_device *dev = encoder-dev;
struct drm_nouveau_private *dev_priv = dev-dev_private;
int head = nv_encoder-restore.head;
+ struct nouveau_connector *connector;
+ struct drm_display_mode *native_mode;
if (nv_encoder-dcb-type == OUTPUT_LVDS) {
- struct drm_display_mode *native_mode =
nouveau_encoder_connector_get(nv_encoder)-native_mode;
- if (native_mode)
- call_lvds_script(dev, nv_encoder-dcb, head,
LVDS_PANEL_ON,
- native_mode-clock);
- else
+ connector = nouveau_encoder_connector_get(nv_encoder);
+ if (!connector) {
+ NV_ERROR(dev, No connector for LVDS encoder. Skipping
restore.\n);
+ goto out;
+ }
+
+ native_mode = connector-native_mode;
+ if (!native_mode) {
NV_ERROR(dev, Not restoring LVDS without native
mode\n);
+ goto out;
+ }
+ call_lvds_script(dev, nv_encoder-dcb, head, LVDS_PANEL_ON,
+ native_mode-clock);
} else if (nv_encoder-dcb-type == OUTPUT_TMDS) {
int clock = nouveau_hw_pllvals_to_clk
(dev_priv-saved_reg.crtc_reg[head].pllvals);
@@ -595,6 +604,7 @@ static void nv04_dfp_restore(struct drm_encoder *encoder)
run_tmds_table(dev, nv_encoder-dcb, head, clock);
}
+out:
nv_encoder-last_dpms = NV_DPMS_CLEARED;
}
Thanks, I've pushed a slightly simplified version of this patch.
pgp6JVI0JInSU.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression
Marcin Slusarz marcin.slus...@gmail.com writes:
On Tue, Mar 08, 2011 at 05:22:52PM +0100, Francisco Jerez wrote:
Marcin Slusarz marcin.slus...@gmail.com writes:
On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote:
Marcin Slusarz marcin.slus...@gmail.com writes:
On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote:
On Mon, 2011-03-07 at 18:18 +, Maarten Maathuis wrote:
On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote:
Combination of locking and interchannel synchronization changes
uncovered poor behaviour of nouveau_fence_wait, which on HZ=100
configuration could waste up to 10 ms per call.
Depending on application, it lead to 10-30% FPS regression.
To fix it, shorten thread sleep time to 0.1 ms and ensure
spinning happens for at least one *full* tick.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 221b846..75ba5e2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -27,6 +27,9 @@
#include drmP.h
#include drm.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+
#include nouveau_drv.h
#include nouveau_ramht.h
#include nouveau_dma.h
@@ -230,9 +233,12 @@ int
__nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy,
bool intr)
{
unsigned long timeout = jiffies + (3 * DRM_HZ);
- unsigned long sleep_time = jiffies + 1;
+ unsigned long sleep_time = jiffies + 2;
+ ktime_t t;
int ret = 0;
+ t = ktime_set(0, NSEC_PER_MSEC / 10);
+
while (1) {
if (__nouveau_fence_signalled(sync_obj, sync_arg))
break;
@@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void
*sync_arg, bool lazy, bool intr)
__set_current_state(intr ? TASK_INTERRUPTIBLE
: TASK_UNINTERRUPTIBLE);
if (lazy time_after_eq(jiffies, sleep_time))
- schedule_timeout(1);
+ schedule_hrtimeout(t, HRTIMER_MODE_REL);
if (intr signal_pending(current)) {
ret = -ERESTARTSYS;
--
1.7.4.rc3
ping again
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
This looks ok to me, but I would like to get Ben Skeggs ok on this
one
as well. So i've CC'ed him, hopefully he'll notice :-)
Ah sorry, I have actually looked at this quite a while back but came to
no solid conclusion.
While yes, I did see some minor performance improvement from it, I also
notice that now we once again get 100% CPU usage while an app is
waiting
for the GPU a lot..
It's not minor performance improvement:
without this patch (FPS):
nexuiz:53
wop: 181
tremulous: 157
wsw0.5:89
glxgears: 730
with:
nexuiz:63 (+18%)
wop: 248 (+37%)
tremulous: 156 (-0.6%)
wsw0.5:91 (+2%)
glxgears: 1054 (+44%)
Ok, so you are worried about CPU usage... Let's see what will happen if
I remove spinning added by drm/nouveau: Spin for a bit in
nouveau_fence_wait() before yielding the CPU.
reduced version (attached):
nexuiz:62
wop: 248
trem: 157
wsw0.5:90
glxgears: 1055
Good enough?
Remember to exercise some software fallbacks as well (e.g. something
using core fonts), software fallbacks were the main users of the
spinning you've removed.
corefonts are pretty fast (measured time dmesg):
without (spinning + timeout 10ms): 0.08s
with (spinning + hrtimeout 0.1ms): 0.08s
reduced (no spinning + hrtimeout 0.1ms): 0.25s
old (no spinning + timeout 10ms): 13s
Ah, so it's still trading one performance regression for another, and
you could make everyone happy at the same time.
So I think no spinning + hrtimeout 0.1ms is a reasonable compromise...
What's the CPU usage difference between the spinning and the no-spinning
cases?
1 cpu set to performance mode
spinning + hrtimeout 0.1ms:
FPS usr sys
nexuiz:63 46.60 + 52.36
wop: 248 57.54 + 41.99
trem: 156 92.40 + 7.30
wsw0.5:91 52.91 + 46.37
glxgears:1054 10.00 + 90.00
corefonts:42.86 + 54.29 0.08s(time)
So it fills the CPU in almost 100%...
no spinning + hrtimeout 0.1ms
Re: [Nouveau] [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression
Marcin Slusarz marcin.slus...@gmail.com writes:
On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote:
On Mon, 2011-03-07 at 18:18 +, Maarten Maathuis wrote:
On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz marcin.slus...@gmail.com
wrote:
On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote:
Combination of locking and interchannel synchronization changes
uncovered poor behaviour of nouveau_fence_wait, which on HZ=100
configuration could waste up to 10 ms per call.
Depending on application, it lead to 10-30% FPS regression.
To fix it, shorten thread sleep time to 0.1 ms and ensure
spinning happens for at least one *full* tick.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 221b846..75ba5e2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -27,6 +27,9 @@
#include drmP.h
#include drm.h
+#include linux/ktime.h
+#include linux/hrtimer.h
+
#include nouveau_drv.h
#include nouveau_ramht.h
#include nouveau_dma.h
@@ -230,9 +233,12 @@ int
__nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool
intr)
{
unsigned long timeout = jiffies + (3 * DRM_HZ);
- unsigned long sleep_time = jiffies + 1;
+ unsigned long sleep_time = jiffies + 2;
+ ktime_t t;
int ret = 0;
+ t = ktime_set(0, NSEC_PER_MSEC / 10);
+
while (1) {
if (__nouveau_fence_signalled(sync_obj, sync_arg))
break;
@@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void
*sync_arg, bool lazy, bool intr)
__set_current_state(intr ? TASK_INTERRUPTIBLE
: TASK_UNINTERRUPTIBLE);
if (lazy time_after_eq(jiffies, sleep_time))
- schedule_timeout(1);
+ schedule_hrtimeout(t, HRTIMER_MODE_REL);
if (intr signal_pending(current)) {
ret = -ERESTARTSYS;
--
1.7.4.rc3
ping again
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
This looks ok to me, but I would like to get Ben Skeggs ok on this one
as well. So i've CC'ed him, hopefully he'll notice :-)
Ah sorry, I have actually looked at this quite a while back but came to
no solid conclusion.
While yes, I did see some minor performance improvement from it, I also
notice that now we once again get 100% CPU usage while an app is waiting
for the GPU a lot..
It's not minor performance improvement:
without this patch (FPS):
nexuiz:53
wop: 181
tremulous: 157
wsw0.5:89
glxgears: 730
with:
nexuiz:63 (+18%)
wop: 248 (+37%)
tremulous: 156 (-0.6%)
wsw0.5:91 (+2%)
glxgears: 1054 (+44%)
Ok, so you are worried about CPU usage... Let's see what will happen if
I remove spinning added by drm/nouveau: Spin for a bit in
nouveau_fence_wait() before yielding the CPU.
reduced version (attached):
nexuiz:62
wop: 248
trem: 157
wsw0.5:90
glxgears: 1055
Good enough?
Remember to exercise some software fallbacks as well (e.g. something
using core fonts), software fallbacks were the main users of the
spinning you've removed.
Anyway, software fallbacks and occlusion queries are the only two places
(that I can think of now) where we need the low latency your patch
gives, and, as Ben already pointed out, we probably want to keep CPU
usage at minimum in every other case. As a middle ground, the lazy
flag (or rather, a hog flag?) could be exposed all the way up to
userspace, and those two cases fixed to set the flag differently.
What do you think?
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression
Combination of locking and interchannel synchronization changes
uncovered poor behaviour of nouveau_fence_wait, which on HZ=100
configuration could waste up to 10 ms per call.
Depending on application, it lead to 10-30% FPS regression.
To fix it, shorten thread sleep time to 0.1 ms.
Additionally, remove spinning (added by drm/nouveau: Spin for
a bit in nouveau_fence_wait() before yielding the CPU), because
it's not needed anymore.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index a244702..010243b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++
Re: [Nouveau] TDMS bandwidth limits
Edgar Fuß e...@math.uni-bonn.de writes: So my problem continues. They're based on what the nvidia proprietary driver itself refuses to do, I see, thanks. though, I'm not 100% sure that I had nv44 in my sample when I made that change. Looks like it limits to 155M in the nv44 case too, so your change is totally correct. It might be using a reduced-blanking mode, Indeed it does, thanks. I had ruled out this too early as highly improbable. check your Xorg.0.log to be sure. See the -logverbose option if you don't get all the timings printed out with the default verbosity level. It does tell at least on level 9, thanks. However, what it doesn't tell is the timing actually used. Anyone more familiar with the relevant reverse engineering methods (MmioTrace or whatever) to find out? A register dump [1] would be the easiest way to find out the exact timings, but any standard 1600x1200 reduced-blanking mode should do it. The other problem is that nouveaufb doesn't (like matroxfb) provide a method of specifying the exact timing to use (and I would presumably need it in order not to change between FB console and X11). You could just use the same CVT reduced-blanking mode on both X and the framebuffer console. One would come to think that video=1600x1200RM would result in a reduced-blanking mode, but drm.debug=7 shows it actually does not. Reading the source of drm_fb_helper.c reveals that it's almost impossible to achieve rb=1. Well, that works for me, can I have a look at your kernel logs? Any chance of implementing implicit reduced blanking in nouveau? If someone could hint me at where to architecturally correctly put it in I will be happy to start implementing it myself. I'm afraid more people than me will run into this and will regard the (absolutely plausible) TDMS bandwidth limiting as a regression (Help! Help! My 1600x1200 used to work, but now it's broken!) when there's no reduced-blanking workaround. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau [1] http://cgit.freedesktop.org/~currojerez/tvdump/ pgpjvsOPDSx3g.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] TDMS bandwidth limits
Edgar Fuß e...@math.uni-bonn.de writes: I'm curious what the TDMS bandwidth limit values in get_tmds_link_bandwidth() are based on. They're based on what the nvidia proprietary driver itself refuses to do, though, I'm not 100% sure that I had nv44 in my sample when I made that change. We're using chipset == 44 cards that happily run 1600x1200@60 using the propriety driver and which also used to work with nouveau up to Linux 2.6.36.2. Since 2.6.37, nouveau refuses to use that mode because the required 163M pixel clock exceeds the computed TDMS bandwidth of 155M (earlier versions allowed for 165M regardless of chipset value). Although I cannot tell for sure which timing the closed-source driver runs 1600x1200@60 with on these monitors, I find it unlikely that it uses some built-in, non-EDID timing requiring a lower pixel clock. I also don't suspect NVidia running their own chips above specs. It might be using a reduced-blanking mode, check your Xorg.0.log to be sure. See the -logverbose option if you don't get all the timings printed out with the default verbosity level. So either NVidia doesn't disclose the specs even to their own programmers, the values in get_tmds_link_bandwidth() are wrong, or, more likely, I'm missing something. Patching get_tmds_link_bandwidth() to allow for 165M already for chipset = 0x44 appears to work. However, I don't feel comfortable with stretching rates above spec. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgpusKsjumsjM.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [libdrm PATCH 1/3] nouveau: remove unused OUT_RELOC2 and OUT_RELOCr
Marcin Slusarz marcin.slus...@gmail.com writes:
---
nouveau/nouveau_pushbuf.h | 17 -
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/nouveau/nouveau_pushbuf.h b/nouveau/nouveau_pushbuf.h
index 2a98789..70d0f28 100644
--- a/nouveau/nouveau_pushbuf.h
+++ b/nouveau/nouveau_pushbuf.h
@@ -109,15 +109,6 @@ OUT_RELOC(struct nouveau_channel *chan, struct
nouveau_bo *bo,
data, 0, flags, vor, tor);
}
-static __inline__ int
-OUT_RELOC2(struct nouveau_channel *chan, struct nouveau_bo *bo,
-unsigned data, unsigned data2, unsigned flags,
-unsigned vor, unsigned tor)
-{
- return nouveau_pushbuf_emit_reloc(chan, chan-cur++, bo,
- data, data2, flags, vor, tor);
-}
-
/* Raw data + flags depending on FB/TT buffer */
static __inline__ int
OUT_RELOCd(struct nouveau_channel *chan, struct nouveau_bo *bo,
@@ -143,14 +134,6 @@ OUT_RELOCl(struct nouveau_channel *chan, struct
nouveau_bo *bo,
return OUT_RELOC(chan, bo, delta, flags | NOUVEAU_BO_LOW, 0, 0);
}
-/* Low 32-bits of offset + GPU linear access range info */
-static __inline__ int
-OUT_RELOCr(struct nouveau_channel *chan, struct nouveau_bo *bo,
-unsigned delta, unsigned size, unsigned flags)
-{
- return OUT_RELOC2(chan, bo, delta, size, flags | NOUVEAU_BO_LOW, 0, 0);
-}
-
/* High 32-bits of offset */
static __inline__ int
OUT_RELOCh(struct nouveau_channel *chan, struct nouveau_bo *bo,
This patch series looks like a good clean-up. Ben, do you have any
additional changes in mind for the libdrm API? (If you do they could go
in together to avoid annoying users more often than necessary)
pgpkBoeu2H8Yo.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Add PFIFO and PGRAPH pausing methods
Martin Peres martin.pe...@free.fr writes:
Hi,
I'm still working on getting the reclocking work done right. There are
several parts I identify:
- Pausing PFIFO (with its caches), pause PGRAPH and wait for idle
- Stop some PLL (I guess it is more, physically disconnect them from
the engines) using the 0xc040 register.
- reclock memory
- reclock the other engines
- Make sure the display doesn't blow up
Depending on the cards, I have completed all of the steps or none.
Anyway, pausing PFIFO and PGRAPH works well on all the card I tested
and so, I would like it to be pushed.
I have a new theory upon the PLL_SUPERVISOR(0xc040) that I want to
test. When I'm done with this, I'll put together a patch for it and
continue on the other steps.
Please provide me with some feedback on the patch or push it if
nothing bothers you.
Thanks, some comments inline.
Martin
PS: I'm quite busy at the moment, I'll write an in-depth mail when
I've verified my theories and got proper support on other cards than
the nv86 ones.
From f7ad98f4a857dd4b1892712d15f93c13eb0669e3 Mon Sep 17 00:00:00 2001
From: Martin Peres martin.pe...@ensi-bourges.fr
Date: Mon, 10 Jan 2011 00:44:05 +0100
Subject: [PATCH] Pause PFIFO and PGRAPH before reclocking
Signed-off-by: Martin Peres martin.pe...@ensi-bourges.fr
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 15 +++
drivers/gpu/drm/nouveau/nouveau_pm.c| 32 ++-
drivers/gpu/drm/nouveau/nouveau_reg.h |3 +
drivers/gpu/drm/nouveau/nouveau_state.c | 51 +++-
drivers/gpu/drm/nouveau/nv04_fifo.c | 16 +++
drivers/gpu/drm/nouveau/nv50_fifo.c | 20 +
drivers/gpu/drm/nouveau/nv50_graph.c| 66
+++
7 files changed, 200 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 6d749b7..b0c52c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -359,6 +359,12 @@ struct nouveau_fifo_engine {
int (*load_context)(struct nouveau_channel *);
int (*unload_context)(struct drm_device *);
void (*tlb_flush)(struct drm_device *dev);
+
+ int (*pause)(struct drm_device *);
+ void (*unpause)(struct drm_device *);
+
+ int (*cache_pause)(struct drm_device *);
+ void (*cache_unpause)(struct drm_device *);
You could fold fifo-cache_pause() into fifo-pause(). I don't see any
reason to have two separate pairs of callbacks here, they're always
going to be called one after the other.
};
struct nouveau_pgraph_engine {
@@ -383,6 +389,9 @@ struct nouveau_pgraph_engine {
void (*tlb_flush)(struct drm_device *dev);
void (*set_tile_region)(struct drm_device *dev, int i);
+
+ int (*pause)(struct drm_device *);
+ void (*unpause)(struct drm_device *);
};
struct nouveau_display_engine {
@@ -1094,6 +1103,8 @@ extern void nv04_fifo_destroy_context(struct
nouveau_channel *);
extern int nv04_fifo_load_context(struct nouveau_channel *);
extern int nv04_fifo_unload_context(struct drm_device *);
extern void nv04_fifo_isr(struct drm_device *);
+extern void nv04_fifo_cache_pause(struct drm_device *dev);
+extern void nv04_fifo_cache_unpause(struct drm_device *dev);
/* nv10_fifo.c */
extern int nv10_fifo_init(struct drm_device *);
@@ -1117,6 +1128,8 @@ extern void nv50_fifo_destroy_context(struct
nouveau_channel *);
extern int nv50_fifo_load_context(struct nouveau_channel *);
extern int nv50_fifo_unload_context(struct drm_device *);
extern void nv50_fifo_tlb_flush(struct drm_device *dev);
+extern int nv50_fifo_pause(struct drm_device *);
+extern void nv50_fifo_unpause(struct drm_device *);
/* nvc0_fifo.c */
extern int nvc0_fifo_init(struct drm_device *);
@@ -1189,6 +1202,8 @@ extern int nv50_graph_unload_context(struct drm_device
*);
extern int nv50_grctx_init(struct nouveau_grctx *);
extern void nv50_graph_tlb_flush(struct drm_device *dev);
extern void nv86_graph_tlb_flush(struct drm_device *dev);
+extern int nv50_graph_pause(struct drm_device *dev);
+extern void nv50_graph_unpause(struct drm_device *dev);
extern struct nouveau_enum nv50_data_error_names[];
/* nvc0_graph.c */
diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c
b/drivers/gpu/drm/nouveau/nouveau_pm.c
index fb846a3..233deec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_pm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_pm.c
@@ -59,6 +59,7 @@ nouveau_pm_perflvl_set(struct drm_device *dev, struct
nouveau_pm_level *perflvl)
{
struct drm_nouveau_private *dev_priv = dev-dev_private;
struct nouveau_pm_engine *pm = dev_priv-engine.pm;
+ unsigned long flags;
int ret;
if (perflvl == pm-cur)
@@ -72,13 +73,42 @@ nouveau_pm_perflvl_set(struct drm_device *dev, struct
nouveau_pm_level *perflvl)
}
}
+ /* Do
Re: [Nouveau] [kernel PATCH] drm/nouveau: add NOUVEAU_GEM_RELOC_HILO
Marcin Slusarz marcin.slus...@gmail.com writes:
add new relocation flag which allows to halving number of relocation
entries on = nv50 cards
I suspect that this change is unnecessary. If you're actually seeing a
performance improvement (I guess you are?), it's very likely to be
masking the actual root of the problem -- last time I checked the nv50
gallium pipe driver was rather careless about reloc re-submission (it
re-submits the whole reloc chain once for every draw call instead of
once for every pushbuf flush), and nouveau_reloc_emit() and friends are
very unoptimized.
I'm betting that using HILO or not will make pretty much no difference
once those two places are fixed :).
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 22 +++---
include/drm/nouveau_drm.h |1 +
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 9a1fdcf..2e21412 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -507,6 +507,7 @@ nouveau_gem_pushbuf_reloc_apply(struct drm_device *dev,
struct drm_nouveau_gem_pushbuf_bo *b;
struct nouveau_bo *nvbo;
uint32_t data;
+ uint32_t data2;
if (unlikely(r-bo_index req-nr_buffers)) {
NV_ERROR(dev, reloc bo index invalid\n);
@@ -544,17 +545,22 @@ nouveau_gem_pushbuf_reloc_apply(struct drm_device *dev,
if (r-flags NOUVEAU_GEM_RELOC_LOW)
data = b-presumed.offset + r-data;
- else
- if (r-flags NOUVEAU_GEM_RELOC_HIGH)
+ else if (r-flags NOUVEAU_GEM_RELOC_HIGH)
data = (b-presumed.offset + r-data) 32;
- else
+ else if (r-flags NOUVEAU_GEM_RELOC_HILO) {
+ data = (b-presumed.offset + r-data) 32;
+ data2 = b-presumed.offset + r-data;
+ } else
data = r-data;
if (r-flags NOUVEAU_GEM_RELOC_OR) {
- if (b-presumed.domain == NOUVEAU_GEM_DOMAIN_GART)
- data |= r-tor;
- else
- data |= r-vor;
+ if (b-presumed.domain == NOUVEAU_GEM_DOMAIN_GART) {
+ data |= r-tor;
+ data2 |= r-tor;
+ } else {
+ data |= r-vor;
+ data2 |= r-vor;
+ }
}
spin_lock(nvbo-bo.lock);
@@ -566,6 +572,8 @@ nouveau_gem_pushbuf_reloc_apply(struct drm_device *dev,
}
nouveau_bo_wr32(nvbo, r-reloc_bo_offset 2, data);
+ if (r-flags NOUVEAU_GEM_RELOC_HILO)
+ nouveau_bo_wr32(nvbo, (r-reloc_bo_offset 2) + 1,
data2);
}
kfree(reloc);
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index bc5590b..126ea8a 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -137,6 +137,7 @@ struct drm_nouveau_gem_pushbuf_bo {
#define NOUVEAU_GEM_RELOC_LOW (1 0)
#define NOUVEAU_GEM_RELOC_HIGH (1 1)
#define NOUVEAU_GEM_RELOC_OR (1 2)
+#define NOUVEAU_GEM_RELOC_HILO (1 3)
#define NOUVEAU_GEM_MAX_RELOCS 1024
struct drm_nouveau_gem_pushbuf_reloc {
uint32_t reloc_bo_index;
pgpn658v5svsE.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] change temp sensor defaults to neutral ones
Lucas Stach d...@lynxeye.de writes: The attached patch deletes some defaults which are not really defaults and changes the standard values to calculation neutral ones. I discussed the matter with mupuf on irc and we agreed on this solution. Hi, I'm attaching the BIOS dump from an nv4a card that needs these sensor defaults (IIRC it's missing the temperature offset/slope entries). --lynxeye ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau nv4a_bios.rom.xz Description: Binary data pgpH7JVYntsbS.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] CRTC video scanout position for high precision vblank timestamping?
Mario Kleiner mario.klei...@tuebingen.mpg.de writes: On 12/29/2010 10:44 AM, Ben Skeggs wrote: On Wed, 2010-12-29 at 10:37 +0100, Maarten Maathuis wrote: [...] In my infinite wisdom i swapped the vertical and horizontal regs, these are the right ones: 0x616340: CRTC0 horizontal scanline (lower 16 bits, upper 16 bits is a counter that increments every display cycle) 0x616344: CRTC0 vertical scanline (lower 16 bits, upper 16 bits empty) 0x616B40: CRTC1 horizontal scanline 0x616B44: CRTC1 vertical scanline Ah, I should've waited 10 minutes before doing the same here. Ah well, I can confirm at least on NV84, I can't imagine it differs at all on any nv50+ board either. I can confirm those registers are still there on NVA8. Ben. Wow, that was fast! Thanks! I'll get some good sleep now and then give it a try on my GF-8800. This is probably also useful to implement the .get_vblank_counter() hook properly. Currently it hooks up to drm_vblank_count() which is problematic, as .get_vblank_counter() is meant to query the hardware for the purpose of reinitializing drm_vblank_count() after a long vblank irq off period. I'll let you know how it goes, hopefully with some nice patches asap. If somebody knows about similar NV40 and earlier registers, keep it coming :-) On nv04-nv4x class hardware there's a scanline counter in the lower 12 bits of 0x600808 (0x602808 for the second CRTC), bit 16 lights up during the vblank period. I don't think I've ever seen a hardware frame counter there, but they might have one. Tracing what the nvidia blob does for SGI_video_sync and friends would be your best bet I guess. Is the range from NV_PCRTC0_OFFSET to NV_PCRTC0_OFFSET + NV_PCRTC0_SIZE a good starting point for a search on NV40 and earlier? thanks, -mario ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgp2b9kvEm5Ii.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Kernel patch: validate nouveau_channel_get id argument
Michel Hermier michel.herm...@gmail.com writes: For my culture, why did you not changed the type to uint32_t like in my original patch ? As I told you before, those changes went over the 80 column limit so I just left them out. I hope you don't mind, the modified patch should do the same thing as the original one for all practical purposes. Also looking at include/drm/nouveau_drm.h, I see some inconsistant type for channel in ioctls structures ? Right, explicitly sized integers are usually the preferred choice in the IOCTL API. 2010/12/25 Francisco Jerez curroje...@riseup.net: Michel Hermier michel.herm...@gmail.com writes: Second try ^^ I'm not used at all at preparing patch for kernel Thanks. I've pushed it with a couple of minor fixes. pgpb87sbrYx7P.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Kernel patch: validate nouveau_channel_get id argument
Michel Hermier michel.herm...@gmail.com writes:
Hi,
While hacking libdrm I triggered a kernel oups due to a non checked
argument from user land.
In nouveau_ioctl_notifier_alloc, nouveau_channel_get is invoked, but
it doesn't validate the na-channel input argument. The attached patch
validates the channel index, and change it's type to uint32_t since it
is an index after all.
Thank you, some minor comments inline.
Cheers,
Michel
From dc00e5ccce3f10e51ae143d6dda6aa8febab271d Mon Sep 17 00:00:00 2001
From: Michel Hermier herm...@frugalware.org
Date: Fri, 24 Dec 2010 14:49:13 +0100
Subject: [PATCH] Fix channel nouveau_channel_get index type and check it's
value.
We usually prefix our kernel commit messages with drm/nouveau: or
something similar, to tell them apart from the huge kernel commit
flow. Also you made a small typo in it's.
Signed-off-by line missing. You should have a look at
Documentation/SubmittingPatches and Documentation/CodingStyle, if
you haven't already.
---
drivers/gpu/drm/nouveau/nouveau_channel.c |5 -
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c
b/drivers/gpu/drm/nouveau/nouveau_channel.c
index e37977d..bc07a61 100644
--- a/drivers/gpu/drm/nouveau/nouveau_channel.c
+++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
@@ -247,12 +247,15 @@ nouveau_channel_get_unlocked(struct nouveau_channel
*ref)
}
struct nouveau_channel *
-nouveau_channel_get(struct drm_device *dev, struct drm_file *file_priv, int
id)
+nouveau_channel_get(struct drm_device *dev, struct drm_file *file_priv,
uint32_t id)
This goes above the 80 column limit. Anyway I'd leave this line alone,
we're already using ints as channel indices in most places.
{
struct drm_nouveau_private *dev_priv = dev-dev_private;
struct nouveau_channel *chan;
unsigned long flags;
+ if (unlikely(id = NOUVEAU_MAX_CHANNEL_NR))
+ return ERR_PTR(-EINVAL);
+
spin_lock_irqsave(dev_priv-channels.lock, flags);
chan = nouveau_channel_get_unlocked(dev_priv-channels.ptr[id]);
spin_unlock_irqrestore(dev_priv-channels.lock, flags);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index e815756..ec3eed2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -870,7 +870,7 @@ extern int nouveau_channel_alloc(struct drm_device *dev,
extern struct nouveau_channel *
nouveau_channel_get_unlocked(struct nouveau_channel *);
extern struct nouveau_channel *
-nouveau_channel_get(struct drm_device *, struct drm_file *, int id);
+nouveau_channel_get(struct drm_device *, struct drm_file *, uint32_t id);
extern void nouveau_channel_put_unlocked(struct nouveau_channel **);
extern void nouveau_channel_put(struct nouveau_channel **);
extern void nouveau_channel_ref(struct nouveau_channel *chan,
--
1.7.3.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
pgpep7a0rTSl7.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nv04_exa: kill useless WAIT_RING
Xavier Chantry chantry.xav...@gmail.com writes: --- src/nv04_exa.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/nv04_exa.c b/src/nv04_exa.c index 2760d4b..bc20ca3 100644 --- a/src/nv04_exa.c +++ b/src/nv04_exa.c @@ -148,7 +148,6 @@ NV04EXASolid (PixmapPtr pPixmap, int x1, int y1, int x2, int y2) int width = x2-x1; int height = y2-y1; - WAIT_RING (chan, 3); BEGIN_RING(chan, rect, NV04_GDI_RECTANGLE_TEXT_UNCLIPPED_RECTANGLE_POINT(0), 2); OUT_RING (chan, (x1 16) | y1); @@ -278,7 +277,6 @@ NV04EXACopy(PixmapPtr pDstPixmap, int srcX, int srcY, int dstX, int dstY, dstY = 0; } - WAIT_RING (chan, 4); BEGIN_RING(chan, blit, NV01_IMAGE_BLIT_POINT_IN, 3); OUT_RING (chan, (srcY 16) | srcX); OUT_RING (chan, (dstY 16) | dstX); Thanks, pushed. pgpe7NrN8jzDN.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Kernel patch: validate nouveau_channel_get id argument
Michel Hermier michel.herm...@gmail.com writes: Second try ^^ I'm not used at all at preparing patch for kernel Thanks. I've pushed it with a couple of minor fixes. pgp0EnbcRf0wZ.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau_bo_busy not supported in kernel anymore
Lucas Stach d...@lynxeye.de writes: Hi all, I want to bring up this issue again on the mailing list, since it got lost in some irc chat a few days ago. Deadwood came to the channel and noted that 25ee1f0e25195729f28b15f33d74db9ec6afd696 removes support for NOUVEAU_GEM_CPU_PREP_NOBLOCK in the kernel. It doesn't, it just removes the NOBLOCK flag, because it's the default (and only) behavior now. [...] pgpyzCHsEijRQ.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Display goes off when framebuffer enabled and Kernel Panic with fbset
Roger rogerx@gmail.com writes: I think I've found the problem. # echo option nouveau noagp=1 /etc/modprobe.d/nouveau.conf So far, it looks like things have stopped freezing. Another tip for people trouble shooting freezes with nouveau: # echo blacklist nouveau /etc/modprobe.d/blacklist.conf With this, the nouveau module isn't loaded during initial boot, giving the user the option to login remotely to perform a # tail -f /var/log/syslog to hopefully catch an output that might make it through before a hard freeze. Attaching current syslog of the loaded nouveau driver without AGP enabled: Dec 08 15:29:13 [kernel] [drm] Initialized drm 1.1.0 20060810 Dec 08 15:29:13 [kernel] nouveau :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Detected an NV40 generation card (0x04b200b1) Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: ... appears to be valid Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: BIT BIOS found Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Bios version 05.73.22.51 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: TMDS table script pointers not stubbed Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: BIT table 'd' not found Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Found Display Configuration Block version 3.0 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 0028 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Raw DCB entry 1: 03000302 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Raw DCB entry 2: 04011310 0028 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Raw DCB entry 3: 020223f1 00c0c080 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: DCB connector table: VHER 0x30 5 10 2 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: 0: 0x2030: type 0x30 idx 0 tag 0x08 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: 1: 0x0100: type 0x00 idx 1 tag 0xff Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: 2: 0x0210: type 0x10 idx 2 tag 0xff Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: 3: 0x0211: type 0x11 idx 3 tag 0xff Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: 4: 0x0213: type 0x13 idx 4 tag 0xff Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xCDAD Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xD457 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xDB8B Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xDD0F Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xDF1B Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Detected 512MiB VRAM Dec 08 15:29:13 [kernel] [TTM] Zone kernel: Available graphics memory: 446486 kiB. Dec 08 15:29:13 [kernel] [TTM] Zone highmem: Available graphics memory: 516058 kiB. Dec 08 15:29:13 [kernel] [TTM] Initializing pool allocator. Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: 64 MiB GART (aperture) Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Saving VGA fonts Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Allocating FIFO number 0 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 0 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 0) Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Setting dpms mode 3 on tmds encoder (output 1) Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 2) Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Setting dpms mode 3 on TV encoder (output 3) Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: allocated 1280x1024 fb: 0x48000, bo f675aa00 Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: 0xC210: Parsing digital output script table Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Setting dpms mode 0 on tmds encoder (output 1) Dec 08 15:29:13 [kernel] [drm] nouveau :01:00.0: Output DVI-I-1 is running on CRTC 0 using output A Dec 08 15:29:13 [kernel] Console: switching to colour frame buffer device 160x64 Dec 08 15:29:13 [kernel] fb0: nouveaufb frame buffer device Dec 08 15:29:13 [kernel] drm: registered panic notifier Dec 08 15:29:13 [kernel] [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 The slight difference I see aside from no AGP, is 64 MiB looks to be reserved for GART from the usual 4 MiB AGP. Probably nothing. Still working to get kdump working here. Again, nothing via KGDB on serial console. Do you get the same kind of AGP problems with the other nvidia cards you said you had access
Re: [Nouveau] [PATCH 2/2] nvfx: reset nvfx-hw_zeta
Xavier Chantry chantry.xav...@gmail.com writes:
If nvfx_framebuffer prepare and validate were called successively with
fb-zsbuf not NULL and then NULL, nvfx-hw_zeta would contain garbage and
this would cause failures in nvfx_framebuffer_relocate/OUT_RELOC(hw_zeta).
This was triggered by piglit/texwrap 2D GL_DEPTH_COMPONENT24 and caused
first a 'write to user buffer!!' error in libdrm and then worse things.
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
Thanks, both patches pushed.
---
src/gallium/drivers/nvfx/nvfx_state_fb.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_state_fb.c
b/src/gallium/drivers/nvfx/nvfx_state_fb.c
index 73885de..90eb110 100644
--- a/src/gallium/drivers/nvfx/nvfx_state_fb.c
+++ b/src/gallium/drivers/nvfx/nvfx_state_fb.c
@@ -113,7 +113,9 @@ nvfx_framebuffer_validate(struct nvfx_context *nvfx,
unsigned prepare_result)
nvfx-state.render_temps |=
nvfx_surface_get_render_target(fb-cbufs[i], prepare_result, nvfx-hw_rt[i])
i;
for(; i 4; ++i)
- nvfx-hw_rt[i].bo = 0;
+ nvfx-hw_rt[i].bo = NULL;
+
+ nvfx-hw_zeta.bo = NULL;
if (fb-zsbuf) {
nvfx-state.render_temps |=
nvfx_surface_get_render_target(fb-zsbuf, prepare_result, nvfx-hw_zeta)
7;
pgpae89LVucx5.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] dri/nouveau: Clean up magic numbers in get_rt_format
Viktor Novotný novik...@seznam.cz writes:
From: Viktor Novotný novik...@seznam.cz
Signed-off-by: Viktor Novotný novik...@seznam.cz
---
Hi,
since the switch to rnn headers was pushed(thank you, curro), here is a patch
that I inteded to submit first, but somehow ended making the switch.
It is just a small clean up.
Regards
Viktor
src/mesa/drivers/dri/nouveau/nv04_state_fb.c |6 +++---
src/mesa/drivers/dri/nouveau/nv10_state_fb.c | 10 +-
src/mesa/drivers/dri/nouveau/nv20_state_fb.c | 10 +-
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_state_fb.c
b/src/mesa/drivers/dri/nouveau/nv04_state_fb.c
index 730f91f..854571d 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_state_fb.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_state_fb.c
@@ -36,11 +36,11 @@ get_rt_format(gl_format format)
{
switch (format) {
case MESA_FORMAT_XRGB:
- return 0x05;
+ return NV04_CONTEXT_SURFACES_3D_FORMAT_COLOR_X8R8G8B8_X8R8G8B8;
case MESA_FORMAT_ARGB:
- return 0x08;
+ return NV04_CONTEXT_SURFACES_3D_FORMAT_COLOR_A8R8G8B8;
case MESA_FORMAT_RGB565:
- return 0x03;
+ return NV04_CONTEXT_SURFACES_3D_FORMAT_COLOR_R5G6B5;
default:
assert(0);
}
diff --git a/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
b/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
index 056054e..0505547 100644
--- a/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
+++ b/src/mesa/drivers/dri/nouveau/nv10_state_fb.c
@@ -37,15 +37,15 @@ get_rt_format(gl_format format)
{
switch (format) {
case MESA_FORMAT_XRGB:
- return 0x05;
+ return NV10_3D_RT_FORMAT_COLOR_X8R8G8B8;
case MESA_FORMAT_ARGB:
- return 0x08;
+ return NV10_3D_RT_FORMAT_COLOR_A8R8G8B8;
case MESA_FORMAT_RGB565:
- return 0x03;
+ return NV10_3D_RT_FORMAT_COLOR_R5G6B5;
case MESA_FORMAT_Z16:
- return 0x10;
+ return NV10_3D_RT_FORMAT_DEPTH_Z16;
case MESA_FORMAT_Z24_S8:
- return 0x0;
+ return NV10_3D_RT_FORMAT_DEPTH_Z24S8;
default:
assert(0);
}
diff --git a/src/mesa/drivers/dri/nouveau/nv20_state_fb.c
b/src/mesa/drivers/dri/nouveau/nv20_state_fb.c
index 8cabb55..cbde74e 100644
--- a/src/mesa/drivers/dri/nouveau/nv20_state_fb.c
+++ b/src/mesa/drivers/dri/nouveau/nv20_state_fb.c
@@ -37,15 +37,15 @@ get_rt_format(gl_format format)
{
switch (format) {
case MESA_FORMAT_XRGB:
- return 0x05;
+ return NV20_3D_RT_FORMAT_COLOR_X8R8G8B8;
case MESA_FORMAT_ARGB:
- return 0x08;
+ return NV20_3D_RT_FORMAT_COLOR_A8R8G8B8;
case MESA_FORMAT_RGB565:
- return 0x03;
+ return NV20_3D_RT_FORMAT_COLOR_R5G6B5;
case MESA_FORMAT_Z16:
- return 0x10;
+ return NV20_3D_RT_FORMAT_DEPTH_Z16;
case MESA_FORMAT_Z24_S8:
- return 0x20;
+ return NV20_3D_RT_FORMAT_DEPTH_Z24S8;
default:
assert(0);
}
Thanks, pushed.
pgpM1KLndUDlx.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (EE) NOUVEAU(0): Unable to allocate GART memory (TNT-2)
Anders Eriksson aeriks...@fastmail.fm writes: I recently discovered $subject in my xorg logs. Any idea what it means and how to get rid of it? Google suggests changing BIOS parameters but my bios has no agp related options (this is a P-II machine from ca 2000). Can you boot with drm.debug=3 log_buf_len=512k in your kernel command line, start X and attach the full output from dmesg? Some data attached. /anders dmesg | egrep '(gart|drm|nouveau)' [9.099026] Linux agpgart interface v0.103 [9.154475] agpgart-intel :00:00.0: Intel 440BX Chipset [9.189754] PM: Adding info for No Bus:agpgart [9.199242] agpgart-intel :00:00.0: AGP aperture is 64M @ 0x4400 [9.231120] [drm] Initialized drm 1.1.0 20060810 [9.277291] nouveau :01:00.0: PCI INT A - Link[LNKA] - GSI 11 (level, low) - IRQ 11 [9.883226] [drm] nouveau :01:00.0: Detected an NV 0 generation card (0x20154000) [9.911229] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [ 10.081464] [drm] nouveau :01:00.0: ... appears to be valid [ 10.150587] [drm] nouveau :01:00.0: BMP BIOS found [ 10.151970] [drm] nouveau :01:00.0: BMP version 5.1 [ 10.154050] [drm] nouveau :01:00.0: Bios version 02.05.17.06 [ 10.155560] [drm] nouveau :01:00.0: Assuming a CRT output exists [ 10.157784] [drm] nouveau :01:00.0: Probing TV encoders on I2C bus: 1 [ 10.190521] [drm] nouveau :01:00.0: No TV encoders found. [ 10.250904] [drm] nouveau :01:00.0: Detected 16MiB VRAM [ 10.430881] agpgart-intel :00:00.0: AGP 1.0 bridge [ 10.435597] agpgart-intel :00:00.0: putting AGP V2 device into 2x mode [ 10.445600] nouveau :01:00.0: putting AGP V2 device into 2x mode [ 10.447590] [drm] nouveau :01:00.0: 64 MiB GART (aperture) [ 10.456054] [drm] nouveau :01:00.0: Allocating FIFO number 0 [ 10.616818] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 0 [ 10.618966] [drm] nouveau :01:00.0: Saving VGA fonts [ 10.733936] [drm] nouveau :01:00.0: Detected a VGA connector [ 10.763794] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 11.146793] [drm] nouveau :01:00.0: allocated 1680x1050 fb: 0x45000, bo e73e3a00 [ 11.333727] [drm] nouveau :01:00.0: Setting dpms mode 0 on vga encoder (output 0) [ 11.334038] [drm] nouveau :01:00.0: Output VGA-1 is running on CRTC 0 using output @ [ 12.026634] fb0: nouveaufb frame buffer device [ 12.029063] drm: registered panic notifier [ 12.050856] [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 xorg log: [ 1393.179] (II) NOUVEAU(0): Opened GPU channel 1 [ 1393.183] (II) NOUVEAU(0): [DRI2] Setup complete [ 1393.184] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau_vieux [ 1393.184] (II) NOUVEAU(0): GART: 64MiB available [ 1393.185] (EE) NOUVEAU(0): Unable to allocate GART memory [ 1393.211] (II) EXA(0): Driver allocated offscreen pixmaps [ 1393.211] (II) EXA(0): Driver registered support for the following operations: [ 1393.211] (II) Solid [ 1393.211] (II) Copy [ 1393.211] (II) UploadToScreen [ 1393.212] (II) DownloadFromScreen [ 1393.212] (==) NOUVEAU(0): Backing store disabled [ 1393.212] (==) NOUVEAU(0): Silken mouse enabled [ 1393.213] (**) NOUVEAU(0): DPMS enabled [ 1393.213] (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message. lspci -v 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 02) Flags: bus master, medium devsel, latency 64 Memory at 4400 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 Kernel driver in use: agpgart-intel 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: 4000-40ff Prefetchable memory behind bridge: 4200-43ff 00:03.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) Subsystem: RaLink Device 2560 Flags: bus master, slow devsel, latency 66, IRQ 3 Memory at 4800 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 Kernel driver in use: rt2500pci Kernel modules: rt2500pci 00:04.0 Multimedia audio controller: Aureal Semiconductor Vortex 1 (rev 02) Subsystem: Diamond Multimedia Systems Sonic Impact A3D Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at 4100 (32-bit, non-prefetchable) [size=128K] I/O ports at 10b0 [size=8] I/O ports at 10b8 [size=8] Capabilities: [dc] Power Management version 1 Kernel driver
Re: [Nouveau] GeForce FX 5200: no kms
Marcin Slusarz marcin.slus...@gmail.com writes: On Sun, Nov 14, 2010 at 10:18:10AM +, Paolo Milani wrote: --- Dom 14/11/10, Marcin Slusarz marcin.slus...@gmail.com wrote: It should work. Please post your kernel logs from a failed boot (they are somewhere in /var/log). when boot fails (and system crashes), it write nothing in /var/log: there are only logs of the previous successful boot (with nomodeset option). my procedure: 1- boot without nomodeset: system crashes. 2- boot with another linux distribution, then I mount partition of point 1, but in /mnt/var/log there are no logs of failed boot. It wrote nothing. So, I don't know how get logs from a failed boot. If there is a guide, I'm eager to read it. Many thanks. http://nouveau.freedesktop.org/wiki/HangDiagnosis The most successful method is netconsole. If you don't feel like setting up a netconsole, at least show us the output from dmesg, Xorg.0.log and lspci -vv after a successful boot. That alone may tell us something (no guarantees, if you really want to find out what's going on netconsole is your best bet). Marcin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgp3hQgUu9IJl.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC/PATCH] Switch dri driver to use rules-ng-ng headers
Viktor Novotný novik...@seznam.cz writes: Hi, following patches make the dri driver use rules-ng-ng(rnn) generated register definitions instead of renouveau generated ones. First set of 5 patches is for mesa repository, second set of 4 patches is for rnn and consists of changes ported from renouveau. Everything pushed, thanks! pgpqUoMcdo7Tf.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC/PATCH] Switch dri driver to use rules-ng-ng headers
Francisco Jerez curroje...@riseup.net writes: Viktor Novotný novik...@seznam.cz writes: Hi, following patches make the dri driver use rules-ng-ng(rnn) generated register definitions instead of renouveau generated ones. First set of 5 patches is for mesa repository, second set of 4 patches is for rnn and consists of changes ported from renouveau. Everything pushed, thanks! By the way, there's a new rules-ng-ng repository here: http://nouveau.git.sourceforge.net/git/gitweb.cgi?p=nouveau/envytools;a=summary git://nouveau.git.sourceforge.net/gitroot/nouveau/envytools ssh://usern...@nouveau.git.sourceforge.net/gitroot/nouveau/envytools Everyone that used to have write access to the renouveau database should be able to commit there too. pgpZZCjZdecj4.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH mesa/nvfx] fill PIPE_CAP_PRIMITIVE_RESTART and PIPE_CAP_SHADER_STENCIL_EXPORT
Lucas Stach d...@lynxeye.de writes: Attached a trivial fix for mesa/nvfx to shut up warnings about unknown pipe caps. Thanks, pushed. -- Lucas pgpCytYRefZa2.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC/PATCH] Switch dri driver to use rules-ng-ng headers
Viktor Novotný novik...@seznam.cz writes: From: Viktor Novotný novik...@seznam.cz Hi, following patches make the dri driver use rules-ng-ng(rnn) generated register definitions instead of renouveau generated ones. First set of 5 patches is for mesa repository, second set of 4 patches is for rnn and consists of changes ported from renouveau. Some renames seem awkward to me, but I can get used to it. I'm OK with the change as long as Ben agrees with it too (along with a similar change for the DDX), and the rnn repository moves somewhere we can all commit to (i.e. sourceforge). Marcin? What are your feelings with regard to that possibility? BTW, is rnn already a complete replacement of the renouveau database? Can it be used to turn renouveau/mmt dumps into a human readable form? One thing I do not understand is, why rnn does not generate NV20_3D_TEX_ENABLE__LEN(should be 4), so any pointers on what to do are welcome, as are any other comments, suggestions etc. That's no big deal, there's already a define with the number of texture samplers in nv20_driver.h:35. Regards Viktor ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgpvoGwCvabls.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH xf86-video-nouveau] Purge cvs tags.
Jesse Adkins jesserayadk...@gmail.com writes: Signed-off-by: Jesse Adkins jesserayadk...@gmail.com --- src/nv_const.h |2 -- src/nv_include.h |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/src/nv_const.h b/src/nv_const.h index 0df25b6..20984ae 100644 --- a/src/nv_const.h +++ b/src/nv_const.h @@ -1,5 +1,3 @@ -/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/nv_const.h,v 1.6 2001/12/07 00:09:55 mvojkovi Exp $ */ - #ifndef __NV_CONST_H__ #define __NV_CONST_H__ diff --git a/src/nv_include.h b/src/nv_include.h index ce89596..48f0b21 100644 --- a/src/nv_include.h +++ b/src/nv_include.h @@ -1,5 +1,3 @@ -/* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/nv_include.h,v 1.9 2000/10/06 12:31:03 eich Exp $ */ - #ifndef __NV_INCLUDE_H__ #define __NV_INCLUDE_H__ Thanks, pushed. pgpLNM6dbYjOL.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Kernel oops with latest nouveau drm git
Stephan Raue mailingli...@openelec.tv writes: Hi all, running a NV46 card with latest git from http://cgit.freedesktop.org/nouveau/linux-2.6/, mesa, libdrm and xf86-video-nouveau fails with an kernel oops. let me know if you need more informations. [ 11.127274] BUG: unable to handle kernel NULL pointer dereference at 0028 [ 11.127329] IP: [b11c6ef1] nouveau_gpuobj_new+0x26d/0x338 If your kernel was built with debug symbols you can use gdb to find out the source line where it's crashing, like: $ gdb nouveau.ko (gdb) l *nouveau_gpuobj_new+0x26d [ 11.127371] *pde = [ 11.127391] Oops: [#1] [ 11.127407] last sysfs file: /sys/devices/virtual/vc/vcsa1/uevent [ 11.127438] Modules linked in: zram crystalhd [ 11.127466] [ 11.127481] Pid: 700, comm: xbmc.bin Not tainted 2.6.36-rc7 #1 Mac-F4228DC8/AppleTV1,1 [ 11.127520] EIP: 0060:[b11c6ef1] EFLAGS: 00210286 CPU: 0 [ 11.127550] EIP is at nouveau_gpuobj_new+0x26d/0x338 [ 11.127576] EAX: b893e6c0 EBX: bee0 ECX: EDX: bfa68de0 [ 11.127606] ESI: bfab1600 EDI: 0006 EBP: bf8e1000 ESP: bf98bd80 [ 11.127638] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 [ 11.127666] Process xbmc.bin (pid: 700, ti=bf98a000 task=bc54c000 task.ti=bf98a000) [ 11.127699] Stack: [ 11.127712] bfab1600 b1064737 bfb926e0 c278 0020 bfa68de0 bf98be24 bf8e1000 [ 11.127763] 0 b11c73f1 0010 0006 bf98be24 bfab1600 bee0 [ 11.127816] 0 003d bee0 bfab1600 bee0 bf8e1000 [ 11.127871] Call Trace: [ 11.127894] [b1064737] ? alloc_file+0x6c/0x73 [ 11.127923] [b11c73f1] ? nouveau_gpuobj_dma_new+0xf0/0x264 [ 11.127958] [b11c79e3] ? nouveau_gpuobj_channel_init+0x39d/0x512 [ 11.127996] [b11c4c2c] ? nouveau_channel_alloc+0x31c/0x4f9 [ 11.128029] [b11c4e57] ? nouveau_ioctl_fifo_alloc+0x4e/0xf1 [ 11.128064] [b1151461] ? _copy_from_user+0x2a/0x4d [ 11.128094] [b11b155d] ? drm_ioctl+0x240/0x2f6 [ 11.128122] [b11c4e09] ? nouveau_ioctl_fifo_alloc+0x0/0xf1 [ 11.128158] [b1055767] ? handle_mm_fault+0x44a/0x490 [ 11.128188] [b11b131d] ? drm_ioctl+0x0/0x2f6 [ 11.128215] [b106d7a4] ? do_vfs_ioctl+0x48f/0x4c8 [ 11.128247] [b101364c] ? do_page_fault+0x2a7/0x2bf [ 11.128277] [b1013634] ? do_page_fault+0x28f/0x2bf [ 11.128308] [b1017111] ? update_curr.clone.113+0x68/0x8b [ 11.128339] [b1063d57] ? vfs_read+0x93/0xe8 [ 11.128366] [b106d80a] ? sys_ioctl+0x2d/0x47 [ 11.128394] [b1002497] ? sysenter_do_call+0x12/0x26 [ 11.128420] Code: 89 e8 ff 93 1c 05 00 00 85 c0 89 c6 0f 84 d7 00 00 00 8d 54 24 14 31 c0 e8 a6 f7 ff ff e9 bd 00 00 00 8b 34 24 8b 8e b0 00 00 00 8b 49 28 83 f9 ff 89 4a 28 74 06 03 48 14 89 4a 28 83 7b 04 4f [ 11.128637] EIP: [b11c6ef1] nouveau_gpuobj_new+0x26d/0x338 SS:ESP 0068:bf98bd80 [ 11.128679] CR2: 0028 [ 11.136797] ---[ end trace c78ebcc9857021e1 ]--- greetings Stephan pgpdMHsTjaQdA.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: fix nv40 gart size
Lucas Stach d...@lynxeye.de writes: Oh, yes. It seems my email client had some good lunch with the tabs. I added the patch as an attachment. Hope it works this time. -- Lucas Thanks, pushed. Am Montag, den 18.10.2010, 15:47 +0200 schrieb Francisco Jerez: Lucas Stach d...@lynxeye.de writes: Nouveau sets GART size to 64MiB for all cards before nv50, but nv40 has enough RAMIN space to support 512MiB GART size. This patch fixes this value to make use of this hardware capability. Signed-off-by: Lucas Stach d...@lynxeye.de --- The patch doesn't seem to apply, I guess it's been corrupted on the way. Can you please resend? pgppZkbDwDHY7.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: fix nv40 gart size
Lucas Stach d...@lynxeye.de writes:
Nouveau sets GART size to 64MiB for all cards before nv50, but nv40 has
enough RAMIN space to support 512MiB GART size. This patch fixes this
value to make use of this hardware capability.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
The patch doesn't seem to apply, I guess it's been corrupted on the way.
Can you please resend?
drivers/gpu/drm/nouveau/nouveau_sgdma.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 7f028fe..388b3e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -224,7 +224,11 @@ nouveau_sgdma_init(struct drm_device *dev)
int i, ret;
if (dev_priv-card_type NV_50) {
- aper_size = (64 * 1024 * 1024);
+ if(dev_priv-card_type NV_40) {
+ aper_size = (64 * 1024 * 1024);
+ } else {
+ aper_size = (512 * 1024 * 1024);
+ }
obj_size = (aper_size NV_CTXDMA_PAGE_SHIFT) * 4;
obj_size += 8; /* ctxdma header */
} else {
pgppPUEc7Tt7w.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] dual head X config
Grzesiek Sójka p...@pfu.pl writes: Hi there, I have a question. I have a dual DVI NV34 adapter and at the moment the Xserver works fine. Two separated displays configured as follows: Section Monitor Identifier Monitor0 Option PrimaryTrue EndSection Section Monitor Identifier Monitor1 Option RightOf Monitor0 Option PrimaryFalse EndSection Section Device Identifier Device0 Driver nouveau #assigns the output DVI-I-1 to Monitor0 Option monitor-DVI-I-1 Monitor0 #assigns the output DVI-I-2 to Monitor1 Option monitor-DVI-I-2 Monitor1 EndSection Section Screen Identifier screen0 Device Device0 Monitor Monitor0 DefaultDepth 16 SubSection Display Depth 16 Virtual 3200 1200 EndSubSectino EndSection The problem is that I would like to make the mplayer stretch the movie to both monitors when going into the fullscreen mode. When I was using the binary nvidia driver I used the TwinView to do this. Is it possible using the nouveau driver?? You could try fake xinerama: http://ktown.kde.org/~seli/fakexinerama/ pgphipnbVGFqL.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Grzesiek Sójka p...@pfu.pl writes:
On 10/05/10 14:55, Francisco Jerez wrote:
PS. I'm afraid that my system is not very stable when the AGP support
is turned on both using the nouveau kernel source tree and the PLD
patched 2.6.35-5 version with an extra amd-k7-agp patch. The Xserver
uses the driver:
Unstable? How? What's the problem?
Here are the logs:
http://yen.ipipan.waw.pl/~gs159090/tmp/log.tgz
BTW: Sometimes the Xserver freezes during normal work. Unfortunately I
was not able to generate such a crush now. I send you logs if it
happens again.
Regards.
[...]
[ 197.374498] kernel BUG at drivers/gpu/drm/ttm/ttm_tt.c:420!
Oops, I overlooked that, updated patch attached.
diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index b6b1568..b1b4362 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -309,7 +309,8 @@ static int amd_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
num_entries = A_SIZE_LVL2(agp_bridge-current_size)-num_entries;
- if (type != 0 || mem-type != 0)
+ if (type != mem-type ||
+ agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type))
return -EINVAL;
if ((pg_start + mem-page_count) num_entries)
@@ -348,7 +349,8 @@ static int amd_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
unsigned long __iomem *cur_gatt;
unsigned long addr;
- if (type != 0 || mem-type != 0)
+ if (type != mem-type ||
+ agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type))
return -EINVAL;
for (i = pg_start; i (mem-page_count + pg_start); i++) {
pgpKP8QOD53nn.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Grzesiek Sójka p...@pfu.pl writes:
On 10/02/10 15:31, Francisco Jerez wrote:
Ah, I think you're hitting the bandwidth limitation of the nv34
integrated TMDS transmitter. The attached patch should help with the
console modesetting problem, but you'll still need to set the modelines
manually (and force panel rescaling) if you want to go up to 1600x1200,
because your GPU *cannot* handle the video mode your monitor is asking
for.
Your patch works fine. Now I have clear image at both displays. Only
disadvantage is that the resolution is 1280x1024 (PixClk 135MHz). So I
was wondering if it is possible to force particular modeline (by
editing the kernel source tree??). The mode:
Modeline 1600x1200_def 144 1600 1628 1788 1920 1200 1201 1204 1250
works fine with the XServer. Is it possible to force it at the console??
You could try to force a reduced blanking mode in the kernel command
line like: video=DVI-I-1:1600x1200RM. But it isn't going to work with
GPU rescaling, the attached patch (on top of the previous one) will make
the kernel detect that, and automatically fall back to panel rescaling.
Thanks again!
PS. I'm afraid that my system is not very stable when the AGP support
is turned on both using the nouveau kernel source tree and the PLD
patched 2.6.35-5 version with an extra amd-k7-agp patch. The Xserver
uses the driver:
Unstable? How? What's the problem?
[38.842] (II) Module nouveau: vendor=X.Org Foundation
[38.842]compiled for 1.9.0, module version = 0.0.16
[38.842]Module class: X.Org Video Driver
[38.842]ABI class: X.Org Video Driver, version 8.0
diff --git a/drivers/gpu/drm/nouveau/nv04_dfp.c b/drivers/gpu/drm/nouveau/nv04_dfp.c
index c936403..0d6ee18 100644
--- a/drivers/gpu/drm/nouveau/nv04_dfp.c
+++ b/drivers/gpu/drm/nouveau/nv04_dfp.c
@@ -185,14 +185,19 @@ static bool nv04_dfp_mode_fixup(struct drm_encoder *encoder,
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_connector *nv_connector = nouveau_encoder_connector_get(nv_encoder);
- /* For internal panels and gpu scaling on DVI we need the native mode */
- if (nv_connector-scaling_mode != DRM_MODE_SCALE_NONE) {
- if (!nv_connector-native_mode)
- return false;
+ if (!nv_connector-native_mode ||
+ mode-hdisplay nv_connector-native_mode-hdisplay ||
+ mode-vdisplay nv_connector-native_mode-vdisplay) {
+ NV_DEBUG_KMS(encoder-dev, Mode larger than native mode,
+ forcing panel rescaling.\n);
+ nv_encoder-mode = *adjusted_mode;
+
+ } else if (nv_connector-scaling_mode == DRM_MODE_SCALE_NONE) {
+ nv_encoder-mode = *adjusted_mode;
+
+ } else {
nv_encoder-mode = *nv_connector-native_mode;
adjusted_mode-clock = nv_connector-native_mode-clock;
- } else {
- nv_encoder-mode = *adjusted_mode;
}
return true;
pgpmgUBQqaNqt.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Grzesiek Sójka p...@pfu.pl writes:
On 10/01/10 01:29, Francisco Jerez wrote:
Grzesiek Sójkap...@pfu.pl writes:
On 09/30/10 18:05, Francisco Jerez wrote:
Does the following command help?
$ xrandr --output DVI-I-2 --set scaling mode None
Yes! Now I have:
xrandr --output DVI-I-1 --set scaling mode None
xrandr --output DVI-I-2 --set scaling mode None
in xinitrc. Both displays work fine when Xserver is running. But after I
go back to the console the display #1 switches off and #2 starts to
blink again. Is it possible to fix the console??
Do you need to tell the binary driver to do anything special to get it
working on those monitors? (e.g. manually specified timings or EDID)
No, binary driver works fine without any extra settings. The version I
used was 173.14.22. With nouveau drivers I'm forced to use the
following
Modeline 1600x1200_def 144 1600 1628 1788 1920 1200 1201 1204 1250
Without it the displays (both) are blinking. Remember that binary
nvidia claims that the MaxPixClk is 135MHz and nouveau says that it is
175MHz. According to the spec it should be 162MHz. I'm not sure but I
think that this high rate works only with D-SUB. Actually I have 3
monitors and the third one is connected with the ancient Matrox
Millennium II card using the D-SUB cable and it uses the modeline with
the 162MHz PixClk.
Ah, I think you're hitting the bandwidth limitation of the nv34
integrated TMDS transmitter. The attached patch should help with the
console modesetting problem, but you'll still need to set the modelines
manually (and force panel rescaling) if you want to go up to 1600x1200,
because your GPU *cannot* handle the video mode your monitor is asking
for.
PS. By the way - I was force to install Win7 and it works with my LCD
without any drivers installed.
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 0871495..6208eed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -641,11 +641,28 @@ nouveau_connector_get_modes(struct drm_connector *connector)
return ret;
}
+static unsigned
+get_tmds_link_bandwidth(struct drm_connector *connector)
+{
+ struct nouveau_connector *nv_connector = nouveau_connector(connector);
+ struct drm_nouveau_private *dev_priv = connector-dev-dev_private;
+ struct dcb_entry *dcb = nv_connector-detected_encoder-dcb;
+
+ if (dcb-location != DCB_LOC_ON_CHIP ||
+ dev_priv-chipset = 0x46)
+ return 165000;
+ else if (dev_priv-chipset = 0x40)
+ return 155000;
+ else if (dev_priv-chipset = 0x18)
+ return 135000;
+ else
+ return 112000;
+}
+
static int
nouveau_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- struct drm_nouveau_private *dev_priv = connector-dev-dev_private;
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_encoder *nv_encoder = nv_connector-detected_encoder;
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
@@ -663,11 +680,9 @@ nouveau_connector_mode_valid(struct drm_connector *connector,
max_clock = 40;
break;
case OUTPUT_TMDS:
- if ((dev_priv-card_type = NV_50 !nouveau_duallink) ||
- !nv_encoder-dcb-duallink_possible)
- max_clock = 165000;
- else
- max_clock = 33;
+ max_clock = get_tmds_link_bandwidth(connector);
+ if (nouveau_duallink nv_encoder-dcb-duallink_possible)
+ max_clock *= 2;
break;
case OUTPUT_ANALOG:
max_clock = nv_encoder-dcb-crtconf.maxfreq;
pgpgzVLsh7YTE.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Pekka Paalanen p...@iki.fi writes: On Tue, 28 Sep 2010 18:17:25 +0200 Grzesiek Sójka p...@pfu.pl wrote: I'm completely lost at the moment so let me start from the beginning. First thing is that everything works fine with Nvidia binary drivers, which means that hardware is rather OK. After loading of the nouveau.ko the monitor connected to DVI-I-1 goes to the standby mode. I do not know if the head is turned of or maybe some kind of rates are too high/low. I was trying to play with video=DVI-I-1: with different modes and switches (M/R/D/e) and nothing. At the some time (after loading nouveau.ko) the monitor connected with the DVI-I-2 starts to blink. And again I was playing with the video=DVI-I-2:??? and nothing. I thought that maybe after starting the xorg I will get the proper image at both monitor. Unfortunately - no success. According to the Xorg log file (Option ModeDebug true) all the refresh rates are ok. Moreover I was trying to use different ModeLines and nothing. The X server claims that there are two monitor connected and working but the first one is in standby mode and the second is blinking. Any ideas?? If you need some more information please let me know. Yes, the complete kernel and X logs, like I have requested twice before. That is the minimum before anyone will seriously start looking into it. Before doing that, can you try latest git again? I pushed a patch yesterday that may help with it. Preferrably, use the simplest setup that fails: - only one monitor physically connected - the following xorg.conf: And use drm.debug=4 in your kernel command line, that should tell you what timings are being used exactly. Section Device Identifier n Driver nouveau Option ModeDebug true EndSection Thanks. pgpwI3BIFYzzl.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Grzesiek Sójka p...@pfu.pl writes:
I did download new sources and applied the amd-agp patch but no change.
I get the some problems. Here is the dmesg without modeset:
http://yen.ipipan.waw.pl/~gs159090/tmp/txt.gz
Then I added following modeline to the file drm_edid_modes.h
/* 1600x1...@50hz */
{ DRM_MODE(1600x1200, DRM_MODE_TYPE_DRIVER, 135000, 1600, 1664,
1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
and tried to force the mode by setting video=DVI-I-[12]:1600x1200...@50.
No luck, here you have the dmesg:
http://yen.ipipan.waw.pl/~gs159090/tmp/txt2.gz
I also did some test with the xorg:
http://yen.ipipan.waw.pl/~gs159090/tmp/Xorg.0.log.gz
http://yen.ipipan.waw.pl/~gs159090/tmp/xorg.conf.gz
The interesting thing is that according to the dmesg the xorgs tries to
set the mode:
Modeline 58:1600x1200_def 0 144000 1600 1628 1788 1920 1200 1201 1204
1250 0x0 0x0
but just after the mode is used:
Modeline 75:1600x1200 0 162000 1600 1664 1856 2160 1200 1201 1204 1250
0x48 0x5
Here is the xrandr --verbose output:
http://yen.ipipan.waw.pl/~gs159090/tmp/xrandr.nouveau.gz
Does the following command help?
$ xrandr --output DVI-I-2 --set scaling mode None
Just in case I also recorded the xrandr output in the case of the Nvidia
binary driver:
http://yen.ipipan.waw.pl/~gs159090/tmp/xrandr.nvidia.gz
I was really surprised because the xrandr claims that the refresh rate
is 50Hz but at the OSD there is an information that the refresh rate is
60Hz. What to think?? Next thing is that the refresh rate of 50Hz is out
of the monitor range: VertRefresh 56 - 75. So the Xserver should not to
set it to 50.
Don't worry about that, IIRC it's just a hack nvidia did to
differentiate between meta-modes with the same resolution but a
different set of enabled outputs, instead of switching to RandR12.
All the time (when using nouveau.ko) the monitor #1 is switched off and
#2 is blinking. It does not mater if Xserver is running or not.
Please let me know if you need any more data.
Thanks for any help in advance.
Regards
pgpyOgvSpsQlp.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Grzesiek Sójka p...@pfu.pl writes: On 09/30/10 18:05, Francisco Jerez wrote: Does the following command help? $ xrandr --output DVI-I-2 --set scaling mode None Yes! Now I have: xrandr --output DVI-I-1 --set scaling mode None xrandr --output DVI-I-2 --set scaling mode None in xinitrc. Both displays work fine when Xserver is running. But after I go back to the console the display #1 switches off and #2 starts to blink again. Is it possible to fix the console?? Do you need to tell the binary driver to do anything special to get it working on those monitors? (e.g. manually specified timings or EDID) Regards. pgpHWYtDixNuB.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] AMD768 GeForce5200: nouveau bug??
Grzesiek Sójka p...@pfu.pl writes:
Hi there,
Im using ASUS A7M266-D mainboard based on AMD768 chipset and Nvidia
GeForce FX5200 dual DVI graphics adapter. I'm forced to switch from
binary Nvidia drivers to nouveau but the problem is that nouveau.ko
would not load with AGP support turned on. Is it a nouveau/kernel bug??
To build the kernel I used the kernel tree downloaded from the nouveau
repository about a week ago. The dmesg output with/without the AGP
support you can find at:
http://yen.ipipan.waw.pl/~gs159090/tmp/withAGP.txt.gz
http://yen.ipipan.waw.pl/~gs159090/tmp/withoutAGP.txt.gz
And here is lspci -vv output
http://yen.ipipan.waw.pl/~gs159090/tmp/lspci-vv.txt.gz
Thanks in advance for any help.
That looks like a bug in the amdk7 agp driver, can you give this patch a
try?
Regards
Greg
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index b6b1568..82e5189 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -303,13 +303,15 @@ static void amd_irongate_tlbflush(struct agp_memory *temp)
static int amd_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
{
+ struct agp_bridge_data *bridge = mem-bridge;
int i, j, num_entries;
unsigned long __iomem *cur_gatt;
unsigned long addr;
num_entries = A_SIZE_LVL2(agp_bridge-current_size)-num_entries;
- if (type != 0 || mem-type != 0)
+ if (!bridge || type != mem-type ||
+ bridge-driver-agp_type_to_mask_type(bridge, type))
return -EINVAL;
if ((pg_start + mem-page_count) num_entries)
pgpuCELwZbmwF.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.
Chris Ball c...@laptop.org writes:
Hi Francisco,
There is a problem with this on pre-nv20 cards. Fbcon
acceleration won't work properly with IRQs disabled because you
miss the context switching interrupts: You'll get a locked up
fbcon if you hit sysrq-g when there's some process using the GPU.
I'd suggest disabling acceleration while in debug mode
(e.g. using nouveau_fbcon_save_disable_accel()). That aside the
patch looks good to me.
Thanks very much for this. Here's a (only compile-tested) patch for
this, on top of jwessel's current kgdb-next branch. Jason, would you
mind testing on pre-nv20 and applying?
Thanks, it looks OK to me, and I just tested it successfully on
nv11. You can have my Acked-by on both nouveau patches if you need it.
Thanks,
- Chris.
From: Chris Ball c...@laptop.org
Subject: [PATCH] drm/nouveau/kms: Avoid a hang entering KDB with VT accel on.
Francisco Jerez advises that pre-nv20 cards would hang if we entered
kdb with accel on and IRQs disabled, so we now disable accel before
entering kdb and re-enable it on the way back out.
Signed-off-by: Chris Ball c...@laptop.org
Cc: Francisco Jerez curroje...@riseup.net
Cc: Jason Wessel jason.wes...@windriver.com
---
drivers/gpu/drm/nouveau/nv04_crtc.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c
b/drivers/gpu/drm/nouveau/nv04_crtc.c
index fb669dd..427f90e 100644
--- a/drivers/gpu/drm/nouveau/nv04_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv04_crtc.c
@@ -31,10 +31,11 @@
#include nouveau_connector.h
#include nouveau_crtc.h
#include nouveau_fb.h
#include nouveau_hw.h
#include nvreg.h
+#include nouveau_fbcon.h
static int
nv04_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb);
@@ -858,10 +859,18 @@ nv04_crtc_mode_set_base(struct drm_crtc *crtc, int x,
int y,
static int
nv04_crtc_mode_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int x, int y, int enter)
{
+ struct drm_nouveau_private *dev_priv = crtc-dev-dev_private;
+ struct drm_device *dev = dev_priv-dev;
+
+ if (enter)
+ nouveau_fbcon_save_disable_accel(dev);
+ else
+ nouveau_fbcon_restore_accel(dev);
+
return nv04_crtc_do_mode_set_base(crtc, fb, x, y, true);
}
static void nv04_cursor_upload(struct drm_device *dev, struct nouveau_bo
*src,
struct nouveau_bo *dst)
pgp8xTuA4qilR.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] shouldn't nouveau.ko depend on fbcon.ko?
Dragos Delcea dragos.del...@gmail.com writes: Hi, I noticed that loading nouveau doesn't load fbcon automatically; and without fbcon, when loading nouveau the console turns blank. I spent a few good hours until I was able to figure out that I had to manually modprobe fbcon to get the console back after loading nouveau. This is happening on a vanilla 2.6.35.3; shouldn't there be dependencies in place between modules? Note that I haven't got to the xorg part just yet, I'm currently installing gentoo. We already do, except for kernels compiled with Configure standard kernel features (for small systems). Strictly speaking, nouveau doesn't depend on fbcon so that option is left open for e.g. embedded platforms that don't need a framebuffer console. thanks, Dragos PS please include me in the reply as I'm not subscribed. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgp1kXdnUb6Ix.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [mesa PATCH] nouveau: handle early initialization errors
Marcin Slusarz marcin.slus...@gmail.com writes:
handle very early errors in pipe_screen creation (failure of
nouveau_screen_init in nv50_screen_create)
---
src/gallium/drivers/nouveau/nouveau_screen.c |3 ++-
.../winsys/nouveau/drm/nouveau_drm_winsys.c|3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
b/src/gallium/drivers/nouveau/nouveau_screen.c
index 513e5e0..ebb21a6 100644
--- a/src/gallium/drivers/nouveau/nouveau_screen.c
+++ b/src/gallium/drivers/nouveau/nouveau_screen.c
@@ -258,6 +258,7 @@ nouveau_screen_fini(struct nouveau_screen *screen)
{
struct pipe_winsys *ws = screen-base.winsys;
nouveau_channel_free(screen-channel);
- ws-destroy(ws);
+ if (ws)
+ ws-destroy(ws);
}
diff --git a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
index 660dbd0..d4bf124 100644
--- a/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
+++ b/src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c
@@ -19,7 +19,8 @@ nouveau_drm_destroy_winsys(struct pipe_winsys *s)
{
struct nouveau_winsys *nv_winsys = nouveau_winsys(s);
struct nouveau_screen *nv_screen= nouveau_screen(nv_winsys-pscreen);
- nouveau_device_close(nv_screen-device);
+ if (nv_screen)
+ nouveau_device_close(nv_screen-device);
FREE(nv_winsys);
}
Thanks, pushed.
pgpZGxipcr6TN.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: try to load fbcon
Marcin Slusarz marcin.slus...@gmail.com writes: On Wed, Aug 25, 2010 at 06:15:53PM +0200, Francisco Jerez wrote: Dragos Delcea dragos.del...@gmail.com writes: Hi, I noticed that loading nouveau doesn't load fbcon automatically; and without fbcon, when loading nouveau the console turns blank. I spent a few good hours until I was able to figure out that I had to manually modprobe fbcon to get the console back after loading nouveau. This is happening on a vanilla 2.6.35.3; shouldn't there be dependencies in place between modules? Note that I haven't got to the xorg part just yet, I'm currently installing gentoo. We already do, except for kernels compiled with Configure standard kernel features (for small systems). Strictly speaking, nouveau doesn't depend on fbcon so that option is left open for e.g. embedded platforms that don't need a framebuffer console. But it's only a build time dependency. Let's fix it. --- From: Marcin Slusarz marcin.slus...@gmail.com Subject: [PATCH] drm/nouveau: try to load fbcon Currently users have to load fbcon manually or build it into the kernel to have any console output. Let's make it easy for them and load fbcon automatically at init time. Nouveau already selects fbcon at build time when !EMBEDDED. Reported-by: Dragos Delcea dragos.del...@gmail.com Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com --- drivers/gpu/drm/nouveau/nouveau_drv.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index a8d3d17..df9a687 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c @@ -434,6 +434,12 @@ static int __init nouveau_init(void) if (!nouveau_modeset) return 0; +#if defined(CONFIG_FRAMEBUFFER_CONSOLE_MODULE) + request_module(fbcon); +#elif !defined(CONFIG_FRAMEBUFFER_CONSOLE) + printk(KERN_INFO CONFIG_FRAMEBUFFER_CONSOLE was not enabled. You won't get any console output.\n); +#endif + nouveau_register_dsm_handler(); return drm_init(driver); } Pushed to master, thanks. pgp0bZQgRgGCQ.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS.
Chris Ball c...@laptop.org writes: Hi, Here's a patch to add support for KMS debugging to Nouveau, along the style of the previous patches for Intel¹ and Radeon². I'm only able to test on nv50 here, so a test on nv04 would be much appreciated, and I've published instructions on how to test here³. Thanks! There is a problem with this on pre-nv20 cards. Fbcon acceleration won't work properly with IRQs disabled because you miss the context switching interrupts: You'll get a locked up fbcon if you hit sysrq-g when there's some process using the GPU. I'd suggest disabling acceleration while in debug mode (e.g. using nouveau_fbcon_save_disable_accel()). That aside the patch looks good to me. - Chris. ¹: http://lkml.org/lkml/2010/8/5/280 ²: http://dev.laptop.org/~cjb/kdb-radeon.patch ³: http://blog.printf.net/articles/2010/08/19/kdb-kms-for-nouveau-radeon [...] pgp67oAafbkPP.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 2 cards in, but work only separately
Kārlis Repsons k...@11.lv writes: On Monday 02 August 2010 14:07:19 Francisco Jerez wrote: Kārlis Repsons k...@11.lv writes: On Monday 02 August 2010 11:33:14 Francisco Jerez wrote: But now I'm at the next level of trouble: 1. when two Xservers are running, after some minutes video output of the primary card ceases (logging out restarts X and then it's back..), while the second output is still ok; Kernel and X logs after the crash would be helpful. I found them to be funnily short: in my kernel log there is this line: [drm] nouveau :01:00.0: Setting dpms mode 1 on vga encoder (output 0) And yes it doesn't come back just by moving mouse. In xorg.conf there is /Option DPMS off/ for each monitor and also for each server layout Blank, Standby, Suspend, Off *Time is set to 0... $ cat Xorg.0.log | egrep (DPMS|Dpms|dpms) Aug 2 13:05:01 station 19180.806] (II) Loading extension DPMS Aug 2 13:05:01 station 19181.154] (II) NOUVEAU(0): DPMS capabilities: Off; RGB/Color Display Now what should I do please? Show us your full logs, please. Ok. Here I post the kernel log fragment between start of Xservers at 13:05:00 and crash, which happened at 13:14:47, you can find full logs in attach, note that syslog-ng has done some modifications, but I hope they're not harmful for us: Aug 2 13:05:01 station kernel: [drm] nouveau :04:00.0: Allocating FIFO number 1 Aug 2 13:05:01 station kernel: [drm] nouveau :04:00.0: nouveau_channel_alloc: initialised FIFO 1 Aug 2 13:05:01 station kernel: [drm] nouveau :04:00.0: Setting dpms mode 3 on tmds encoder (output 2) Aug 2 13:05:01 station kernel: [drm] nouveau :04:00.0: 0xD0B6: Parsing digital output script table Aug 2 13:05:01 station kernel: [drm] nouveau :04:00.0: Setting dpms mode 0 on tmds encoder (output 2) Aug 2 13:05:01 station kernel: [drm] nouveau :04:00.0: Output DVI-I-2 is running on CRTC 0 using output A Aug 2 13:05:01 station kernel: [drm] nouveau :01:00.0: Allocating FIFO number 1 Aug 2 13:05:01 station kernel: [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 1 Aug 2 13:14:47 station kernel: [drm] nouveau :01:00.0: Setting dpms mode 1 on vga encoder (output 0) Aug 2 13:17:11 station kernel: [drm] nouveau :04:00.0: nouveau_channel_free: freeing fifo 1 Aug 2 13:17:11 station kernel: [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 1 Let me know what you find... Apparently something's setting DPMS mode 1 behind the X server back. Does xset dpms force on give you the display back? pgpoNNIgdcYl8.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [patch v2] nouveau: unwind on load errors
Marcin Slusarz marcin.slus...@gmail.com writes:
On Fri, Jul 30, 2010 at 05:04:32PM +0200, Dan Carpenter wrote:
nuveau_load() just returned directly if there was an error instead of
^^ typo
releasing resources.
Signed-off-by: Dan Carpenter erro...@gmail.com
---
V2: updated to the nouveau git tree.
Thanks.
Reviewed-by: Marcin Slusarz marcin.slus...@gmail.com
Thanks, pushed to the nouveau kernel tree.
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
b/drivers/gpu/drm/nouveau/nouveau_state.c
index ee3729e..cf16bfb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -739,8 +739,10 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
int ret;
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
-if (!dev_priv)
-return -ENOMEM;
+if (!dev_priv) {
+ret = -ENOMEM;
+goto err_out;
+}
dev-dev_private = dev_priv;
dev_priv-dev = dev;
@@ -750,8 +752,10 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
dev-pci_vendor, dev-pci_device, dev-pdev-class);
dev_priv-wq = create_workqueue(nouveau);
-if (!dev_priv-wq)
-return -EINVAL;
+if (!dev_priv-wq) {
+ret = -EINVAL;
+goto err_priv;
+}
/* resource 0 is mmio regs */
/* resource 1 is linear FB */
@@ -764,7 +768,8 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
if (!dev_priv-mmio) {
NV_ERROR(dev, Unable to initialize the mmio mapping.
Please report your setup to DRIVER_EMAIL \n);
-return -EINVAL;
+ret = -EINVAL;
+goto err_wq;
}
NV_DEBUG(dev, regs mapped ok at 0x%llx\n,
(unsigned long long)mmio_start_offs);
@@ -812,7 +817,8 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
break;
default:
NV_INFO(dev, Unsupported chipset 0x%08x\n, reg0);
-return -EINVAL;
+ret = -EINVAL;
+goto err_mmio;
}
NV_INFO(dev, Detected an NV%2x generation card (0x%08x)\n,
@@ -820,7 +826,7 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
ret = nouveau_remove_conflicting_drivers(dev);
if (ret)
-return ret;
+goto err_mmio;
/* Map PRAMIN BAR, or on older cards, the aperture withing BAR0 */
if (dev_priv-card_type = NV_40) {
@@ -834,7 +840,8 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
dev_priv-ramin_size);
if (!dev_priv-ramin) {
NV_ERROR(dev, Failed to PRAMIN BAR);
-return -ENOMEM;
+ret = -ENOMEM;
+goto err_mmio;
}
} else {
dev_priv-ramin_size = 1 * 1024 * 1024;
@@ -842,7 +849,8 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
dev_priv-ramin_size);
if (!dev_priv-ramin) {
NV_ERROR(dev, Failed to map BAR0 PRAMIN.\n);
-return -ENOMEM;
+ret = -ENOMEM;
+goto err_mmio;
}
}
@@ -857,9 +865,21 @@ int nouveau_load(struct drm_device *dev, unsigned long
flags)
/* For kernel modesetting, init card now and bring up fbcon */
ret = nouveau_card_init(dev);
if (ret)
-return ret;
+goto err_ramin;
return 0;
+
+err_ramin:
+iounmap(dev_priv-ramin);
+err_mmio:
+iounmap(dev_priv-mmio);
+err_wq:
+destroy_workqueue(dev_priv-wq);
+err_priv:
+kfree(dev_priv);
+dev-dev_private = NULL;
+err_out:
+return ret;
}
void nouveau_lastclose(struct drm_device *dev)
pgpoc4Uuc3uKd.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [nouveau-drm] failed to set mode on crtc
yaiba.kurog...@interia.pl writes: Hi. I have a problem with current kernel 2.6.35 and nouveau module compiled from git (today).From xorg.0.log I got information that no output was found.And here is some nasty kernel logs: [...] What is going on? Your BIOS lacks some information we need for modesetting. The attached patch should fix it, can you give it a try? diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 23a7bec..fc35e9d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -5855,7 +5855,7 @@ static void fabricate_vga_output(struct dcb_table *dcb, int i2c, int heads) entry-i2c_index = i2c; entry-heads = heads; entry-location = DCB_LOC_ON_CHIP; - /* or mostly unused in early gen crt modesetting, 0 is fine */ + entry-or = 1; } static void fabricate_dvi_i_output(struct dcb_table *dcb, bool twoHeads) pgpowhiZIvyYf.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 2 cards in, but work only separately
Kārlis Repsons k...@11.lv writes: On Sunday 01 August 2010 10:30:02 Marcin Slusarz wrote: On Sun, Aug 01, 2010 at 08:59:28AM +, Kārlis Repsons wrote: On Sunday 01 August 2010 08:41:04 Pekka Paalanen wrote: On Sat, 31 Jul 2010 22:08:23 + Kārlis Repsons k...@11.lv wrote: Hi list, my thanks to developers of nouveau first: I wonder how you put it together this far, where there's quite enough to appreciate! This question I have: strangely I can get each of 2 cards to work separately for a dualseat PC by toggling on/off fbcon=map: kernel option (compiled with CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY) -- by doing so I can have each card initialized and start it's Xorg, all welll, but can't have both cards initialized (and thus used) -- why? In very short, this is what my dmesg says: [drm] Initialized drm 1.1.0 20060810 nouveau :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 nouveau :04:00.0: enabling device ( - 0002) nouveau :04:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 nouveau :04:00.0: PCI INT A disabled nouveau: probe of :04:00.0 failed with error -12 Is this really a continuous section of the kernel log, no lines removed from between? No, I removed! See all in attach! What versions of the Nouveau components and the kernel you have? What cards do you have? Linux 2.6.34-gentoo-r2 (no DRM or nouveau driver in); nouveau-drm 20100520 from portage (gives me ch7006.ko drm_kms_helper.ko drm.ko nouveau.ko ttm.ko); GeForce 7300GS, GeForce 6200LE! These are NV40's (see http://nouveau.freedesktop.org/wiki/CodeNames) and multicard (http://nouveau.freedesktop.org/wiki/FeatureMatrix) on NV40's works since 2010.05.25. Just upgrade. Marcin So I'm back with updated system: $ uname gives me 2.6.35-rc3, where Linux 2.6.35-rc6 (object b37fa16e78d6f9790462b3181602a26b5af36260) is used as base for nouveau-master with HEAD 439a21f25f60221e6d9032cb8ad3bb1aafee44ea, nouveau kernel modules compiled in; libdrm 2.4.21-r1 from gentoo x11 overlay; xf86-video-nouveau 0.0.16_pre20100615; x11-base/xorg-server-1.8.99.905 from overlay too. Yes, that problem with cards initialization is gone! But now I'm at the next level of trouble: 1. when two Xservers are running, after some minutes video output of the primary card ceases (logging out restarts X and then it's back..), while the second output is still ok; Kernel and X logs after the crash would be helpful. 2. after hibernation/resume the same problematic video output is showing me some vt with my X11 mouse cursor and gpm's one in the same time, all input is directed to X11, but no useful video output for primary card, while second output is ok (again X restart helps). What would you suggest me now? pgp2v7foN7Ae0.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 2 cards in, but work only separately
Kārlis Repsons k...@11.lv writes: On Monday 02 August 2010 11:33:14 Francisco Jerez wrote: But now I'm at the next level of trouble: 1. when two Xservers are running, after some minutes video output of the primary card ceases (logging out restarts X and then it's back..), while the second output is still ok; Kernel and X logs after the crash would be helpful. I found them to be funnily short: in my kernel log there is this line: [drm] nouveau :01:00.0: Setting dpms mode 1 on vga encoder (output 0) And yes it doesn't come back just by moving mouse. In xorg.conf there is /Option DPMS off/ for each monitor and also for each server layout Blank, Standby, Suspend, Off *Time is set to 0... $ cat Xorg.0.log | egrep (DPMS|Dpms|dpms) Aug 2 13:05:01 station 19180.806] (II) Loading extension DPMS Aug 2 13:05:01 station 19181.154] (II) NOUVEAU(0): DPMS capabilities: Off; RGB/Color Display Now what should I do please? Show us your full logs, please. pgpRktqHiUvU4.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 2 cards in, but work only separately
Kārlis Repsons k...@11.lv writes: On Sunday 01 August 2010 08:41:04 Pekka Paalanen wrote: On Sat, 31 Jul 2010 22:08:23 + Kārlis Repsons k...@11.lv wrote: Hi list, my thanks to developers of nouveau first: I wonder how you put it together this far, where there's quite enough to appreciate! This question I have: strangely I can get each of 2 cards to work separately for a dualseat PC by toggling on/off fbcon=map: kernel option (compiled with CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY) -- by doing so I can have each card initialized and start it's Xorg, all welll, but can't have both cards initialized (and thus used) -- why? In very short, this is what my dmesg says: [drm] Initialized drm 1.1.0 20060810 nouveau :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 nouveau :04:00.0: enabling device ( - 0002) nouveau :04:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 nouveau :04:00.0: PCI INT A disabled nouveau: probe of :04:00.0 failed with error -12 Is this really a continuous section of the kernel log, no lines removed from between? No, I removed! See all in attach! What versions of the Nouveau components and the kernel you have? What cards do you have? Linux 2.6.34-gentoo-r2 (no DRM or nouveau driver in); nouveau-drm 20100520 from portage (gives me ch7006.ko drm_kms_helper.ko drm.ko nouveau.ko ttm.ko); GeForce 7300GS, GeForce 6200LE! Could you please try again with the latest kernel modules from git? I think your problem has already been fixed. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgpcD3Jv9kc1L.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Reflow logic to make it easier to follow
Tomas Carnecky t...@dbservice.com writes:
The control flow was:
if (!y) {
ppix = ...
}
if (y) {
...
} else if (x) {
use ppix for something
} else {
use ppix for something
}
Merge the if(!y) block with the two else branches. This avoids
a false-positive in the clang static analyzer, it can't know that
!y and x are mutually exclusive.
The result looks something like this:
if (y) {
...
} else {
ppix = ...
if (x) {
use ppix for something
} else {
use ppix for something
}
}
This patch makes the code go above the 80-column limit, that's probably
the reason it was structured that way.
Signed-off-by: Tomas Carnecky t...@dbservice.com
---
This patch actually compiles. There are still a couple clang warnings, but
those are dead assignments and one dead initialization. If there is interest
I can send patches for those as well. The clang results can be viewed at
http://stuff.caurea.org/clang-static-analyzer/nouveau
Sure, patches are welcome. I wouldn't bother with the warnings found in
the overlay code though, those functions are currently unused and
they'll eventually be moved to the kernel.
src/nouveau_xv.c | 114
++
1 files changed, 55 insertions(+), 59 deletions(-)
diff --git a/src/nouveau_xv.c b/src/nouveau_xv.c
index 4437aa6..eb43207 100644
--- a/src/nouveau_xv.c
+++ b/src/nouveau_xv.c
@@ -920,7 +920,6 @@ NVPutImage(ScrnInfoPtr pScrn, short src_x, short src_y,
short drw_x,
{
NVPortPrivPtr pPriv = (NVPortPrivPtr)data;
NVPtr pNv = NVPTR(pScrn);
- PixmapPtr ppix;
/* source box */
INT32 xa = 0, xb = 0, ya = 0, yb = 0;
/* size to allocate in VRAM and in GART respectively */
@@ -1249,11 +1248,29 @@ CPU_copy:
if (pPriv-currentHostBuffer != NO_PRIV_HOST_BUFFER_AVAILABLE)
pPriv-currentHostBuffer ^= 1;
- /* If we're not using the hw overlay, we're rendering into a pixmap
- * and need to take a couple of additional steps...
- */
- if (!(action_flags USE_OVERLAY)) {
- ppix = NVGetDrawablePixmap(pDraw);
+ if (action_flags USE_OVERLAY) {
+ if (pNv-Architecture == NV_ARCH_04) {
+ NV04PutOverlayImage(pScrn, pPriv-video_mem, offset,
+ id, dstPitch, dstBox, 0, 0,
+ xb, yb, npixels, nlines,
+ src_w, src_h, drw_w, drw_h,
+ clipBoxes);
+ } else {
+ NV10PutOverlayImage(pScrn, pPriv-video_mem, offset,
+ uv_offset, id, dstPitch, dstBox,
+ 0, 0, xb, yb,
+ npixels, nlines, src_w, src_h,
+ drw_w, drw_h, clipBoxes);
+ }
+
+ pPriv-currentBuffer ^= 1;
+ } else {
+ int ret = BadImplementation;
+
+ /* If we're not using the hw overlay, we're rendering into a
pixmap
+ * and need to take a couple of additional steps...
+ */
+ PixmapPtr ppix = NVGetDrawablePixmap(pDraw);
/* Ensure pixmap is in offscreen memory */
pNv-exa_force_cp = TRUE;
@@ -1274,69 +1291,48 @@ CPU_copy:
dstBox.y2 -= ppix-screen_y;
}
#endif
- }
-
- if (action_flags USE_OVERLAY) {
- if (pNv-Architecture == NV_ARCH_04) {
- NV04PutOverlayImage(pScrn, pPriv-video_mem, offset,
- id, dstPitch, dstBox, 0, 0,
- xb, yb, npixels, nlines,
- src_w, src_h, drw_w, drw_h,
- clipBoxes);
- } else {
- NV10PutOverlayImage(pScrn, pPriv-video_mem, offset,
- uv_offset, id, dstPitch, dstBox,
- 0, 0, xb, yb,
- npixels, nlines, src_w, src_h,
- drw_w, drw_h, clipBoxes);
- }
- pPriv-currentBuffer ^= 1;
- } else
- if (action_flags USE_TEXTURE) {
- int ret = BadImplementation;
- if (pNv-Architecture == NV_ARCH_30) {
- ret = NV30PutTextureImage(pScrn, pPriv-video_mem,
- offset, uv_offset,
- id, dstPitch, dstBox, 0, 0,
- xb, yb, npixels, nlines,
- src_w, src_h, drw_w, drw_h,
- clipBoxes,
Re: [Nouveau] deadlock possiblity introduced by drm/nouveau: use drm_mm in preference to custom code doing the same thing
Marcin Slusarz marcin.slus...@gmail.com writes: On Sun, Jul 11, 2010 at 11:02:12AM +1000, Ben Skeggs wrote: On Sun, 2010-07-11 at 01:24 +0200, Marcin Slusarz wrote: Hi Patch drm/nouveau: use drm_mm in preference to custom code doing the same thing in nouveau tree introduced new deadlock possibility, for which lockdep complains loudly: (...) Hey, Thanks for the report, I'll look at this more during the week. Deadlock scenario looks like this: CPU1CPU2 nouveau code calls some drm_mm.c function which takes mm-unused_lock nouveau_channel_free disables irqs and takes dev_priv-context_switch_lock calls nv50_graph_destroy_context which (... backtrace above) calls drm_mm_put_block which tries to take mm-unused_lock (spins) nouveau interrupt raises nouveau_irq_handler tries to take dev_priv-context_switch_lock (spins) deadlock It's important to note that the drm_mm referenced eventually by nv50_graph_destroy_context is per-channel on the card, so for the deadlock to happen it'd have to be multiple threads from a single process, one thread creating/destroying and object on the channel while another was trying to destroy the channel. Yeah, and that situation is impossible ATM because those functions are called with the BKL held. Possible solutions: - reverting drm/nouveau: use drm_mm in preference to custom code doing the same thing - disabling interrupts before calling drm_mm functions - unmaintainable and still deadlockable in multicard setups (nouveau and eg radeon) Agreed it's unmaintainable, but, as mentioned above, the relevant locks can't be touched by radeon. - making mm-unused_lock HARDIRQ-safe (patch below) - simple but with slight overhead I'll look more during the week, there's other solutions to be explored. So, did you find other solution? Some random ideas: - Make context_switch_lock HARDIRQ-unsafe. To avoid racing with the IRQ handler we'd have to disable interrupt dispatch on the card before taking context_switch_lock (i.e. at channel creation and destruction time), and the interrupt control registers would have to be protected with a IRQ safe spinlock. - Split the current destroy_context() hooks in two halves, the first one would be in charge of the PFIFO/PGRAPH-poking tasks (e.g. disable_context()), and the second one would take care of releasing the allocated resources (and it wouldn't need locking). Marcin ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel pgp5qMkN7xYxF.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Enabling TV-out with the nouveau driver
Hi, Adrian Popa adrian_gh.p...@romtelecom.ro writes: Hello, I've checked and i have a GeForce 4 MX 440, and i do see a TV-1 in xrandr but I didn't manage to configure it with xrandr. I've looked over [2] and by using xrandr --output TV-1 --right-of VGA-1 i managed to extend my desktop to my TV. Also, i see the window transparency effect keeps working ;) The problem is - I tried to configure xorg.conf but I didn't manage to add the displays side by side (the TV overlaps with the monitor from the top-left corner), even if they have different resolutions. I have attached my xorg.conf for reference. I realize I must be missing something trivial in the configuration. Anyone care to point it out? Thanks, Adrian Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files ModulePath /usr/lib/xorg/modules FontPath /usr/share/fonts/X11/misc FontPath /usr/share/fonts/X11/cyrillic FontPath /usr/share/fonts/X11/100dpi/:unscaled FontPath /usr/share/fonts/X11/75dpi/:unscaled FontPath /usr/share/fonts/X11/Type1 FontPath /usr/share/fonts/X11/100dpi FontPath /usr/share/fonts/X11/75dpi FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType FontPath built-ins EndSection Section Module Load record Load dri2 Load dri Load glx Load extmod Load dbe EndSection You probably don't need any of the last two sections. Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option ZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier VGA-1 DisplaySize 340 270 # mm VendorName NEC ModelNameLCD72VM HorizSync31.0 - 81.0 VertRefresh 56.0 - 75.0 Option DPMS You shouldn't need any of the options above. EndSection Section Monitor Identifier TV-1 Option RightOf Monitor0 The Monitor0 identifier is wrong, I guess you meant VGA-1. HorizSync30-50 VertRefresh 60 # 720x576 @ 50Hz, 31.25kHz, itu-r bt.1358 625/50/p/1:1, RGB, YPbPr, HDMI ModeLine 720x...@50 27 720 732 795 864 576 581 586 625 -hsync -vsync # nonstandard PAL (Works with BOB deinterlace) It is 60Hz but works well with nVIDIA PAL-B TV-OUT # Nvidia option: Option TVStandard PAL-B ModeLine 720x...@60 32.7 720 744 816 912 576 577 580 597 # This modeline is 50Hz interlaced and works well with kerneldeint: ModeLine 720x576i 13.875 720 744 808 888 576 581 586 625 -hsync -vsync interlace You shouldn't need to set any timings manually. EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option SWcursor# [bool] #Option HWcursor# [bool] #Option NoAccel # [bool] #Option ShadowFB# [bool] #Option UseFBDev# [bool] #Option Rotate # [str] #Option VideoKey# i #Option FlatPanel # [bool] #Option FPDither# [bool] #Option CrtcNumber # i #Option FPScale # [bool] #Option FPTweak # i #Option DualHead True # [bool] Identifier Card0 Driver nouveau VendorName nVidia Corporation BoardName NV18 [GeForce4 MX 440 AGP 8x] BusID PCI:2:0:0 Option Monitor-VGA-1 VGA-1 Option Monitor-TV-1 TV-1 EndSection Section Screen Identifier Screen0 Device Card0 #MonitorMonitor0 SubSection Display Viewport 0 0 Depth 1 EndSubSection SubSection Display Viewport 0 0 Depth 4 EndSubSection SubSection Display Viewport 0 0 Depth 8 EndSubSection SubSection Display Viewport 0 0 Depth 15 EndSubSection SubSection Display Viewport 0 0 Depth 16 EndSubSection SubSection Display Viewport 0 0 Depth 24 EndSubSection EndSection pgpWRxBxx7pHd.pgp Description: PGP signature
Re: [Nouveau] Enabling TV-out with the nouveau driver
Adrian Popa adrian_gh.p...@romtelecom.ro writes: Hello everyone, First of all - congratulations on the success of your project. It was about time the community did something about the nvidia drivers! :) Now, I'm still experimenting with nouveau and I have enabled it on a test system that has a rather old Nvidia card (GeForce4 I think) with tv-out. Everything works fine, but I haven't been able to find any examples on how to configure tv-out so I can extend my desktop to my TV. Which card exactly? nv1x-based gf4 cards should be fine but nv2x GPUs need an external TV encoder chip (and right now we only have a driver for ch7006 and similar external encoders). So, if your card has one of the supported encoders, you'll see a TV-1 connector in the output of xrandr. Can anyone help with a demo configuration of Xorg.conf? It's configured as a regular RandR12 output, so it should just work with the minimal xorg.conf [1], if you need to do something fancier like changing the relative output positions or setting TV-specific properties, see [2] and [3] (check out the TV-related kernel module parameters too, see modinfo nouveau). Also, I want to ask - if there is any chance of using two displays *and* enabling compositing (window transparency effects) - either with software or hardware acceleration? It should work, but keep in mind that nv1x cards have a rather crude pitch limitation (you'll get no hw accel if your desktop is larger than 2048x2048). By the way, I am using Xubuntu 10.04. Regards, Adrian ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau [1] http://nouveau.freedesktop.org/wiki/InstallNouveau [2] http://nouveau.freedesktop.org/wiki/Randr12 [3] http://wiki.debian.org/XStrikeForce/HowToRandR12 pgpPGWhbk2Mqf.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Spurious TV load detection on GeForce 6150 (no TV connector)
Renato Caldas seventhguard...@gmail.com writes:
Hello,
Since I've updated to F13 I keep getting blank screens at cold boot
with this card:
00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce
6150] (rev a2)
When I say cold boot I mean the first couple of times I turn on my
computer in the morning. After a couple of reboots I get plymouth to
show up, and then X11. This never happened with F12.
After comparing the logs (--- bad, +++ good), I found these:
(...)
input: ImPS/2 Generic Wheel Mouse as
/devices/platform/i8042/serio1/input/input4
-[drm] nouveau :00:05.0: Load detected on output B
-[drm] nouveau :00:05.0: allocated 1280x1024 fb: 0x49000, bo
880034ea0cd8
+[drm] nouveau :00:05.0: allocated 1280x1024 fb: 0x49000, bo
880034ea8cd8
fbcon: nouveaufb (fb0) is primary device
[drm] nouveau :00:05.0: Setting dpms mode 0 on vga encoder (output 0)
[drm] nouveau :00:05.0: Output VGA-1 is running on CRTC 0 using output B
-[drm] nouveau :00:05.0: Setting dpms mode 0 on TV encoder (output 2)
-[drm] nouveau :00:05.0: Output TV-1 is running on CRTC 1 using output B
-Console: switching to colour frame buffer device 90x36
+Console: switching to colour frame buffer device 160x64
fb0: nouveaufb frame buffer device
(...)
[drm] nouveau :00:05.0: Allocating FIFO number 1
[drm] nouveau :00:05.0: nouveau_channel_alloc: initialised FIFO 1
-[drm] nouveau :00:05.0: Setting dpms mode 3 on TV encoder (output 2)
[drm] nouveau :00:05.0: Allocating FIFO number 2
[drm] nouveau :00:05.0: nouveau_channel_alloc: initialised FIFO 2
(...)
Although this may seem like a hardware quirk (it may be, partially),
the fact is that I don't have a TV output, only VGA and DVI. So I
guess the driver shouldn't be looking for load on an nonexistent
output. This other log line may be relevant (or not):
Could you provide full kernel logs and the output from lspci -vvn?
Apr 13 08:35:30 localhost kernel: type=1400 audit(1271144119.830:4):
avc: denied { mmap_zero } for pid=462 comm=vbetool
scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023
tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
On the other hand, both CRTC's are using output B. I'm not that
familiar with the hardware, and this may be completely wrong, but I
assume an output can only be used by a single CRTC.
Yeah, that's correct.
Cheers,
Renato
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
pgpCanmIMRCZY.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Patch to fix make dist
Rico Tzschichholz ric...@t-online.de writes: A patch is attached to fix this problem. It removes the deprecated reference to README.NV1 and properly adds src/nv_rop.h Thanks, pushed. Thanks, Rico Tzschichholz ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgpILBOVUi07f.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau: Make use of TTM busy_placements.
Previously we were filling it the same as placements, but in some
cases there're valid alternatives that we were ignoring completely.
Keeping a back-up memory type helps on several low-mem situations.
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 61 ++---
drivers/gpu/drm/nouveau/nouveau_drv.h |4 ++-
drivers/gpu/drm/nouveau/nouveau_gem.c | 55 +
3 files changed, 61 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 0266124..418d881 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -153,7 +153,7 @@ nouveau_bo_new(struct drm_device *dev, struct
nouveau_channel *chan,
nvbo-placement.fpfn = 0;
nvbo-placement.lpfn = mappable ? dev_priv-fb_mappable_pages : 0;
- nouveau_bo_placement_set(nvbo, flags);
+ nouveau_bo_placement_set(nvbo, flags, 0);
nvbo-channel = chan;
ret = ttm_bo_init(dev_priv-ttm.bdev, nvbo-bo, size,
@@ -172,26 +172,33 @@ nouveau_bo_new(struct drm_device *dev, struct
nouveau_channel *chan,
return 0;
}
+static void
+set_placement_list(uint32_t *pl, unsigned *n, uint32_t type, uint32_t flags)
+{
+ *n = 0;
+
+ if (type TTM_PL_FLAG_VRAM)
+ pl[(*n)++] = TTM_PL_FLAG_VRAM | flags;
+ if (type TTM_PL_FLAG_TT)
+ pl[(*n)++] = TTM_PL_FLAG_TT | flags;
+ if (type TTM_PL_FLAG_SYSTEM)
+ pl[(*n)++] = TTM_PL_FLAG_SYSTEM | flags;
+}
+
void
-nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t memtype)
+nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t busy)
{
- int n = 0;
-
- if (memtype TTM_PL_FLAG_VRAM)
- nvbo-placements[n++] = TTM_PL_FLAG_VRAM | TTM_PL_MASK_CACHING;
- if (memtype TTM_PL_FLAG_TT)
- nvbo-placements[n++] = TTM_PL_FLAG_TT | TTM_PL_MASK_CACHING;
- if (memtype TTM_PL_FLAG_SYSTEM)
- nvbo-placements[n++] = TTM_PL_FLAG_SYSTEM |
TTM_PL_MASK_CACHING;
- nvbo-placement.placement = nvbo-placements;
- nvbo-placement.busy_placement = nvbo-placements;
- nvbo-placement.num_placement = n;
- nvbo-placement.num_busy_placement = n;
-
- if (nvbo-pin_refcnt) {
- while (n--)
- nvbo-placements[n] |= TTM_PL_FLAG_NO_EVICT;
- }
+ struct ttm_placement *pl = nvbo-placement;
+ uint32_t flags = TTM_PL_MASK_CACHING |
+ (nvbo-pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
+
+ pl-placement = nvbo-placements;
+ set_placement_list(nvbo-placements, pl-num_placement,
+ type, flags);
+
+ pl-busy_placement = nvbo-busy_placements;
+ set_placement_list(nvbo-busy_placements, pl-num_busy_placement,
+ type | busy, flags);
}
int
@@ -199,7 +206,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t memtype)
{
struct drm_nouveau_private *dev_priv = nouveau_bdev(nvbo-bo.bdev);
struct ttm_buffer_object *bo = nvbo-bo;
- int ret, i;
+ int ret;
if (nvbo-pin_refcnt !(memtype (1 bo-mem.mem_type))) {
NV_ERROR(nouveau_bdev(bo-bdev)-dev,
@@ -215,9 +222,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t memtype)
if (ret)
goto out;
- nouveau_bo_placement_set(nvbo, memtype);
- for (i = 0; i nvbo-placement.num_placement; i++)
- nvbo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
+ nouveau_bo_placement_set(nvbo, memtype, 0);
ret = ttm_bo_validate(bo, nvbo-placement, false, false);
if (ret == 0) {
@@ -244,7 +249,7 @@ nouveau_bo_unpin(struct nouveau_bo *nvbo)
{
struct drm_nouveau_private *dev_priv = nouveau_bdev(nvbo-bo.bdev);
struct ttm_buffer_object *bo = nvbo-bo;
- int ret, i;
+ int ret;
if (--nvbo-pin_refcnt)
return 0;
@@ -253,8 +258,7 @@ nouveau_bo_unpin(struct nouveau_bo *nvbo)
if (ret)
return ret;
- for (i = 0; i nvbo-placement.num_placement; i++)
- nvbo-placements[i] = ~TTM_PL_FLAG_NO_EVICT;
+ nouveau_bo_placement_set(nvbo, bo-mem.placement, 0);
ret = ttm_bo_validate(bo, nvbo-placement, false, false);
if (ret == 0) {
@@ -439,10 +443,11 @@ nouveau_bo_evict_flags(struct ttm_buffer_object *bo,
struct ttm_placement *pl)
switch (bo-mem.mem_type) {
case TTM_PL_VRAM:
- nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_TT);
+ nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_TT,
+TTM_PL_FLAG_SYSTEM);
break;
default:
- nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_SYSTEM);
+ nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_SYSTEM, 0);
break
[Nouveau] [PATCH] drm/nouveau: Never evict VRAM buffers to system.
VRAM-system is a synchronous operation: it involves scheduling a
VRAM-TT DMA transfer and stalling the CPU until it's finished so that
we can unbind the new memory from the translation tables. VRAM-TT can
always be performed asynchronously, even if TT is already full and we
have to move something out of it.
Additionally, allowing VRAM-system behaves badly under heavy memory
pressure because once we run out of TT, stuff starts to be moved back
and forth between VRAM and system, and the TT contents are hardly
renewed.
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
drivers/gpu/drm/nouveau/nouveau_bo.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 028719f..0266124 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -439,8 +439,7 @@ nouveau_bo_evict_flags(struct ttm_buffer_object *bo, struct
ttm_placement *pl)
switch (bo-mem.mem_type) {
case TTM_PL_VRAM:
- nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_TT |
-TTM_PL_FLAG_SYSTEM);
+ nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_TT);
break;
default:
nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_SYSTEM);
--
1.6.4.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: make sure initial kalloc for user bo ends up in the right place
Maarten Maathuis madman2...@gmail.com writes: - Currently reloc'ing a user bo to gart will first cause an allocation in vram, which is then cpu written to, then the bo gets moved to gart. Signed-off-by: Maarten Maathuis madman2...@gmail.com --- nouveau/nouveau_reloc.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/nouveau/nouveau_reloc.c b/nouveau/nouveau_reloc.c index 301482b..332dfa0 100644 --- a/nouveau/nouveau_reloc.c +++ b/nouveau/nouveau_reloc.c @@ -73,6 +73,12 @@ nouveau_reloc_emit(struct nouveau_channel *chan, struct nouveau_bo *reloc_bo, return -EINVAL; } + /* We're about to reloc a user buffer, better make sure we don't cause + * a double migration. + */ + if (!(nvbo-flags (NOUVEAU_BO_GART | NOUVEAU_BO_VRAM))) + nvbo-flags |= (flags (NOUVEAU_BO_GART | NOUVEAU_BO_VRAM)); + rpbbo = nouveau_bo_emit_buffer(chan, reloc_bo); if (!rpbbo) return -ENOMEM; Looks good to me: Acked-by: Francisco Jerez curroje...@riseup.net pgpX4oYFsUZ9k.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] renouveau/nv10: remove duplicate vertex buffer registers
Luca Barbieri l...@luca-barbieri.com writes: NV10TCL defines the vertex buffer registers both as arrays and as individual named registers. This causes duplicate register definitions and the individual registers are not used either by the DDX or by the Mesa driver. Francisco Jerez said to remove them all. I forgot to ask: why do they bother you? Signed-off-by: Luca Barbieri l...@luca-barbieri.com --- renouveau.xml | 49 - 1 files changed, 0 insertions(+), 49 deletions(-) diff --git a/renouveau.xml b/renouveau.xml index 8fb35a5..3fb9d9a 100644 --- a/renouveau.xml +++ b/renouveau.xml @@ -2498,55 +2498,6 @@ bitfield name=STRIDE high=15 low=8 type=int/ bitfield name=POS_HOMOGENEOUS high=24 low=24 type=boolean/ /reg32 - -reg32 offset=0x0d00 name=VERTEX_ARRAY_OFFSET_POS type=hexa/ -reg32 offset=0x0d04 name=VERTEX_ARRAY_FORMAT_POS type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 -reg32 offset=0x0d08 name=VERTEX_ARRAY_OFFSET_COL type=hexa/ -reg32 offset=0x0d0c name=VERTEX_ARRAY_FORMAT_COL type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 -reg32 offset=0x0d10 name=VERTEX_ARRAY_OFFSET_COL2 type=hexa/ -reg32 offset=0x0d14 name=VERTEX_ARRAY_FORMAT_COL2 type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 -reg32 offset=0x0d18 name=VERTEX_ARRAY_OFFSET_TX0 type=hexa/ -reg32 offset=0x0d1c name=VERTEX_ARRAY_FORMAT_TX0 type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 -reg32 offset=0x0d20 name=VERTEX_ARRAY_OFFSET_TX1 type=hexa/ -reg32 offset=0x0d24 name=VERTEX_ARRAY_FORMAT_TX1 type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 -reg32 offset=0x0d28 name=VERTEX_ARRAY_OFFSET_NOR type=hexa/ -reg32 offset=0x0d2c name=VERTEX_ARRAY_FORMAT_NOR type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 -reg32 offset=0x0d30 name=VERTEX_ARRAY_OFFSET_WGH type=hexa/ -reg32 offset=0x0d34 name=VERTEX_ARRAY_FORMAT_WGH type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 -reg32 offset=0x0d38 name=VERTEX_ARRAY_OFFSET_FOG type=hexa/ -reg32 offset=0x0d3c name=VERTEX_ARRAY_FORMAT_FOG type=bitfield - bitfield name=TYPE high=3 low=0 type=int/ - bitfield name=FIELDS high=7 low=4 type=int/ - bitfield name=STRIDE high=15 low=8 type=int/ -/reg32 reg32 offset=0x0dfc name=VERTEX_BEGIN_END type=enum enum_name=nv10_begin_end/ reg32 offset=0x0e00 name=VB_ELEMENT_U16 type=bitfield bitfield name=I0 high=15 low=0 type=int/ pgpk2Hr4RBZSm.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce 6150SE: DVI-connector not detected
Hi, Frank Schaefer fschaefer@googlemail.com writes: Hi, today I tested kernel 2.6.33 and it seems that nouveau doesn't detect the DVI-connector of my GeForce 6150SE (Asus M2N-VM DH). The screen turns black during boot-process immediately after the [drm] nouveau ... messages appeared. It looks like your IGP uses some sort of weird-ass external TMDS encoder, an mmiotrace from the blob enabling DVI on this card might be useful, see [1] and the mmiotrace docs in the linux kernel tree for the details. [1] http://nouveau.freedesktop.org/wiki/MmioTrace The board has two connectors (DVI + VGA) and I'm using the DVI-connector only. Everything is fine when I use a VGA-cable instead. See boot.msg in the attachment. Please tell me if you need further informations. I can also test patches. Regards, Frank Schaefer pgp7hLc5k0Sct.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/2] drm/nouveau: Unmap pushbuf BOs when we're done with them.
If you're especially unlucky BOs would move around and their kmaps would end up pointing to something else in GART, then ioctl_pushbuf() would use the kmaps again corrupting textures or other pushbufs (the most noticeable symptom was a PFIFO_DMA_PUSHER from time to time). Signed-off-by: Francisco Jerez curroje...@riseup.net --- drivers/gpu/drm/nouveau/nouveau_gem.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index fb6d87b..ec6da5c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -243,6 +243,8 @@ validate_fini_list(struct list_head *list, struct nouveau_fence *fence) nouveau_fence_unref((void *)prev_fence); } + ttm_bo_kunmap(nvbo-kmap); + list_del(nvbo-entry); nvbo-reserved_by = NULL; ttm_bo_unreserve(nvbo-bo); -- 1.6.4.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/2] drm/nouveau: Don't reuse the same variable in a nested loop.
Signed-off-by: Francisco Jerez curroje...@riseup.net --- drivers/gpu/drm/nouveau/nouveau_gem.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index ec6da5c..173d5e2 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -578,7 +578,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, struct nouveau_channel *chan; struct validate_op op; struct nouveau_fence *fence = 0; - int i, ret = 0, do_reloc = 0; + int i, j, ret = 0, do_reloc = 0; NOUVEAU_CHECK_INITIALISED_WITH_RETURN; NOUVEAU_GET_USER_CHANNEL_WITH_RETURN(req-channel, file_priv, chan); @@ -700,7 +700,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, OUT_RING(chan, ((mem-start PAGE_SHIFT) + push[i].offset) | 0x2000); OUT_RING(chan, 0); - for (i = 0; i NOUVEAU_DMA_SKIPS; i++) + for (j = 0; j NOUVEAU_DMA_SKIPS; j++) OUT_RING(chan, 0); } } -- 1.6.4.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: fix pramdac_table range checking
Marcin Slusarz marcin.slus...@gmail.com writes:
On Mon, Feb 15, 2010 at 03:40:56PM +0300, Dan Carpenter wrote:
This is the results from:
make C=1 CHECK=/path/to/smatch -p=kernel bzImage modules | tee
warns.txt
grep -w overflow warns.txt | uniq -f 3 | tee err-list
I hacked on the buffer overflow check last weekend and these are the
results. It has way more false positives than the other bug lists
I've posted, but it's still kinda neat.
It works like this:
lib/zlib_inflate/inftrees.c
112 for (min = 1; min = MAXBITS; min++)
113 if (count[min] != 0) break;
114 if (root min) root = min;
smatch thinks min can be MAXBITS here.
One bad thing is that if you have code like:
if (foo == 42)
frob();
Smatch thinks that foo can be 43 after the if statement.
The format is:
file.c +line function(lines into function) warning 'array_name' array
size = offset
regards,
dan carpenter
Previous bug lists:
* Putting too much data on the stack
http://lkml.indiana.edu/hypermail/linux/kernel/1002.1/01252.html
* Assigning negative values to unsigned variables
http://lkml.indiana.edu/hypermail/linux/kernel/1001.3/01222.html
* Doing dma on the stack
http://lkml.indiana.edu/hypermail/linux/kernel/1001.3/01231.html
* Dereferencing variables before verifying they are not null
http://lkml.indiana.edu/hypermail/linux/kernel/1001.3/01980.html
(...)
drivers/gpu/drm/nouveau/nouveau_bios.c +770 get_tmds_index_reg(36) error:
buffer overflow 'pramdac_table' 4 = 4
(...)
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] drm/nouveau: fix pramdac_table range checking
get_tmds_index_reg reads some value from stack when mlv happens
to be equal to size of pramdac_table array. Fix it.
Reported-by: Dan Carpenter erro...@gmail.com
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 2cd0fad..e7be506 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -762,7 +762,7 @@ static uint32_t get_tmds_index_reg(struct drm_device
*dev, uint8_t mlv)
dacoffset ^= 8;
return 0x6808b0 + dacoffset;
} else {
- if (mlv ARRAY_SIZE(pramdac_table)) {
+ if (mlv = ARRAY_SIZE(pramdac_table)) {
NV_ERROR(dev, Magic Lookup Value too big (%02X)\n,
mlv);
return 0;
Thanks. I've pushed all the three patches.
pgpv5wIlrdWno.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] Revert kms: work around some bong hits with dpms
This reverts commit 98c9e4edb58374f18249e5c9c53b392fb8b4a1d1. AFAIK
it's no longer needed.
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
src/drmmode_display.c |3 ---
src/nv_driver.c |2 --
src/nv_type.h |1 -
3 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7c45d9c..a91741d 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -651,9 +651,6 @@ drmmode_output_dpms(xf86OutputPtr output, int mode)
drmmode_ptr drmmode = drmmode_output-drmmode;
int mode_id = -1, i;
- if (!NVPTR(output-scrn)-allow_dpms)
- return;
-
for (i = 0; i koutput-count_props; i++) {
props = drmModeGetProperty(drmmode-fd, koutput-props[i]);
if (props (props-flags DRM_MODE_PROP_ENUM)) {
diff --git a/src/nv_driver.c b/src/nv_driver.c
index 3908347..7149759 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -331,10 +331,8 @@ NVEnterVT(int scrnIndex, int flags)
if (ret)
ErrorF(Unable to get master: %d\n, ret);
- pNv-allow_dpms = FALSE;
if (!xf86SetDesiredModes(pScrn))
return FALSE;
- pNv-allow_dpms = TRUE;
if (pNv-overlayAdaptor pNv-Architecture != NV_ARCH_04)
NV10WriteOverlayParameters(pScrn);
diff --git a/src/nv_type.h b/src/nv_type.h
index 989812b..18ea3bb 100644
--- a/src/nv_type.h
+++ b/src/nv_type.h
@@ -69,7 +69,6 @@ typedef struct _NVRec {
drmVersionPtr pKernelDRMVersion;
void *drmmode; /* for KMS */
- Bool allow_dpms;
/* DRM interface */
struct nouveau_device *dev;
--
1.6.4.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Remove some UMS leftovers.
Marcin Kościelnicki koria...@0x04.net writes:
---
src/nv_driver.c | 32 +---
1 files changed, 1 insertions(+), 31 deletions(-)
diff --git a/src/nv_driver.c b/src/nv_driver.c
index 248a151..9606d97 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -315,8 +315,6 @@ NVAdjustFrame(int scrnIndex, int x, int y, int flags)
/*
* This is called when VT switching back to the X server. Its job is
* to reinitialise the video mode.
- *
- * We may wish to unmap video/MMIO memory too.
*/
/* Mandatory */
@@ -333,9 +331,6 @@ NVEnterVT(int scrnIndex, int flags)
if (ret)
ErrorF(Unable to get master: %d\n, ret);
- if (!pNv-NoAccel)
- NVAccelCommonInit(pScrn);
-
pNv-allow_dpms = FALSE;
if (!xf86SetDesiredModes(pScrn))
return FALSE;
@@ -350,8 +345,6 @@ NVEnterVT(int scrnIndex, int flags)
/*
* This is called when VT switching away from the X server. Its job is
* to restore the previous (text) mode.
- *
- * We may wish to remap video/MMIO memory too.
*/
/* Mandatory */
@@ -586,24 +579,6 @@ NVPreInit(ScrnInfoPtr pScrn, int flags)
MessageType from;
int ret, i;
- if (flags PROBE_DETECT) {
- EntityInfoPtr pEnt = xf86GetEntityInfo(pScrn-entityList[0]);
-
- if (!pEnt)
- return FALSE;
-
- i = pEnt-index;
- xfree(pEnt);
-
- if (xf86LoadSubModule(pScrn, vbe)) {
- vbeInfoPtr pVbe = VBEInit(NULL, i);
- ConfiguredMonitor = vbeDoEDID(pVbe, NULL);
- vbeFree(pVbe);
- }
-
- return TRUE;
- }
-
/*
* Note: This function is only called once at server startup, and
* not at the start of each server generation. This means that
@@ -733,11 +708,6 @@ NVPreInit(ScrnInfoPtr pScrn, int flags)
xf86GetVisualName(pScrn-defaultVisual),
pScrn-depth);
}
- /* The vgahw module should be loaded here when needed */
- if (!xf86LoadSubModule(pScrn, vgahw)) {
- NVPreInitFail(\n);
- }
-
/* We use a programmable clock */
pScrn-progClock = TRUE;
@@ -905,7 +875,7 @@ NVMapMem(ScrnInfoPtr pScrn)
}
/*
- * Unmap the framebuffer and MMIO memory.
+ * Unmap the framebuffer and offscreen memory.
*/
static Bool
Thanks, pushed with some minor changes.
pgphiGBUqv56L.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [RFC] Merge of a reincarnation of the nouveau classic mesa driver.
For a long time the gallium pipe drivers for nvidia fixed function cards (nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and godforsaken -- especially nv0x and nv1x had seen almost no progress since their creation. They've recently grown a classic mesa driver which implements many new features: texturing, hardware-accelerated tnl. However the killer feature is it actually draws stuff (and if you're lucky even some simple games at reasonable FPS) so I don't like to consider this a step back. Right now it is located in a git repo here [1], mesa-next is the branch I'm proposing to merge. I'll reply myself with the patches affecting core mesa it depends on, to give them more visibility. Of course driver-related comments are welcome too. [1] http://cgit.freedesktop.org/~currojerez/mesa/ configure.ac |2 +- src/gallium/docs/source/distro.rst | 15 - src/gallium/drivers/nouveau/Makefile |3 +- src/gallium/drivers/nouveau/nouveau_winsys.h | 18 - src/gallium/drivers/nouveau/nv04_surface_2d.c | 547 + src/gallium/drivers/nouveau/nv04_surface_2d.h | 37 + src/gallium/drivers/nv04/Makefile | 21 - src/gallium/drivers/nv04/nv04_clear.c | 12 - src/gallium/drivers/nv04/nv04_context.c| 112 --- src/gallium/drivers/nv04/nv04_context.h| 148 src/gallium/drivers/nv04/nv04_fragprog.c | 21 - src/gallium/drivers/nv04/nv04_fragtex.c| 73 -- src/gallium/drivers/nv04/nv04_miptree.c| 146 src/gallium/drivers/nv04/nv04_prim_vbuf.c | 339 src/gallium/drivers/nv04/nv04_screen.c | 222 - src/gallium/drivers/nv04/nv04_screen.h | 30 - src/gallium/drivers/nv04/nv04_state.c | 459 --- src/gallium/drivers/nv04/nv04_state.h | 72 -- src/gallium/drivers/nv04/nv04_state_emit.c | 246 -- src/gallium/drivers/nv04/nv04_surface.c| 63 -- src/gallium/drivers/nv04/nv04_surface_2d.c | 547 - src/gallium/drivers/nv04/nv04_surface_2d.h | 37 - src/gallium/drivers/nv04/nv04_transfer.c | 178 - src/gallium/drivers/nv04/nv04_vbo.c| 78 -- src/gallium/drivers/nv10/Makefile | 20 - src/gallium/drivers/nv10/nv10_clear.c | 14 - src/gallium/drivers/nv10/nv10_context.c| 298 --- src/gallium/drivers/nv10/nv10_context.h| 151 src/gallium/drivers/nv10/nv10_fragprog.c | 21 - src/gallium/drivers/nv10/nv10_fragtex.c| 130 --- src/gallium/drivers/nv10/nv10_miptree.c| 165 src/gallium/drivers/nv10/nv10_prim_vbuf.c | 267 --- src/gallium/drivers/nv10/nv10_screen.c | 208 - src/gallium/drivers/nv10/nv10_screen.h | 28 - src/gallium/drivers/nv10/nv10_state.c | 590 -- src/gallium/drivers/nv10/nv10_state.h | 140 src/gallium/drivers/nv10/nv10_state_emit.c | 333 src/gallium/drivers/nv10/nv10_surface.c| 63 -- src/gallium/drivers/nv10/nv10_transfer.c | 178 - src/gallium/drivers/nv10/nv10_vbo.c| 78 -- src/gallium/drivers/nv20/Makefile | 21 - src/gallium/drivers/nv20/nv20_clear.c | 14 - src/gallium/drivers/nv20/nv20_context.c| 424 -- src/gallium/drivers/nv20/nv20_context.h| 150 src/gallium/drivers/nv20/nv20_fragprog.c | 21 - src/gallium/drivers/nv20/nv20_fragtex.c| 130 --- src/gallium/drivers/nv20/nv20_miptree.c| 226 -- src/gallium/drivers/nv20/nv20_prim_vbuf.c | 440 -- src/gallium/drivers/nv20/nv20_screen.c | 204 - src/gallium/drivers/nv20/nv20_screen.h | 28 - src/gallium/drivers/nv20/nv20_state.c | 583 -- src/gallium/drivers/nv20/nv20_state.h | 140 src/gallium/drivers/nv20/nv20_state_emit.c | 426 -- src/gallium/drivers/nv20/nv20_surface.c| 63 -- src/gallium/drivers/nv20/nv20_transfer.c | 178 - src/gallium/drivers/nv20/nv20_vbo.c| 79 -- src/gallium/drivers/nv20/nv20_vertprog.c | 841 src/gallium/drivers/nv30/nv30_miptree.c|2 +- src/gallium/drivers/nv30/nv30_screen.h |2 +- src/gallium/drivers/nv40/nv40_miptree.c|2 +- src/gallium/drivers/nv40/nv40_screen.h |2 +- src/gallium/winsys/drm/nouveau/dri/Makefile|3 - .../winsys/drm/nouveau/drm/nouveau_drm_api.c | 18 - src/gallium/winsys/drm/nouveau/egl/Makefile|3 - src/gallium/winsys/drm/nouveau/xorg/Makefile |3 -
Re: [Nouveau] [PATCH 1/3] Introduce nouveau_bo_wait for waiting on a BO with a GPU channel
Luca Barbieri l...@luca-barbieri.com writes:
nouveau_bo_wait will make the GPU channel wait for fence if possible,
otherwise falling back to waiting with the CPU using ttm_bo_wait.
The nouveau_fence_sync function currently returns -ENOSYS, and is
the focus of the next patch.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
Just a few comments inline.
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 68
++-
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
drivers/gpu/drm/nouveau/nouveau_fence.c |6 +++
drivers/gpu/drm/nouveau/nouveau_gem.c | 20 +
4 files changed, 86 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index db0ed4c..8afc17e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -35,6 +35,70 @@
#include linux/log2.h
+int
+nouveau_bo_wait(struct ttm_buffer_object *bo, struct nouveau_channel *chan)
+{
+ int ret = 0;
+
+ if (likely(!bo-sync_obj))
+ return 0;
+
+ spin_lock(bo-lock);
+ if (chan) {
+ struct nouveau_fence *new_fence;
+ struct nouveau_channel *waited_chan;
+
+ do {
+ struct nouveau_fence *prev_fence;
+ prev_fence = bo-sync_obj;
+
+ waited_chan = nouveau_fence_channel(prev_fence);
+ if (likely(!waited_chan || waited_chan == chan))
+ break;
+
+ nouveau_fence_ref(prev_fence);
+
+ ret = ttm_bo_wait(bo, false, false, true);
+ if (!ret)
+ goto unref_break;
+
+ if (unlikely(prev_fence != bo-sync_obj))
+ goto unref_continue;
+
+ spin_unlock(bo-lock);
+ new_fence = nouveau_fence_sync(prev_fence, chan);
+ spin_lock(bo-lock);
+
+ if (likely(!IS_ERR(new_fence))) {
+ if (likely(bo-sync_obj)) {
+ if (unlikely(bo-sync_obj !=
prev_fence)) {
+ nouveau_fence_unref((void
**)new_fence);
+ continue;
+ }
+ nouveau_fence_unref((void
**)bo-sync_obj);
+ }
+ bo-sync_obj = new_fence;
+ ret = 0;
+unref_break:
+ nouveau_fence_unref((void **)prev_fence);
+ break;
+ }
+
+ if (unlikely(prev_fence != bo-sync_obj)) {
+unref_continue:
+ nouveau_fence_unref((void **)prev_fence);
+ continue;
+ }
+
+ nouveau_fence_unref((void **)prev_fence);
+ ret = ttm_bo_wait(bo, false, false, false);
+ } while (0);
+ } else
+ ret = ttm_bo_wait(bo, false, false, false);
+ spin_unlock(bo-lock);
+ return ret;
+}
I believe this looping will become unnecessary if the IRQ-fencing
patches get in, as every sync_obj will be usable as a SEMAPHORE_ACQUIRE
target.
+
static void
nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
{
@@ -469,8 +533,10 @@ nouveau_bo_move_accel_cleanup(struct nouveau_channel
*chan,
ret = ttm_bo_move_accel_cleanup(nvbo-bo, fence, NULL,
evict, no_wait, new_mem);
+
+ /* TODO: this should be redundant, since we do the check in validate */
if (nvbo-channel nvbo-channel != chan)
- ret = nouveau_fence_wait(fence, NULL, false, false);
+ ret = nouveau_bo_wait(nvbo-bo, nvbo-channel);
nouveau_fence_unref((void *)fence);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 5445cef..2b78ee6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -1110,6 +1110,7 @@ extern int nv04_crtc_create(struct drm_device *, int
index);
/* nouveau_bo.c */
extern struct ttm_bo_driver nouveau_bo_driver;
+extern int nouveau_bo_wait(struct ttm_buffer_object *bo, struct
nouveau_channel *chan);
extern int nouveau_bo_new(struct drm_device *, struct nouveau_channel *,
int size, int align, uint32_t flags,
uint32_t tile_mode, uint32_t tile_flags,
@@ -1135,6 +1136,7 @@ extern int nouveau_fence_emit(struct nouveau_fence *);
struct nouveau_channel *nouveau_fence_channel(struct nouveau_fence *);
extern bool nouveau_fence_signalled(void *obj, void *arg);
extern int nouveau_fence_wait(void
Re: [Nouveau] [PATCH 2/3] drm/nouveau: add lockless dynamic semaphore allocator
Luca Barbieri l...@luca-barbieri.com writes:
This patch adds code to allocate semaphores in a dynamic way using
an algorithm with a lockless fast path.
1. Semaphore BOs
Semaphore BOs are BOs containing semaphores. Each is 4KB large and
contains 1024 4-byte semaphores. They are pinned.
Semaphore BOs are allocated on-demand and freed at device takedown.
Those that are not fully allocated are kept on a free list.
Each is assigned an handle. DMA objects and references are created
on demand for each channel that needs to use a semaphore BO.
Those objects and references are automatically destroyed at channel
destruction time.
Typically only a single semaphore BO will be needed.
2. Semaphore allocation
Each semaphore BO contains a bitmask of free semaphores within the BO.
Allocation is done in a lockless fashion using a count of free
semaphores and the bitmask.
Semaphores are released once the fence on the waiting side passed.
This is done by adding fields to nouveau_fence.
Semaphore values are zeroed when the semaphore BO is allocated, and
are afterwards only modified by the GPU.
This is performed by storing a bitmask that allows to alternate
between using the values 0 and 1 for a given semaphore.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/nouveau/nouveau_dma.h |1 +
drivers/gpu/drm/nouveau/nouveau_drv.h |7 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 243
+++
drivers/gpu/drm/nouveau/nouveau_state.c |4 +
4 files changed, 255 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.h
b/drivers/gpu/drm/nouveau/nouveau_dma.h
index dabfd65..0658979 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dma.h
+++ b/drivers/gpu/drm/nouveau/nouveau_dma.h
@@ -69,6 +69,7 @@ enum {
NvGdiRect = 0x800c,
NvImageBlit = 0x800d,
NvSw= 0x800e,
+ NvSem = 0x8100, /* range of 16M handles */
/* G80+ display objects */
NvEvoVRAM = 0x0100,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 2b78ee6..0a7abc7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -620,6 +620,11 @@ struct drm_nouveau_private {
struct {
struct dentry *channel_root;
} debugfs;
+
+ spinlock_t sem_bo_free_list_lock;
+ struct nouveau_sem_bo *sem_bo_free_list;
+ atomic_t sem_handles;
+ uint32_t sem_max_handles;
};
static inline struct drm_nouveau_private *
@@ -1141,6 +1146,8 @@ extern int nouveau_fence_flush(void *obj, void *arg);
extern void nouveau_fence_unref(void **obj);
extern void *nouveau_fence_ref(void *obj);
extern void nouveau_fence_handler(struct drm_device *dev, int channel);
+extern void nouveau_fence_device_init(struct drm_device *dev);
+extern void nouveau_fence_device_takedown(struct drm_device *dev);
/* nouveau_gem.c */
extern int nouveau_gem_new(struct drm_device *, struct nouveau_channel *,
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 9b1c2c3..01152f3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -32,6 +32,13 @@
#define USE_REFCNT (dev_priv-card_type = NV_10)
+#define NOUVEAU_SEM_BO_SIZE PAGE_SIZE
+
+/* reading fences can be very expensive
+ * use a threshold that would only use up half a single sem_bo
+ */
+#define NOUVEAU_SEM_MIN_THRESHOLD (NOUVEAU_SEM_BO_SIZE /
(NOUVEAU_MAX_CHANNEL_NR * 2))
+
struct nouveau_fence {
struct nouveau_channel *channel;
struct kref refcount;
@@ -47,6 +54,218 @@ nouveau_fence(void *sync_obj)
return (struct nouveau_fence *)sync_obj;
}
+struct nouveau_sem_bo {
+ struct nouveau_sem_bo *next;
+ struct nouveau_bo *bo;
+ uint32_t handle;
+
+ /* = 0: num_free + 1 slots are free, sem_bo is or is about to be on
free_list
+ -1: all allocated, sem_bo is NOT on free_list
+ */
+ atomic_t num_free;
+
+ DECLARE_BITMAP(free_slots, NOUVEAU_SEM_BO_SIZE / sizeof(uint32_t));
+ DECLARE_BITMAP(values, NOUVEAU_SEM_BO_SIZE / sizeof(uint32_t));
+ DECLARE_BITMAP(channels, NOUVEAU_MAX_CHANNEL_NR);
+};
+
+struct nouveau_sem {
+ struct nouveau_sem_bo *sem_bo;
+ unsigned num;
+ uint32_t value;
+};
+
+struct nouveau_sem_bo*
+nouveau_sem_bo_alloc(struct drm_device *dev)
+{
+ struct nouveau_sem_bo *sem_bo = kmalloc(sizeof(*sem_bo), GFP_KERNEL);
+ struct nouveau_bo *bo;
+ int flags = TTM_PL_FLAG_VRAM;
+ int ret;
+ bool is_iomem;
+ void *mem;
+
+ sem_bo = kmalloc(sizeof(*sem_bo), GFP_KERNEL);
+
+ if (!sem_bo)
+ return 0;
+
+ ret = nouveau_bo_new(dev, NULL, NOUVEAU_SEM_BO_SIZE, 0, flags,
+ 0, 0x, true, true, bo);
+
Re: [Nouveau] [PATCH 2/3] drm/nouveau: add lockless dynamic semaphore allocator
Luca Barbieri l...@luca-barbieri.com writes: How often do we expect cross-channel sync to kick in? Maybe 2-3 times per frame? I suspect contentions will be rare enough to make spinlocks as fast as atomics for all real-life cases, and they don't have such a high maintainability cost. What do you guys think? For the case of a single (or a few) GL application the requirements are indeed modest. I'm not sure that spinlocks or an otherwise reduced solution would be much simpler. You basically would just avoid the retrying code. Also if you have a multithreaded/multiprocess GPGPU application on large SMP machine things may change, as you may have a lot of commands and semaphores in flight, as well as high contention for anything global. Sounds like premature optimization to me. I'm just stating my personal view here, but I have a feeling a patch with 60% of lines could do very well the same for most realistic cases. Maarten, Ben, what do you think about this? Of course, currently we hold both the BKL and struct_mutex around things, which makes it all moot, but hopefully we'll switch to per-channel mutexes soon (I'm looking into that). BTW, the kernel has some linked list helpers you might want to use for sem_bo_free_list, and probably the best place for the sem stuff to live is dev_priv-fence instead of the root of drm_nouveau_private. pgpECYGXD4Dlu.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: call ttm_bo_wait with the bo lock held to prevent hang
Luca Barbieri l...@luca-barbieri.com writes: Please apply or state objections to this patch. Thanks. Thanks, pushed. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau pgpBVw1pLElgT.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Luca Barbieri l...@luca-barbieri.com writes: At a first glance: 1) We probably *will* need a delayed destroyed workqueue to avoid wasting memory that otherwise should be freed to the system. At the very least, the delayed delete process should optionally be run by a system shrinker. You are right. For VRAM we don't care since we are the only user, while for system backed memory some delayed destruction will be needed. The logical extension of the scheme would be for the Linux page allocator/swapper to check for TTM buffers to destroy when it would otherwise shrink caches, try to swap and/or wait on swap to happen. Not sure whether there are existing hooks for this or where exactly to hook this code. 2) Fences in TTM are currently not necessarily strictly ordered, and sequence numbers are hidden from the bo code. This means, for a given FIFO, fence sequence 3 may expire before fence sequence 2, depending on the usage of the buffer. My definition of channel (I sometimes used FIFO incorrectly as a synonym of that) is exactly a set of fences that are strictly ordered. If the card has multiple HW engines, each is considered a different channel (so that a channel becomes a (fifo, engine) pair). We may need however to add the concept of a sync domain that would be a set of channels that support on-GPU synchronization against each other. This would model hardware where channels with the same FIFO can be synchronized together but those with different FIFOs don't, and also multi-core GPUs where synchronization might be available only inside each core and not across cores. To sum it up, a GPU consists of a set of sync domains, each consisting of a set of channels, each consisting of a sequence of fences, with the following rules: 1. Fences within the same channel expire in order 2. If channels A and B belong to the same sync domain, it's possible to emit a fence on A that is guaranteed to expire after an arbitrary fence of B Whether channels have the same FIFO or not is essentially a driver implementation detail, and what TTM cares about is if they are in the same sync domain. [I just made up sync domain here: is there a standard term?] This assumes that the synchronizability graph is a disjoint union of complete graphs. Is there any example where it is not so? Also, does this actually model correctly Poulsbo, or am I wrong? Note that we could use CPU mediation more than we currently do. For instance now Nouveau, to do inter-channel synchronization, simply waits on the fence with the CPU immediately synchronously, while it could instead queue the commands in software, and with an interrupt/delayed mechanism submit them to hardware once the fence to be waited for is expired. Nvidia cards have a synchronization primitive that could be used to synchronize several FIFOs in hardware (AKA semaphores, see [1] for an example). ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau [1] http://lists.freedesktop.org/archives/nouveau/2009-December/004514.html pgpPDUkLn0FBH.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Luca Barbieri l...@luca-barbieri.com writes: Nvidia cards have a synchronization primitive that could be used to synchronize several FIFOs in hardware (AKA semaphores, see [1] for an example). Does this operate wholly on the GPU on all nVidia cards? It seems that at least on some GPUs this will trigger software methods that are basically a way for the GPU to trigger an interrupt and stop the FIFO until the CPU handles the interrupt and restarts it. Yes, it could be handled without software methods, Maarten (CC'ed) was looking into this, IIRC. Also, is there a way on nVidia cards to get interrupts on fences, but only where the fence sequence number is higher than a dynamically set value? (so that one could sleep for fence X without getting an interrupt for every single fence before that) If not, it could possibly be hacked around by reading from a DMA object at the address of the fence sequence number and then resizing the DMA object so that addresses from a certain point on would trigger a protection fault interrupt. I don't think you can safely modify a DMA object without stalling the card completely, but i think you could use e.g. PGRAPH NOTIFY interrupts and disable them by flipping a bit in PGRAPH when you stop caring about them. pgpJlRQwUx57K.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Luca Barbieri l...@luca-barbieri.com writes: If not, it could possibly be hacked around by reading from a DMA object at the address of the fence sequence number and then resizing the DMA object so that addresses from a certain point on would trigger a protection fault interrupt. I don't think you can safely modify a DMA object without stalling the card completely, but i think you could use e.g. PGRAPH NOTIFY interrupts and disable them by flipping a bit in PGRAPH when you stop caring about them. The problem is that one needs to disable them *before* the one he cares about. Suppose the card is at fence 0 and we are interested in fence 1000 expiring. That isn't the most common case. You typically don't expect the card to get further than 3-4 pushbufs behind the CPU. If we just enable interrupts, then we are going to be interrupted uselessly 1000 times. Instead, we would like to tell the card send me interrupts for fences, but only for fence number 1000 (or higher). This way one could for instance render a whole scene, and then desiring to read it into the CPU, just ask for an interrupt once rendering is done (i.e. wait for the framebuffer fence) and get a single interrupt, while we cleanly sleep undisturbed in the meantime. Basically, it would just need some way of *conditionally* causing interrupts. If there is none, then maybe we could insert a call to a fence mini-pushbuffer filled with NOPs that could be overwritten with an interrupt request on demand? The card also keeps some internal FIFO caches, so it seems to me that getting that safe of races and efficient at the same time could be a bit non-trivial. Or alternatively, construct such a pushbuffer with the 2D or 3D engines, starting from our 1000 input and the fence value generated by the 3D engine? (this is likely to be slow though). Or some hack like the DMA object resizing? (would it crash the GPU? or just not work due to it caching the previous size?) pgpxgRnpPl0JA.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Acknowledge DMA_VTX_PROTECTION PGRAPH interrupts
Luca Barbieri l...@luca-barbieri.com writes:
Currently Nouveau is unable to dismiss DMA_VTX_PROTECTION errors,
which results in an infinite loop in the interrupt handler.
These errors are caused both by bugs in the Gallium driver and by
user-specified index buffers with out of bounds indices.
By mmio-tracing the nVidia drivers, I found out how this is done.
On DMA_VTX_PROTECTION, The nVidia driver reads the register 0x402000,
always getting the value 4, and then writes 4 back to 0x402000.
This patch adds that logic by reading 0x402000 and writing the same
value back.
It's unclear what should happen if the value read is not 4, and
the current approach might not be the correct one.
To test this, modify mesa/progs/trivial/vbo-drawrange.c, defining
ELTOBJ to 1 and replacing indices with huge out of bounds integers.
Without this patch, the GPU and/or kernel should lock up.
With this patch, it should misrender as expected but not lock up.
The errors are still logged since they are useful for development.
This has been tested on NV49 and may not work on other cards.
To find out how things work on other cards, run the aforementioned
test using the blob with mmiotrace and grep for a read of the PGRAPH
source register.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/nouveau/nouveau_irq.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index 919a619..14de5a1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_irq.c
+++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
@@ -483,9 +483,16 @@ nouveau_pgraph_intr_error(struct drm_device *dev,
uint32_t nsource)
if (nsource NV03_PGRAPH_NSOURCE_ILLEGAL_MTHD) {
if (nouveau_pgraph_intr_swmthd(dev, trap))
unhandled = 1;
- } else {
+ } else if(nsource NV03_PGRAPH_NSOURCE_DMA_VTX_PROTECTION) {
+ uint32_t v = nv_rd32(dev, 0x402000);
+ nv_wr32(dev, 0x402000, v);
+
+ /* dump the error anyway for now: it's useful for
+Gallium development */
unhandled = 1;
}
+ else
+ unhandled = 1;
if (unhandled nouveau_ratelimit())
nouveau_graph_dump_trap_info(dev, PGRAPH_ERROR, trap);
Both pushed. Thanks!
pgpS9yslnndbX.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching.
Fixes errors like:
reserve_ram_pages_type failed 0x15b7a000-0x15b7b000, track 0x8, req 0x10
when a BO is moved between WC and UC areas.
Reported-by: Xavier Chantry shinin...@gmail.com
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
drivers/gpu/drm/ttm/ttm_tt.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 9c2b1cc..e2123af 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -198,17 +198,26 @@ EXPORT_SYMBOL(ttm_tt_populate);
static inline int ttm_tt_set_page_caching(struct page *p,
enum ttm_caching_state c_state)
{
+ int ret = 0;
+
if (PageHighMem(p))
return 0;
- switch (c_state) {
- case tt_cached:
- return set_pages_wb(p, 1);
- case tt_wc:
- return set_memory_wc((unsigned long) page_address(p), 1);
- default:
- return set_pages_uc(p, 1);
+ if (get_page_memtype(p) != -1) {
+ /* p isn't in the default caching state, set it to
+* writeback first to free its current memtype. */
+
+ ret = set_pages_wb(p, 1);
+ if (ret)
+ return ret;
}
+
+ if (c_state == tt_wc)
+ ret = set_memory_wc((unsigned long) page_address(p), 1);
+ else if (c_state == tt_uncached)
+ ret = set_pages_uc(p, 1);
+
+ return ret;
}
#else /* CONFIG_X86 */
static inline int ttm_tt_set_page_caching(struct page *p,
--
1.6.4.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Removal of Non-KMS support
Ben Skeggs skeg...@gmail.com writes:
I did a very quick pass at removing all the non-KMS support from the
DDX. It's tested on G80 but nowhere else currently, I thought some
discussion would be a good idea rather than just ripping it out :)
The non-KMS paths are messy, and lets face it, rotting badly. IMO the
KMS code is stable enough now that we can continue without the UMS
crutch, and indeed, the KMS code supports a lot more chipsets
(particularly on GF8 and up) than the UMS code ever will.
I've left the Xv overlay code intact, but ifdef'd out. I want to bring
support back with KMS enabled (thinking of older chipsets where the
blitter sucks), so it made sense to leave the old code there for now.
So, who has some Signed-off-by's :)
I'm very happy that we're finally getting rid of this :), besides a few
comments, you got my blessing:
Signed-off-by: Francisco Jerez curroje...@riseup.net
Ben.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Some snips from the patch in question:
[...]
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index e37e7c1..3d2df8d 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
[...]
+#define SOURCE_MASK_INTERLEAVE 32
+#define TRANSPARENT_PIXEL 0
+
+/*
+ * Convert a source/mask bitmap cursor to an ARGB cursor, clipping or
+ * padding as necessary. source/mask are assumed to be alternated each
+ * SOURCE_MASK_INTERLEAVE bits.
+ */
+static void
+nv_cursor_convert_cursor(uint32_t *src, void *dst, int src_stride,
+ int dst_stride, int bpp, uint32_t fg, uint32_t bg)
+{
+ int width = min(src_stride, dst_stride);
+ uint32_t b, m, pxval;
+ int i, j, k;
+
+ for (i = 0; i width; i++) {
+ for (j = 0; j width / SOURCE_MASK_INTERLEAVE; j++) {
+ int src_off = i*src_stride/SOURCE_MASK_INTERLEAVE + j;
+ int dst_off = i*dst_stride + j*SOURCE_MASK_INTERLEAVE;
+
+ b = src[2*src_off];
+ m = src[2*src_off + 1];
+
+ for (k = 0; k SOURCE_MASK_INTERLEAVE; k++) {
+ pxval = TRANSPARENT_PIXEL;
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+ if (m 0x8000)
+ pxval = (b 0x8000) ? fg : bg;
+ b = 1;
+ m = 1;
+#else
+ if (m 1)
+ pxval = (b 1) ? fg : bg;
+ b = 1;
+ m = 1;
+#endif
+ if (bpp == 32)
+ ((uint32_t *)dst)[dst_off + k] = pxval;
+ else
+ ((uint16_t *)dst)[dst_off + k] = pxval;
+ }
+ }
+ }
+}
+
I'm quite sure that, without UMS, this function doesn't make sense
anymore, you could leave this fun for the X server (we can use the
load_cursor_argb hook even on the cards we don't advertise ARGB
support). As a bonus that would probably solve Craig's rotated cursor
issue.
[...]
diff --git a/src/nv_setup.c b/src/nv_setup.c
deleted file mode 100644
index f0478ca..000
--- a/src/nv_setup.c
+++ /dev/null
[...]
- pNv-alphaCursor = (pNv-NVArch = 0x11);
-
- pNv-twoHeads = (pNv-Architecture = NV_ARCH_10)
- (implementation != CHIPSET_NV10)
- (implementation != CHIPSET_NV15)
- (implementation != CHIPSET_NFORCE)
- (implementation != CHIPSET_NV20);
-
- pNv-gf4_disp_arch = pNv-twoHeads implementation != CHIPSET_NV11;
-
- /* nv30 and nv35 have two stage PLLs, but use only one register; they
are dealt with separately */
- pNv-two_reg_pll = (implementation == CHIPSET_NV31) ||
-(implementation == CHIPSET_NV36) ||
-(pNv-Architecture = NV_ARCH_40);
-
- pNv-WaitVSyncPossible = (pNv-Architecture = NV_ARCH_10)
- (implementation != CHIPSET_NV10);
-
The accel code still has some bogus checks for WaitVSyncPossible, and
bad things will happen if it's left uninitialized. Anyway, it would be
nice to kill all this crap from NVRec.
- pNv-BlendingPossible = ((pNv-Chipset 0x) CHIPSET_NV04);
[...]
pgp6vJDVoIpJp.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Synchronization mostly missing?
Younes Manton youne...@gmail.com writes: On Mon, Dec 28, 2009 at 1:55 AM, Luca Barbieri l...@luca-barbieri.com wrote: Can you reproduce this with your vertex buffers in VRAM instead of GART? (to rule out that it's a fencing issue). Putting the vertex buffers in VRAM makes things almost perfect, but still with rare artifacts. In particular, the yellow arrow in dinoshade sometimes becames a yellow polygon on the floor, which happens almost every frame if I move the window around. It does fix demos/engine, blender and etracer is almost perfect. Using my sync patch fixes demos/engine and demos/dinoshade, but still leaves artifacts in blender when moving the rectangle and artifacts in etracer. Putting the vertex buffers in VRAM _AND_ adding my sync patch makes things perfect on my system. Using sync + a delay loop before drawing makes things better but still problematic. Also note that both adding wbinvd in the kernel at the start of push buffer submission, running with nopat and synchronizing with the current fence in the kernel had no effect on demos/engine artifacts. To stay on the safe side, you should flush both before and after writing your vertex buffers (e.g. both at CPU_PREP and FINI). Preventing loading of intel_agp did not seem to have any effect either (but strangely, it still listed the aperture size, not sure what's up there). Some intel AGP chipsets are known to contain an evil write cache, adding drm_agp_chipset_flush() calls at random places in the kernel is something else you could try. The last test I tried was, all together: 1. My nv40_sync patch 2. 3 wbinvd followed by spinning 1 times in the kernel at the start of pushbuffer validation 3. Adding BEGIN_RING(curie, NV40TCL_VTX_CACHE_INVALIDATE, 1); OUT_RING(0); before and after draw_elements and draw_arrays 4. Removing intel_agp The logo on etracer's splash screen still, on some frames, flickered. Only putting vertex buffers in VRAM fixed that. I'm not really sure what is happening there. It seems that there is the lack of synchronization plus some other problem. Maybe there is indeed an on-GPU cache for AGP/PCI memory which isn't getting flushed. Maybe NV40TCL_VTX_CACHE_INVALIDATE should be used but not in the way I did. I couldn't find it in renouveau traces, who did reverse engineer that? What does that do? Also, what happens when I remove intel_agp? Does it use PCI DMA? BTW, it seems to me that adding the fencing mechanism I described is necessary even if the vertices are read before the FIFO continues, since rendering is not completed and currently I don't see anything preventing TTM from, for instance, evicting the render buffer while it is being rendered to. It's my understanding that once the FIFO get reg is past a certain point all previous commands are guaranteed to be finished, which is what our fencing is based on. I think we would all have corruption issues if this wasn't the case. You can see that the FIFO get ptr stops advancing after long running draw commands are submitted, and the video decoder FIFO works similarly as well when the HW is lagging. Yeah, really, if PFIFO wasn't waiting for PGRAPH to finish its task before putting in the next command, your X server wouldn't stand a single minute alive. A fencing implementation based on notifiers or DMA_FENCEs is likely to exhibit the same corruption. Anyhow, another person with a GF7 had the same problem and putting vertex buffers in VRAM also improved things for him, so it could be a hardware bug/quirk for some/all GF7s. We don't do it in general because it's slower, but as a temporary workaround we can do that for GF7 NV40s I guess. It likely also doesn't happen with immediate mode vertex submission, which will be implemented sooner or later. I can't reproduce it on my GF6 and I don't think anyone else has either. pgpce3OmkZThA.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Synchronization mostly missing?
Hi,
Luca Barbieri l...@luca-barbieri.com writes:
It seems that Noveau is assuming that once the FIFO pointer is past a
command, that command has finished executing, and all the buffers it
used are no longer needed.
However, this seems to be false at least on G71.
In particular, the card may not have even finished reading the input
vertex buffers when the pushbuffer fence triggers.
While Mesa does not reuse the buffer object itself, the current
allocator tends to return memory that has just been freed, resulting
in the buffer actually been reused.
Thus Mesa will overwrite the vertices before the GPU has used them.
This results in all kinds of artifacts, such as vertices going to
infinity, and random polygons appearing.
This can be seen in progs/demos/engine, progs/demos/dinoshade,
Blender, Extreme Tux Racer and probably any non-trivial OpenGL
software.
Can you reproduce this with your vertex buffers in VRAM instead of GART?
(to rule out that it's a fencing issue).
The problem can be significantly reduced by just adding a waiting loop
at the end of draw_arrays and draw_elements, or by synchronizing
drawing by adding and calling the following function instead of
pipe-flush in nv40_vbo.c:
I think the remaining artifacts may be due to missing 2D engine
synchronization, but I'm not sure how that works.
Note that this causes the CPU to wait for rendering, which is not the
correct solution
static void nv40_sync(struct nv40_context *nv40)
{
nouveau_notifier_reset(nv40-screen-sync, 0);
//BEGIN_RING(curie, 0x1d6c, 1);
//OUT_RING(0x5c0);
//static int value = 0x23;
//BEGIN_RING(curie, 0x1d70, 1);
//OUT_RING(value++);
BEGIN_RING(curie, NV40TCL_NOTIFY, 1);
OUT_RING(0);
BEGIN_RING(curie, NV40TCL_NOP, 1);
OUT_RING(0);
FIRE_RING(NULL);
nouveau_notifier_wait_status(nv40-screen-sync, 0, 0, 0);
}
It seems that NV40TCL_NOTIFY (which must be followed by a nop for some
reason) triggers a notification of rendering completion.
Furthermore, the card will probably put the value set with 0x1d70
somewhere, where 0x1d6c has an unknown use
The 1d70/1d6c is frequently used by the nVidia driver, with 0x1d70
being a sequence number, while 0x1d6c is always set to 0x5c0, while
NV40TCL_NOTIFY seems to be inserted on demand.
On my machine, setting 0x1d6c/0x1d70 like the nVidia driver does
causes a GPU lockup. That is probably because the location where the
GPU is supposed to put the value has not been setup correctly.
So it seems that the current model is wrong, and the current fence
should only be used to determine whether the pushbuffer itself can be
reused.
It seems that, after figuring out where the GPU writes the value and
how to use the mechanism properly, this should be used by the kernel
driver as the bo-sync_obj implementation.
This will delay destruction of the buffers, and thus prevent
reallocation of them, and artifacts, without synchronizing rendering.
I'm not sure why this hasn't been noticed before though.
Is everyone getting randomly misrendered OpenGL or is my machine
somehow more prone to reusing buffers?
What do you think? Is the analysis correct?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
pgpRwKfHGCfxK.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/3] nouveau: Update nv04 textured triangle object definitions.
Signed-off-by: Francisco Jerez curroje...@riseup.net --- nouveau/nouveau_class.h | 285 +-- 1 files changed, 153 insertions(+), 132 deletions(-) diff --git a/nouveau/nouveau_class.h b/nouveau/nouveau_class.h index 87e167b..00b8e13 100644 --- a/nouveau/nouveau_class.h +++ b/nouveau/nouveau_class.h @@ -1326,8 +1326,8 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. #define NV04_TEXTURED_TRIANGLE_COLORKEY 0x0300 #define NV04_TEXTURED_TRIANGLE_OFFSET 0x0304 #define NV04_TEXTURED_TRIANGLE_FORMAT 0x0308 -#define NV04_TEXTURED_TRIANGLE_FORMAT_DMA_SHIFT 0 -#define NV04_TEXTURED_TRIANGLE_FORMAT_DMA_MASK 0x0003 +#define NV04_TEXTURED_TRIANGLE_FORMAT_DMA_A (1 0) +#define NV04_TEXTURED_TRIANGLE_FORMAT_DMA_B (1 1) #define NV04_TEXTURED_TRIANGLE_FORMAT_COLOR_KEY_MATCH_SHIFT 2 #define NV04_TEXTURED_TRIANGLE_FORMAT_COLOR_KEY_MATCH_MASK 0x000c #define NV04_TEXTURED_TRIANGLE_FORMAT_ORIGIN_ZOH_SHIFT 4 @@ -1401,14 +1401,12 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. #defineNV04_TEXTURED_TRIANGLE_BLEND_SHADE_MODE_FLAT 0x0040 #defineNV04_TEXTURED_TRIANGLE_BLEND_SHADE_MODE_GOURAUD 0x0080 #defineNV04_TEXTURED_TRIANGLE_BLEND_SHADE_MODE_PHONG 0x00c0 -#define NV04_TEXTURED_TRIANGLE_BLEND_TEXTURE_PERSPECTIVE_ENABLE_SHIFT 8 -#define NV04_TEXTURED_TRIANGLE_BLEND_TEXTURE_PERSPECTIVE_ENABLE_MASK 0x0f00 +#define NV04_TEXTURED_TRIANGLE_BLEND_TEXTURE_PERSPECTIVE_ENABLE (1 8) #define NV04_TEXTURED_TRIANGLE_BLEND_SPECULAR_ENABLE_SHIFT 12 #define NV04_TEXTURED_TRIANGLE_BLEND_SPECULAR_ENABLE_MASK 0xf000 #define NV04_TEXTURED_TRIANGLE_BLEND_FOG_ENABLE_SHIFT 16 #define NV04_TEXTURED_TRIANGLE_BLEND_FOG_ENABLE_MASK 0x000f -#define NV04_TEXTURED_TRIANGLE_BLEND_ALPHA_ENABLE_SHIFT 20 -#define NV04_TEXTURED_TRIANGLE_BLEND_ALPHA_ENABLE_MASK 0x00f0 +#define NV04_TEXTURED_TRIANGLE_BLEND_BLEND_ENABLE (1 20) #define NV04_TEXTURED_TRIANGLE_BLEND_SRC_SHIFT 24 #define NV04_TEXTURED_TRIANGLE_BLEND_SRC_MASK 0x0f00 #define NV04_TEXTURED_TRIANGLE_BLEND_DST_SHIFT 28 @@ -1418,18 +1416,20 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. #define NV04_TEXTURED_TRIANGLE_CONTROL_ALPHA_REF_MASK 0x00ff #define NV04_TEXTURED_TRIANGLE_CONTROL_ALPHA_FUNC_SHIFT 8 #define NV04_TEXTURED_TRIANGLE_CONTROL_ALPHA_FUNC_MASK 0x0f00 -#define NV04_TEXTURED_TRIANGLE_CONTROL_ALPHA_TEST_ENABLE (1 12) +#define NV04_TEXTURED_TRIANGLE_CONTROL_ALPHA_ENABLE (1 12) #define NV04_TEXTURED_TRIANGLE_CONTROL_ORIGIN (1 13) -#define NV04_TEXTURED_TRIANGLE_CONTROL_Z_ENABLE_SHIFT 14 -#define NV04_TEXTURED_TRIANGLE_CONTROL_Z_ENABLE_MASK 0xc000 +#define NV04_TEXTURED_TRIANGLE_CONTROL_Z_ENABLE (1 14) #define NV04_TEXTURED_TRIANGLE_CONTROL_Z_FUNC_SHIFT 16 #define NV04_TEXTURED_TRIANGLE_CONTROL_Z_FUNC_MASK 0x000f #define NV04_TEXTURED_TRIANGLE_CONTROL_CULL_MODE_SHIFT 20 #define NV04_TEXTURED_TRIANGLE_CONTROL_CULL_MODE_MASK 0x0030 +#defineNV04_TEXTURED_TRIANGLE_CONTROL_CULL_MODE_BOTH 0x +#defineNV04_TEXTURED_TRIANGLE_CONTROL_CULL_MODE_NONE 0x0010 +#defineNV04_TEXTURED_TRIANGLE_CONTROL_CULL_MODE_CW 0x0020 +#defineNV04_TEXTURED_TRIANGLE_CONTROL_CULL_MODE_CCW 0x0030 #define NV04_TEXTURED_TRIANGLE_CONTROL_DITHER_ENABLE (1 22) #define
