All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Smiechowicz <deadwood-5tc4TXWwyLM@public.gmane.org>
To: Luca Barbieri <luca-Ukmtq+NC3rhBHFWNQifrYwC/G2K4zDHf@public.gmane.org>
Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: Synchronization mostly missing?
Date: Mon, 28 Dec 2009 08:27:17 +0100	[thread overview]
Message-ID: <4B385DD5.90008@wp.pl> (raw)
In-Reply-To: <ff13bc9a0912271941s5d465634te43213ea9df1d14f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Luca Barbieri pisze:

> 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?

I reported a similar problem about 2 weeks ago. It first became apparent 
with NV40 but I also confirmed it with NV30 - in both cases it was 
visible in morph3d demo. As long as nothing changes in memory 
allocation, everything is fine. If I even move a window(which causes 
some allocations in the system) vertexes become damaged.


Some information from that previous emails:

""

I see this problem on morph3d demo. What it does is: for each frame 
create a call list and then call it 4 times.

ADDR    VRAM OFFSET
A    X
B    Y
C    X

A,B,C is the memory offset of 32kb buffer created for vertex buffer when 
call lists are compiled. X,Y is the VRAM OFFSET (bo.mem.mm_node.start)

First buffer is created (X,A). When it gets full (after around 3 frames) 
second buffer is created (Y,B). Then first one is freed. When second 
buffer is full, third is created (X,C) - here the problem start:
according to my observations, the card seems to read vertexes not from 
address C but from address A as if it somehow remembered the initial 
address binding.

Other observations:
- the data during execution of gl commands actually seems to be put into 
location C - when I switch to software path, I could track down that it 
reads data from location C - rendering is done correctly in software path
- when I comment out freeing of memory manager node (bo.mem.mm_node), so 
that the third buffer is Z,C (paired with not yet used offset of VRAM) 
then hardware rendering behaves correctly - but this will make card "run 
out" of memory as no memory manager nodes will be deallocated
- when I switch the calls of glCallList into actual rendering code and 
disable invocation of glNewList/glEndList the hardware rendering also 
behaves correctly
""

Best regards,
Krzysztof

      parent reply	other threads:[~2009-12-28  7:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-28  3:41 Synchronization mostly missing? Luca Barbieri
     [not found] ` <ff13bc9a0912271941s5d465634te43213ea9df1d14f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-28  4:41   ` Francisco Jerez
     [not found]     ` <87d41zn20v.fsf-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
2009-12-28  6:55       ` Luca Barbieri
     [not found]         ` <ff13bc9a0912272255n13e3ab3wf1c126b0341045e2-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-28  7:15           ` Younes Manton
     [not found]             ` <586c2acd0912272315o4e2858b5gffd76b24ad741ee9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-12-28 11:53               ` Christoph Bumiller
2009-12-28 13:21               ` Luca Barbieri
2009-12-28 13:33               ` Francisco Jerez
2009-12-28 13:53               ` Luca Barbieri
2009-12-28  5:50   ` Luca Barbieri
2009-12-28  7:27   ` Krzysztof Smiechowicz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B385DD5.90008@wp.pl \
    --to=deadwood-5tc4txwwylm@public.gmane.org \
    --cc=luca-Ukmtq+NC3rhBHFWNQifrYwC/G2K4zDHf@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.