From: Krzysztof Smiechowicz <deadwood-5tc4TXWwyLM@public.gmane.org>
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Question about nv40_draw_array
Date: Thu, 17 Dec 2009 16:22:22 +0100 [thread overview]
Message-ID: <4B2A4CAE.2020302@wp.pl> (raw)
Hi,
My name is Krzysztof and currently I'm working on porting nouveau
(gallium3d driver + libdrm + drm) to AROS Research OS
(http://www.aros.org). I completed a quite successful port of "old" drm
(one from libdrm git - now removed) and currently I'm working on drm
port from the nouveau kernel tree git.
Right now I'm faced with rather peculiar memory allocation/access
problem with call lists and I would like to ask for help in
understanding how a certain thing is implemented.
Let's assume I have a following call trace:
#0 0x985a764d in nv40_draw_arrays (pipe=0x988ba0fc, mode=5, start=0,
count=3)
at
/data/deadwood/AROS/AROS/contrib/gfx/libs/mesa/src/mesa/../gallium/drivers/nv40/nv40_vbo.c:192
#1 0x9865e773 in st_draw_vbo (ctx=0x9a163788, arrays=0x9a19384c,
prims=0x9a1d595c, nr_prims=23, ib=0x0,
index_bounds_valid=1 '\001', min_index=0, max_index=574)
at
/data/deadwood/AROS/AROS/contrib/gfx/libs/mesa/src/mesa/state_tracker/st_draw.c:698
#2 0x9876c5fa in vbo_save_playback_vertex_list (ctx=0x9a163788,
data=0x9a1d5558)
at
/data/deadwood/AROS/AROS/contrib/gfx/libs/mesa/src/mesa/vbo/vbo_save_draw.c:277
#3 0x985ed13a in execute_list (ctx=0x9a163788, list=1)
at
/data/deadwood/AROS/AROS/contrib/gfx/libs/mesa/src/mesa/main/dlist.c:6438
#4 0x985f1871 in _mesa_CallList (list=1) at
/data/deadwood/AROS/AROS/contrib/gfx/libs/mesa/src/mesa/main/dlist.c:7622
#5 0x98657b4b in neutral_CallList (i=1) at
/data/deadwood/AROS/AROS/contrib/gfx/libs/mesa/src/mesa/main/vtxfmt_tmp.h:298
#6 0x9853e65a in glCallList (list=1) at
/data/deadwood/AROS/AROS/contrib/gfx/libs/mesa/src/mesa/glapi/glapitemp.h:95
at this point nv40->vtxbuf[0] contains a vertex buffer that was
previously used to store a compiled call list.
My question is: how data from this buffer is being transfered to gfx
card/used by gfx card.
I went through the software path "nv40_draw_elements_swtnl" and found a
place in draw module where the buffer storage address is obtained and
data from buffer is used direclty by software rendering. I cannot
however find a similar place for hardware path. I would like to learn
where is the code that copies this data to gfx card or, if this is done
by card reading into computer's memory, what code triggers the read, how
does the gfx card know from which address in RAM to copy the data and
what code indicates that the read finished.
The card in question is GF6200 AGP *but* it runs in PCI mode.
Any help is GREATLY appreciated as I'm stuck on my bug for a long time now.
Best regards,
Krzysztof
next reply other threads:[~2009-12-17 15:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-17 15:22 Krzysztof Smiechowicz [this message]
[not found] ` <4B2A4CAE.2020302-5tc4TXWwyLM@public.gmane.org>
2009-12-17 16:51 ` Question about nv40_draw_array Christoph Bumiller
[not found] ` <4B2A6181.2010601-oe7qfRrRQffzPE21tAIdciO7C/xPubJB@public.gmane.org>
2009-12-17 18:11 ` Krzysztof Smiechowicz
[not found] ` <4B2A746B.60603-5tc4TXWwyLM@public.gmane.org>
2009-12-17 21:26 ` Christoph Bumiller
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=4B2A4CAE.2020302@wp.pl \
--to=deadwood-5tc4txwwylm@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.