Re: [Nouveau] [PATCH] nvfx: fix nv3x fallout from state validation changes
Le Tue, 24 Jan 2012 09:54:31 +0100 Lucas Stach a écrit: > From c998f732d42da5e962fe5da294493132c3e8dc5f Mon Sep 17 00:00:00 2001 > From: Lucas Stach > Date: Tue, 24 Jan 2012 09:46:32 +0100 > Subject: [PATCH] nvfx: fix nv3x fallout from state validation changes > > Apparently nv3x needs some curde hacks to work properly. This > is clearly not the right fix, but it's the behaviour of the old > code and fixes regressions seen by users. Hello, Sorry Lucas, but I finally found a test case I have forgotten, that would maybe need reverting your patches. In mesa-demos/src/demos you'll find fbo_firecube test program that have the scene misrenderered (the scene part that is rendered and used as texture on the cube). As far as I remember now, render temp stuff was used to handle fbo combinations supported on nv40 but not on nv30, or something like that. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] [PATCH 4/4] nvfx: random cleanups of the state validation code
Le Tue, 17 Jan 2012 18:22:59 +0100
Patrice Mandin a écrit:
> Le Tue, 10 Jan 2012 12:41:04 +0100
> Lucas Stach a écrit:
>
> > Signed-off-by: Lucas Stach
> > ---
> > src/gallium/drivers/nvfx/nvfx_state_emit.c | 49
> > ---
> > 1 files changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c
> > b/src/gallium/drivers/nvfx/nvfx_state_emit.c
> > index e2cfb76..a959015 100644
> [snip]
@@ -212,14 +211,6 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
nvfx->relocs_needed = NVFX_RELOCATE_ALL;
}
- if(nvfx->dirty & NVFX_NEW_SAMPLER) {
- nvfx->dirty &=~ NVFX_NEW_SAMPLER;
- nvfx_fragtex_validate(nvfx);
-
- // TODO: only set this if really necessary
- flush_tex_cache = TRUE;
- }
-
dirty = nvfx->dirty;
if(nvfx->render_mode == HW)
@@ -252,6 +243,13 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
}
}
+ if(dirty & NVFX_NEW_SAMPLER) {
+ nvfx_fragtex_validate(nvfx);
+
+ // TODO: only set this if really necessary
+ flush_tex_cache = TRUE;
+ }
+
if(dirty & NVFX_NEW_RAST)
sb_emit(chan, nvfx->rasterizer->sb, nvfx->rasterizer->sb_len);
> I noticed another small regression with it, the splashscreen bitmap is
> also not displayed anymore, so I'll investigate a bit further. Maybe no
> need to revert the whole series.
And the above part triggers it, the missing nvfx->dirty &=~ NVFX_NEW_SAMPLER;
in the change causes this regression.
--
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux
"who writes the code, decides"
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4/4] nvfx: random cleanups of the state validation code
Le Tue, 10 Jan 2012 12:41:04 +0100
Lucas Stach a écrit:
> Signed-off-by: Lucas Stach
> ---
> src/gallium/drivers/nvfx/nvfx_state_emit.c | 49 ---
> 1 files changed, 22 insertions(+), 27 deletions(-)
>
> diff --git a/src/gallium/drivers/nvfx/nvfx_state_emit.c
> b/src/gallium/drivers/nvfx/nvfx_state_emit.c
> index e2cfb76..a959015 100644
[snip]
> @@ -302,11 +303,7 @@ nvfx_state_validate_common(struct nvfx_context *nvfx)
> if(dirty & NVFX_NEW_SR)
> nvfx_state_sr_validate(nvfx);
>
> -/* All these dependencies are wrong, but otherwise
> - etracer, neverball, foobillard, glest totally misrender
> - TODO: find the right fix
> -*/
> - if(dirty & (NVFX_NEW_VIEWPORT | NVFX_NEW_RAST | NVFX_NEW_ZSA))
> + if(dirty & NVFX_NEW_VIEWPORT)
> {
> nvfx_state_viewport_validate(nvfx);
> }
[snip]
After a small revert/compile/try, reverting just that part makes
rendering working again in ut2004demo.
I noticed another small regressing with it, the splashscreen bitmap is
also not displayed anymore, so I'll investigate a bit further. Maybe no
need to revert the whole series.
--
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux
"who writes the code, decides"
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/4] nvfx: rework render temps code and fixes
Le Mon, 16 Jan 2012 17:33:46 +0100 Lucas Stach a écrit: > I seems Marek has just accidentally pushed the whole series. So we have > a bit of a difficult situation here. I'm not sure if we should just > revert or if we can leave the patches upstream. > > I'm aware that this patches haven't received much testing by others than > me and that a review of the code is still oustanding, but I like to > stress the point that these patches are rigorously tested by me and are > relatively low risk. > > Patrice your report of this patchset not working did surprise me, so can > you please make sure those patches are really the cause for your issues? > I heard reports that nv3x is not working properly with mesa/master for > some time. I tried to reproduce the problem on my nv49 setup and I don't > see any issues besides the well known vertex corruption, which is most > likely due to some missing reloc somewhere or the like. Ok I'll try by cleaning and rebuilding everything in mesa. But maybe the issue I spotted is not as severe as it seems, if I can still reproduce it. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/4] nvfx: rework render temps code and fixes
Le Tue, 10 Jan 2012 12:41:00 +0100 Lucas Stach a écrit: > This patch series silences some unknown cap warnings and fixes up > coding style (patch 1+4). > > The most important part of this series are the two patches in the > middle. They rework the state_fb code, so that we are able to > render to not 64 byte aligned targets, as this is the only real > use-case for render temporaries this allows us to drop temp code > completely and simplifies a lot of cases. > > This is only tested on nv49, but there should be nothing different > in this area for other nv3x or nv4x gpus. > > I plan on working on top of that in the following days, so please > review and apply as time permits. > > Thanks, > Lucas Hello, I just tried on my NV34 the whole series. Here is what I noticed: - Seems rendering is a bit slower (in ioquake3, in the first map q3dm0, rendering the mirror and the portal causes more audio stuttering) but it it just my feeling. - ut2004demo hangs at start (display just one frame in the nvidia licence plate part), but the system does not crash, and the game can be killed. Do you want me to check which of your patches makes ut2004 hanging? -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau: Allow using nouveau with 'acpi=off'
Check if ACPI is disabled or not, before calling any kernel acpi function.
It avoids recompiling kernel without ACPI for people not wanting to use it, or
for broken ACPI systems.
Signed-off-by: Patrice Mandin
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index a542380..418bd2c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -52,6 +52,9 @@ static int nouveau_dsm(acpi_handle handle, int func, int arg,
uint32_t *result)
union acpi_object *obj;
int err;
+ if (acpi_disabled)
+ return -ENODEV;
+
input.count = 4;
input.pointer = params;
params[0].type = ACPI_TYPE_BUFFER;
@@ -155,6 +158,9 @@ static bool nouveau_dsm_pci_probe(struct pci_dev *pdev)
int ret;
uint32_t result;
+ if (acpi_disabled)
+ return false;
+
dhandle = DEVICE_ACPI_HANDLE(&pdev->dev);
if (!dhandle)
return false;
@@ -181,6 +187,9 @@ static bool nouveau_dsm_detect(void)
int has_dsm = 0;
int vga_count = 0;
+ if (acpi_disabled)
+ return false;
+
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) !=
NULL) {
vga_count++;
@@ -222,6 +231,9 @@ static int nouveau_rom_call(acpi_handle rom_handle, uint8_t
*bios,
struct acpi_object_list rom_arg;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
+ if (acpi_disabled)
+ return -ENODEV;
+
rom_arg.count = 2;
rom_arg.pointer = &rom_arg_elements[0];
@@ -247,6 +259,9 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev)
acpi_status status;
acpi_handle dhandle, rom_handle;
+ if (acpi_disabled)
+ return false;
+
if (!nouveau_dsm_priv.dsm_detected)
return false;
@@ -276,6 +291,9 @@ nouveau_acpi_edid(struct drm_device *dev, struct
drm_connector *connector)
int type, ret;
void *edid;
+ if (acpi_disabled)
+ return -ENODEV;
+
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
--
1.7.4.4
--
Patrice Mandin
WWW: http://pmandin.atari.org/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] PFIFO_CACHE_ERROR
Le Wed, 20 Oct 2010 10:04:26 +0200 Grzesiek Sójka a écrit: > Hi there! > > I'm using GeForce FX5200 and today I installed > Mesa-dri-driver-nouveau-7.9-3.i686. Now when I shut down the Xserver I > get lots of PFIFO_CACHE_ERROR. Is it something serious or a kind of a > versions problem? I'm using very recent nouveau kernel and > xorg-driver-video-nouveau-0.0.16-0.20100921.1.i686. > > This is the dmesg > > [snip] I also encounter a similar issue, for a very long time. This time, I opened this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=31637 Could you check it happens also for you in the same conditions? -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] mesa: nouveau/nvfx primitive restart
Le Sat, 13 Nov 2010 15:26:51 +0100 Patrice Mandin a écrit: > Le Sat, 13 Nov 2010 12:40:38 +0100 > Christoph Bumiller a écrit: > > > On 13.11.2010 11:20, Patrice Mandin wrote: > > > Hello, > > > > > > As nv30/nv40 supports primitive restart in hardware, here is a patch. > > > > > Thank you, note however that this does not make it work yet in the case > > where the driver decides to push vertex data on the FIFO directly, which > > is implemented via the translate module and u_split_prim in nvfx_push.c, > > maybe you could adjust that path too ? > > Of course, I was also wondering if there were any other code paths that > may need to be fixed. After having rewritten a bit the test in renouveau, my patch appears to be wrong. I found a bit of early announcements about nv30 chips that talk about a vertex cache. Luca Barbieri thought 0x1710 could be some kind of vertex cache flush (see http://people.freedesktop.org/~cbrill/dri-log/dri-devel-2010-01-14.log (at 18:50)). 0x1dac that I changed recently, thinking it could be PRIMITIVE_RESTART_ENABLE, could be a VERTEX_CACHE_ENABLE instead. When using a vbo, the blob always resend vertex data when primitive_restart is used, even when using an array of indices (which could contain the primitive_restart index, set with 0x1db0). -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] mesa: nouveau/nvfx primitive restart
Le Sat, 13 Nov 2010 12:40:38 +0100 Christoph Bumiller a écrit: > On 13.11.2010 11:20, Patrice Mandin wrote: > > Hello, > > > > As nv30/nv40 supports primitive restart in hardware, here is a patch. > > > Thank you, note however that this does not make it work yet in the case > where the driver decides to push vertex data on the FIFO directly, which > is implemented via the translate module and u_split_prim in nvfx_push.c, > maybe you could adjust that path too ? Of course, I was also wondering if there were any other code paths that may need to be fixed. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] mesa: nouveau/nvfx primitive restart
Hello,
As nv30/nv40 supports primitive restart in hardware, here is a patch.
I still did not manage to get piglit working to check for correctness,
so I would like to know if it's ok as is.
--
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux
"who writes the code, decides"
>From 39edccdb5ac0d72eff8c6d0441028a5e201a002c Mon Sep 17 00:00:00 2001
From: Patrice Mandin
Date: Sat, 13 Nov 2010 11:07:14 +0100
Subject: [PATCH] nouveau/nvfx: primitive restart support
Signed-off-by: Patrice Mandin
---
src/gallium/drivers/nvfx/nv30-40_3d.xml.h |3 ++-
src/gallium/drivers/nvfx/nvfx_push.c | 18 ++
src/gallium/drivers/nvfx/nvfx_screen.c|2 +-
3 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nv30-40_3d.xml.h b/src/gallium/drivers/nvfx/nv30-40_3d.xml.h
index a705a6b..3ed3e53 100644
--- a/src/gallium/drivers/nvfx/nv30-40_3d.xml.h
+++ b/src/gallium/drivers/nvfx/nv30-40_3d.xml.h
@@ -1942,7 +1942,8 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#define NV30_3D_CLEAR_BUFFERS_COLOR_B0x0040
#define NV30_3D_CLEAR_BUFFERS_COLOR_A0x0080
-#define NV30_3D_DO_VERTICES 0x1dac
+#define NV30_3D_PRIMITIVE_RESTART_ENABLE 0x1dac
+#define NV30_3D_PRIMITIVE_RESTART_INDEX0x1db0
#define NV30_3D_LINE_STIPPLE_ENABLE0x1db4
diff --git a/src/gallium/drivers/nvfx/nvfx_push.c b/src/gallium/drivers/nvfx/nvfx_push.c
index ebf47e6..eeba225 100644
--- a/src/gallium/drivers/nvfx/nvfx_push.c
+++ b/src/gallium/drivers/nvfx/nvfx_push.c
@@ -337,6 +337,12 @@ nvfx_push_vbo(struct pipe_context *pipe, const struct pipe_draw_info *info)
nvfx_emit_vtx_attr(chan, nvfx->vtxelt->per_instance[i].base.idx, v, nvfx->vtxelt->per_instance[i].base.ncomp);
}
+ /* Primitive restart */
+ WAIT_RING(chan, 2);
+ OUT_RING(chan, RING_3D(NV30_3D_PRIMITIVE_RESTART_ENABLE, 2));
+ OUT_RING(chan, info->primitive_restart ? 1 : 0);
+ OUT_RING(chan, info->restart_index);
+
/* per-instance loop */
while (instances_left--) {
int max_verts;
@@ -367,18 +373,6 @@ nvfx_push_vbo(struct pipe_context *pipe, const struct pipe_draw_info *info)
if(max_verts >= 16)
{
-/* XXX: any command a lot of times seems to (mostly) fix corruption that would otherwise happen */
-/* this seems to cause issues on nv3x, and also be unneeded there */
-if(nvfx->is_nv4x)
-{
- int i;
- for(i = 0; i < 32; ++i)
- {
- OUT_RING(chan, RING_3D(0x1dac, 1));
- OUT_RING(chan, 0);
- }
-}
-
OUT_RING(chan, RING_3D(NV30_3D_VERTEX_BEGIN_END, 1));
OUT_RING(chan, hw_mode);
done = util_split_prim_next(&s, max_verts);
diff --git a/src/gallium/drivers/nvfx/nvfx_screen.c b/src/gallium/drivers/nvfx/nvfx_screen.c
index 8bf0907..8981377 100644
--- a/src/gallium/drivers/nvfx/nvfx_screen.c
+++ b/src/gallium/drivers/nvfx/nvfx_screen.c
@@ -78,7 +78,7 @@ nvfx_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param)
case PIPE_CAP_DEPTH_CLAMP:
return 0; // TODO: implement depth clamp
case PIPE_CAP_PRIMITIVE_RESTART:
- return 0; // TODO: implement primitive restart
+ return 1;
case PIPE_CAP_SHADER_STENCIL_EXPORT:
return 0;
default:
--
1.7.2.3
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nvfx
Le Sat, 24 Jul 2010 15:34:06 +0200 Luca Barbieri a écrit: > I got busy with other things and then essentially lost interest; > furthermore, my nv40 is not even working right now. > > As for the code, sure, feel free to make it work and merge it :) > The new temporary code did indeed screw things up, and I think it also > had other stuff mixed in that I didn't factor out. > However, the old temporary code is wrong because the temporary is > per-surface, while it should be attached to the resource, so that > multiple surfaces, and direct use of the resource itself, works > properly. > > nv40 should support having mismatching color/depth as long as both are > linear and not swizzled. > I'm not sure if that is the case on nv30 or if there the restriction > applies to both cases. > > There are also two branches starting with "RFC" in mesa git that add > correct nv30 ARB_texture_rectangle and correct glsl support, which > require minor Gallium changes but for which IIRC I never got answers > back from Gallium maintainers. > > There should also be code in other branches to add control flow for > nv40 fragment programs (and perhaps other features I don't remember > right now). Hello Luca, Happy to get some news from you, and a bit sad you can not continue to work on it. Thanks for this report. At last, we know in which state is the work you left. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nvfx
Le Sat, 24 Jul 2010 01:52:57 +0200 Marek Olšák a écrit: > > Marek, if you are still interested in merging stuff from nvfx-next-6b, > > I would like to propose up to commit > > 9a4c66b0d1963c4d90fccac41e7aa48105835857 included (as I said before, > > the following ones bring back nasty regression regarding fbo stuff, > > hanging the gpu hard). > > > > 9a4c66b0d1963c4d90fccac41e7aa48105835857 doesn't compile, so I went one > commit back. > > It's here for testing: > git://anongit.freedesktop.org/~mareko/mesa nvfx-new > > Please let me know if it works. I found 2 regressions: - xbmc not starting anymore (stuck at start), due to commit ab434f6b7641a64d30725a9ac24929240362d466 (glx: Use _Xglobal_lock for protecting extension display list) according to git bisect. Current master does not have this problem, so some investigation needed (as xbmc triggers some errors on the gpu even there). - Textures not properly setup in some programs (alien arena, ut 2004 demo) i.e. shown non swizzled when they should be swizzled. git bisect did not show anything till the merge between master and nvfx-next, so once again, some investigation needed. I'll be in holidays soon, so I hope to have time to fix these. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nvfx
Le Fri, 18 Jun 2010 18:43:27 +0200 Marek Olšák a écrit: > On Fri, Jun 18, 2010 at 6:05 PM, Patrice Mandin > wrote: > > > Le Thu, 17 Jun 2010 03:35:19 +0200 > > Marek Olšák a écrit: > > > > > On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry < > > chantry.xav...@gmail.com>wrote: > > > > > > > Hi Marek > > > > > > > > Thanks a lot for your rebasing work. > > > > Here is my report : > > > > > > > > - all my games that broke with temporaries patch (they were either > > > > completely black or lot of black screen flash every frame) behave > > > > badly, but in different ways : > > > > * etracer is very slow and often crash in ttm code [1] (I think this > > > > is an old bug that just resurrected, no idea why) > > > > * foobillard is very slow and still flash a bit > > > > * strangely, neverball seems to work, I get similar results than with > > > > old nvfx-next-6b branch with temporaries reverted. no black flash > > > > while playing. > > > > * glest segfault [2] > > > > > > > > I also compared with piglit the old nvfx branch with the new merged one > > : > > > > 114/174 vs 113/174 > > > > That looks quite good with 3 new pass, but 4 new fail : > > > > * fbo-copypix > > > > Returncode was -6 > > > > * glean pbo > > > > > > ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference: > > > > Assertion `pipe_is_referenced(reference)\\\' failed. > > > > * texCombine4: FAIL rgba8, db, z24, s8, win+pmap, id 33 > > > > * fp-long-alu > > > > > > > > > > Hi Xavier, > > > > > > Sorry for the late reply. > > > > > > The assertion in pipe_reference can be fixed quite easily I think. There > > is > > > pipe_*_reference missing somewhere. > > > > > > Concerning fp-long-alu, there are new CAPs for shader limits which should > > be > > > filled out but I don't know what values to put there. If the two get > > fixed, > > > it will hopefully be just 2 new failures along with 3 that pass. > > > > > > > > > > There is just fp-long-alu that is for sure a regression caused by new > > > > master code (some gallium changes). I don't know about the 3 others. > > > > > > > > It might be worth to re-test everything on your new branch with this > > > > patch reverted : > > > > nvfx: rewrite render temporaries code, also affecting 2D and resource > > code > > > > > > > > > > Here is the tree with the commit reverted: > > > > > > git://anongit.freedesktop.org/~mareko/mesa<http://anongit.freedesktop.org/%7Emareko/mesa>nvfx-next-6b-notemps > > > > > > It is compile-tested so if it does not work, there is nothing I can do > > about > > > it. > > > > > > -Marek > > > > I just tested the new tree nvfx-next-6b-notemps, I think we should go > > some commits before, because Luca removed the check in fbo setting > > between difference in bits between colour and depth/stencil buffer, and > > nv30 hw does not support that (they must be equal) and doing that > > simply hang the gpu. > > > > Commit 4787059263755fb92b2bb09ac71658d9b4cc9368 'nvfx: new 2D: add > > support for render temporaries' removed this check and fbo tests > > trigger the bug. Maybe Luca was planning to use temporaries to avoid > > this check, but unfortunately we do not know if he finished it or not. > > I do not want to guess here. I would like to hear something from Luca before > doing anything else with his code. It has been 3 months since latest Luca's sign, and I'm afraid it will be a while before it changes :-(. Marek, if you are still interested in merging stuff from nvfx-next-6b, I would like to propose up to commit 9a4c66b0d1963c4d90fccac41e7aa48105835857 included (as I said before, the following ones bring back nasty regression regarding fbo stuff, hanging the gpu hard). Luca did many fixes in his branch so it's really bad these ones are not merged back to master. Also, I don't feel like touching the nvfx backend in master till these fixes are merged. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nvfx
Le Fri, 18 Jun 2010 18:43:27 +0200 Marek Olšák a écrit: > I do not want to guess here. I would like to hear something from Luca before > doing anything else with his code. OK, so if Luca does not show up soon to tell us more about it, someone (me?) will have to fix/finish his work. I just wanted to point about the issues I know. If you want to merge, I'm OK with it. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nvfx
Le Thu, 17 Jun 2010 03:35:19 +0200 Marek Olšák a écrit: > On Fri, Jun 11, 2010 at 3:37 PM, Xavier Chantry > wrote: > > > Hi Marek > > > > Thanks a lot for your rebasing work. > > Here is my report : > > > > - all my games that broke with temporaries patch (they were either > > completely black or lot of black screen flash every frame) behave > > badly, but in different ways : > > * etracer is very slow and often crash in ttm code [1] (I think this > > is an old bug that just resurrected, no idea why) > > * foobillard is very slow and still flash a bit > > * strangely, neverball seems to work, I get similar results than with > > old nvfx-next-6b branch with temporaries reverted. no black flash > > while playing. > > * glest segfault [2] > > > > I also compared with piglit the old nvfx branch with the new merged one : > > 114/174 vs 113/174 > > That looks quite good with 3 new pass, but 4 new fail : > > * fbo-copypix > > Returncode was -6 > > * glean pbo > > ../../../../src/gallium/auxiliary/util/u_inlines.h:77:pipe_reference: > > Assertion `pipe_is_referenced(reference)\\\' failed. > > * texCombine4: FAIL rgba8, db, z24, s8, win+pmap, id 33 > > * fp-long-alu > > > > Hi Xavier, > > Sorry for the late reply. > > The assertion in pipe_reference can be fixed quite easily I think. There is > pipe_*_reference missing somewhere. > > Concerning fp-long-alu, there are new CAPs for shader limits which should be > filled out but I don't know what values to put there. If the two get fixed, > it will hopefully be just 2 new failures along with 3 that pass. > > > > There is just fp-long-alu that is for sure a regression caused by new > > master code (some gallium changes). I don't know about the 3 others. > > > > It might be worth to re-test everything on your new branch with this > > patch reverted : > > nvfx: rewrite render temporaries code, also affecting 2D and resource code > > > > Here is the tree with the commit reverted: > > git://anongit.freedesktop.org/~mareko/mesa nvfx-next-6b-notemps > > It is compile-tested so if it does not work, there is nothing I can do about > it. > > -Marek I just tested the new tree nvfx-next-6b-notemps, I think we should go some commits before, because Luca removed the check in fbo setting between difference in bits between colour and depth/stencil buffer, and nv30 hw does not support that (they must be equal) and doing that simply hang the gpu. Commit 4787059263755fb92b2bb09ac71658d9b4cc9368 'nvfx: new 2D: add support for render temporaries' removed this check and fbo tests trigger the bug. Maybe Luca was planning to use temporaries to avoid this check, but unfortunately we do not know if he finished it or not. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [BUG ?] Nouveau driver on 330M GT
Le Wed, 16 Jun 2010 06:58:25 +1000 Ben Skeggs a écrit: > I'm on holidays for the next 2 weeks, but I'll get back to looking at it > then. The only suggestion so far is to make sure you're using the very > latest code from nouveau git, just to make sure it's not already > fixed :) Isn't it related to still-unsupported tmds revision 2 tables? This is in Eric log: [ 15.276217] [drm] nouveau :01:00.0: TMDS table revision 2.0 not currently supported -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux "who writes the code, decides" ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Support writing out the pushbuffer in renouveau trace format (v2)
Le Mon, 12 Apr 2010 18:20:52 +0200 Luca Barbieri a écrit: > Changes in v2: > - Unmap buffers we mapped, avoid assertion > - Silence warnings > > This patch causes libdrm, when NOUVEAU_DUMP=1 is set, to write the > pushbuffer to stdout instead of submitting it to the card. > > renouveau-parse can then be used to parse it and obtain a readable > trace. And for more easier parsing, it would be nice to know which graphic objects are mapped to which handles (the 0x8800000N values). -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau: avoid running out of relocs (attempt 5)
Le Sun, 13 Dec 2009 16:07:37 +0100 Maarten Maathuis a écrit: > - Added flush notify functions for NV30 and NV40. > - NV30 and NV40 need testing (check for regressions). Just tested for NV30, no visible regression, just a minor performance penalty. So it's OK for me. Timedemo with ioquake3: mesa git head: 1260 frames 31.5 seconds 40.0 fps 9.0/25.0/50.0/8.0 ms 1260 frames 31.4 seconds 40.1 fps 9.0/24.9/50.0/7.9 ms with your patch, outofreloc.diff: 1260 frames 32.7 seconds 38.5 fps 9.0/26.0/52.0/8.2 ms 1260 frames 32.6 seconds 38.7 fps 9.0/25.8/51.0/8.1 ms -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Add missing include
Le Tue, 10 Nov 2009 23:00:00 +0100 "Peter Hjalmarsson" a écrit: > fixes the following warning: > nv30_fragprog.c:710: warning: implicit declaration of function 'tgsi_dump' > --- > src/gallium/drivers/nv30/nv30_fragprog.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/gallium/drivers/nv30/nv30_fragprog.c > b/src/gallium/drivers/nv30/nv30_fragprog.c > index cc03854..b42a7be 100644 > --- a/src/gallium/drivers/nv30/nv30_fragprog.c > +++ b/src/gallium/drivers/nv30/nv30_fragprog.c > @@ -4,6 +4,7 @@ > #include "pipe/p_inlines.h" > > #include "pipe/p_shader_tokens.h" > +#include "tgsi/tgsi_dump.h" > #include "tgsi/tgsi_parse.h" > #include "tgsi/tgsi_util.h" Applied. Thanks. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] REnouveau crashed my computer
Le Sat, 14 Jul 2007 15:14:28 +0200 "Louise Hoffman" <[EMAIL PROTECTED]> a écrit: > When REnouveau came to "74/75 test_interesting_registers" the CPU used > 100% and I could only use the mouse, but not interact witt anything. It's happening because this test check if certain hardware registers are available or not by reading them. And sometimes, it crashes when they are not available. > What could be wrong? I am using GeForce 6150 and Fedora 7. Quick fix: disable this test in the test list in renouveau main.c, func_store test_funcs[] array by commenting the line. It's the latest item. Long fix: check in tests.c test_interesting_regs() function which register tested make your system crashing. Most likely in nv40_regs[] array or no_g80_regs[] array. -- Patrice Mandin WWW: http://pmandin.atari.org/ Programmeur Linux, Atari Spécialité: Développement, jeux ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
