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
prev 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.