[Nouveau] [Bug 27152] [G72M] Screen corruption when using KMS. Dell Latitude D620 / Quadro NVS 110M/GeForce Go 7300
https://bugs.freedesktop.org/show_bug.cgi?id=27152 Christopher James Halse Rogers changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Christopher James Halse Rogers 2010-05-03 21:24:57 PDT --- This has been confirmed fixed for a while with commit 2eb92c80074ecfbc691741720382007417f64523. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27905] DVI monitor is blank - DVI detected as Display Port ?
https://bugs.freedesktop.org/show_bug.cgi?id=27905 --- Comment #11 from Ben Skeggs 2010-05-03 15:47:00 PDT --- According to your log you have 2 external displays plugged in (VGA-1, DisplayPort-1), as well as your laptop's panel (LVDS-1). The card only has 2 CRTCs, so can only bring up 2 displays. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
On Mon, May 3, 2010 at 1:57 PM, José Fonseca wrote: > On Mon, 2010-05-03 at 01:36 -0700, Xavier Chantry wrote: > > I am trying to understand the s3tc init code as nv50 gallium has a > > problem with that. > > > > It looks like some drivers (r300g and llvmpipe) actually inits s3tc in > > two places : > > ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() > > ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() > > > > Here is an extract of the backtrace calls while loading fgfs on llvmpipe > : > > driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init > > driCreateContext -> st_create_context -> _mesa_create_context_for_api > > -> init_attrib_groups -> _mesa_init_texture_s3tc > > > > These two functions seem to do more or less the same job, and > > apparently, the classic mesa init is unused for a gallium driver. > > So I suppose that init is not necessary, but it happens because > > gallium and mesa are tightly tied together, and create context is > > handled similarly, but it shouldn't hurt ? > > Both inits are necessary. The same .so is used for both paths, but given > that gallium and mesa do not depend on each other that's the way to do > it. Gallium and mesa also have seperate format translation functions. > > At least until we start factoring code into a separate library. (I said > I'd do it, but stuff came up and I couldn't do when I thought, and I > don't know when I'll be able to do it...) > > > Additionally r300g and llvmpipe added util_format_s3tc_init to their > > create_screen functions, and util/u_format_s3tc.c apparently contains > > all the functions that a gallium driver uses. > > So I suppose that nvfx and nv50 should do the same ? > > > > If that's correct, the patch below might not be completely wrong. > > > > On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry > > wrote: > > > flightgear now dies with : > > > Mesa warning: external dxt library not available: texstore_rgba_dxt3 > > > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' > failed. > > > > > > I don't really understand what these stubs are about, they were > > > introduced by following commit : > > > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > > > Author: José Fonseca > > > Date: Wed Apr 7 20:47:38 2010 +0100 > > > > > >util: Use stubs for the dynamically loaded S3TC functions. > > > > > >Loosely based on Luca Barbieri's commit > > >52e9b990a192a9329006d5f7dd2ac222effea5a5. > > > > > > Looking at llvm and r300 code and trying to guess, I came up with the > > > following patch that allows flightgear to start again. But I don't > > > really understand that stuff so it could be wrong. > > > nvfx is probably affected as well. > > > > > > > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > > > b/src/gallium/drivers/nouveau/nouveau_screen.c > > > index 233a91a..a91b00b 100644 > > > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > > > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > > > @@ -5,6 +5,7 @@ > > > #include "util/u_memory.h" > > > #include "util/u_inlines.h" > > > #include "util/u_format.h" > > > +#include "util/u_format_s3tc.h" > > > > > > #include > > > #include > > > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, > > > struct nouveau_device *dev) > > >pscreen->fence_signalled = nouveau_screen_fence_signalled; > > >pscreen->fence_finish = nouveau_screen_fence_finish; > > > > > > + util_format_s3tc_init(); > > > + > > >return 0; > > > } > > > > > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > > > b/src/gallium/drivers/nv50/nv50_screen.c > > > index 2dd1042..0d74c90 100644 > > > --- a/src/gallium/drivers/nv50/nv50_screen.c > > > +++ b/src/gallium/drivers/nv50/nv50_screen.c > > > @@ -20,6 +20,7 @@ > > > * SOFTWARE. > > > */ > > > > > > +#include "util/u_format_s3tc.h" > > > #include "pipe/p_screen.h" > > > > > > #include "nv50_context.h" > > > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > > >case PIPE_FORMAT_A8_UNORM: > > >case PIPE_FORMAT_I8_UNORM: > > >case PIPE_FORMAT_L8A8_UNORM: > > > - case PIPE_FORMAT_DXT1_RGB: > > > - case PIPE_FORMAT_DXT1_RGBA: > > > - case PIPE_FORMAT_DXT3_RGBA: > > > - case PIPE_FORMAT_DXT5_RGBA: > > >case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > > >case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > > >case PIPE_FORMAT_Z32_FLOAT: > > > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > > >case PIPE_FORMAT_R16G16_SNORM: > > >case PIPE_FORMAT_R16G16_UNORM: > > >return TRUE; > > > + case PIPE_FORMAT_DXT1_RGB: > > > + case PIPE_FORMAT_DXT1_RGBA: > > > + case PIPE_FORMAT_DXT3_RGBA: > > > + case PIPE_FORMAT_DXT5_RGB
[Nouveau] [Bug 27603] [nouveau] Celestia 1.6.0 crashes with nv04_surface_copy_swizzle assertion
https://bugs.freedesktop.org/show_bug.cgi?id=27603 --- Comment #16 from Alex Buell 2010-05-03 05:01:47 PDT --- Ah now, thank you for the explanation on the mesa.git tree, sorry, seems my confusion arose on the mailing list with references to a 'stable' mesa.git tree and its development branches. All is now clear. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27603] [nouveau] Celestia 1.6.0 crashes with nv04_surface_copy_swizzle assertion
https://bugs.freedesktop.org/show_bug.cgi?id=27603 --- Comment #15 from Xavier 2010-05-03 04:49:22 PDT --- It's not a fix... It's a complete rewrite of the 2d engine. It will probably be merged some day by its own author, not by "someone". There is no such thing as a stable mesa.git tree. The mesa.git tree contains experimental branches (like nvfx-next), main development branch (master), and stable release branch (7.8). This kind of work is only ever merged in master. But why do you care and what difference does it make to you where the code lies ? And did you forget that 3d is unsupported and bugs are not wanted ? http://nouveau.freedesktop.org/wiki/ - Bugs in the 3-D driver are under product “Mesa”, component “Drivers/DRI/nouveau”, but please do not submit bugs on the 3-D support yet. - Any 3-D functionality that might exist is still unsupported. Do not ask for instructions to try it. But you can read GalliumHowto in case you are brave enough. http://nouveau.freedesktop.org/wiki/GalliumHowto - Warning: the Nouveau 3D drivers are not yet suitable for ordinary users. Bug reports on the 3D drivers are not accepted. You should be thankful that someone already wrote code that fix your problem and that code is very easily available in official mesa.git tree, and that someone else took the time to answer you and point to that code :) PS : I am not a developer and have no influence on what gets merged in mesa, neither on the 3d support / bug policy. And this bug looks more like unofficial user support than anything. Feel free to send me private mails if you have further questions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27603] [nouveau] Celestia 1.6.0 crashes with nv04_surface_copy_swizzle assertion
https://bugs.freedesktop.org/show_bug.cgi?id=27603 --- Comment #14 from Alex Buell 2010-05-03 03:16:40 PDT --- Could someone please merge the fix for this into the stable mesa.git tree? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
I am trying to understand the s3tc init code as nv50 gallium has a problem with that. It looks like some drivers (r300g and llvmpipe) actually inits s3tc in two places : ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() Here is an extract of the backtrace calls while loading fgfs on llvmpipe : driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init driCreateContext -> st_create_context -> _mesa_create_context_for_api -> init_attrib_groups -> _mesa_init_texture_s3tc These two functions seem to do more or less the same job, and apparently, the classic mesa init is unused for a gallium driver. So I suppose that init is not necessary, but it happens because gallium and mesa are tightly tied together, and create context is handled similarly, but it shouldn't hurt ? Additionally r300g and llvmpipe added util_format_s3tc_init to their create_screen functions, and util/u_format_s3tc.c apparently contains all the functions that a gallium driver uses. So I suppose that nvfx and nv50 should do the same ? If that's correct, the patch below might not be completely wrong. On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry wrote: > flightgear now dies with : > Mesa warning: external dxt library not available: texstore_rgba_dxt3 > util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' > failed. > > I don't really understand what these stubs are about, they were > introduced by following commit : > commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 > Author: José Fonseca > Date: Wed Apr 7 20:47:38 2010 +0100 > > util: Use stubs for the dynamically loaded S3TC functions. > > Loosely based on Luca Barbieri's commit > 52e9b990a192a9329006d5f7dd2ac222effea5a5. > > Looking at llvm and r300 code and trying to guess, I came up with the > following patch that allows flightgear to start again. But I don't > really understand that stuff so it could be wrong. > nvfx is probably affected as well. > > > diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c > b/src/gallium/drivers/nouveau/nouveau_screen.c > index 233a91a..a91b00b 100644 > --- a/src/gallium/drivers/nouveau/nouveau_screen.c > +++ b/src/gallium/drivers/nouveau/nouveau_screen.c > @@ -5,6 +5,7 @@ > #include "util/u_memory.h" > #include "util/u_inlines.h" > #include "util/u_format.h" > +#include "util/u_format_s3tc.h" > > #include > #include > @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, > struct nouveau_device *dev) > pscreen->fence_signalled = nouveau_screen_fence_signalled; > pscreen->fence_finish = nouveau_screen_fence_finish; > > + util_format_s3tc_init(); > + > return 0; > } > > diff --git a/src/gallium/drivers/nv50/nv50_screen.c > b/src/gallium/drivers/nv50/nv50_screen.c > index 2dd1042..0d74c90 100644 > --- a/src/gallium/drivers/nv50/nv50_screen.c > +++ b/src/gallium/drivers/nv50/nv50_screen.c > @@ -20,6 +20,7 @@ > * SOFTWARE. > */ > > +#include "util/u_format_s3tc.h" > #include "pipe/p_screen.h" > > #include "nv50_context.h" > @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > case PIPE_FORMAT_A8_UNORM: > case PIPE_FORMAT_I8_UNORM: > case PIPE_FORMAT_L8A8_UNORM: > - case PIPE_FORMAT_DXT1_RGB: > - case PIPE_FORMAT_DXT1_RGBA: > - case PIPE_FORMAT_DXT3_RGBA: > - case PIPE_FORMAT_DXT5_RGBA: > case PIPE_FORMAT_S8_USCALED_Z24_UNORM: > case PIPE_FORMAT_Z24_UNORM_S8_USCALED: > case PIPE_FORMAT_Z32_FLOAT: > @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen > *pscreen, > case PIPE_FORMAT_R16G16_SNORM: > case PIPE_FORMAT_R16G16_UNORM: > return TRUE; > + case PIPE_FORMAT_DXT1_RGB: > + case PIPE_FORMAT_DXT1_RGBA: > + case PIPE_FORMAT_DXT3_RGBA: > + case PIPE_FORMAT_DXT5_RGBA: > + return util_format_s3tc_enabled; > default: > break; > } > ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27905] DVI monitor is blank - DVI detected as Display Port ?
https://bugs.freedesktop.org/show_bug.cgi?id=27905 Julien Wajsberg changed: What|Removed |Added Attachment #35337|0 |1 is obsolete|| Attachment #35347|0 |1 is obsolete|| --- Comment #10 from Julien Wajsberg 2010-05-03 01:35:14 PDT --- Created an attachment (id=35384) --> (https://bugs.freedesktop.org/attachment.cgi?id=35384) dmesg log with drm debug=15 option As requested. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
