Oliver, On 4/26/07, Oliver McFadden <[EMAIL PROTECTED]> wrote: > > Currently this is hard-coded, because I haven't done dynamic calculation of > those variables yet. > > You can determine REG_ADDR from "lspci -v"; you want the line that matches > "(32-bit, non-prefetchable) [size=64K]". In the following example, REG_ADDR > would be 0xe5000000. I haven't figured out how to calculate REG_SIZE yet; It's > just copied from IBA. > ... >
Yeah. That one was easy enought to find. I changed that yesterday. (I know it is working because it is getting the proper register values when it reads things.) > > You can determine AGP_ADDR and AGP_SIZE from "dmesg | grep 'AGP aperture'". > > agpgart: AGP aperture is 64M @ 0xe0000000 > This is pcie card, so I don't have that string. What does that address represent? Is it the address of the GART memory mapped into the card? (Ie, the card accesses 0xe0000000, but it might actually be mapped to some number of physical pages...) For my card, I don't think that there is a region in memory (that I can get to from the CPU) that matches that memory region as the card sees it. However, I CAN get access to the GART table, and use that to figure out exactly where all of the ring buffer is mapped into physical memory. For example, the card sees my RING buffer as starting at 0x58000000. 0x58000000 is ALSO the start of the GART mapped addresses. So, the first 4k of the ring buffer is located at the address of the page in the first entry of the GART table. If I need to access 4k-8k, I have to look at the second table entry and map that page, etc. I think that I can extend your tool to do that, but it will definately make things more ugly than the current "map a range of memory". > > Is it the physical address of the ring buffer? In a system where the > > ring buffer lives in GART addressible memory, wouldn't you basically > > need to reimplement the GART in software? (Because there is no single > > address range which represents the entire ring buffer... It is a > > series of pages...) If the ring buffer lives in the framebuffer, > > things are much easier.. > > > > ... > > > > Also, I've tried glxtest, but the indirect buffer has NO match in the > > maps.log file. > > > > Dave, how did you generate this file? (Was it from an indirect buffer?) > > http://www.skynet.ie/~airlied/dri/mypa.parsed > > That appears to be a dump of an indirect buffer, parsed with > pretty_print_command_stream.tcl. Currently that program is able to parse the > indirect buffers better than my tool, as it can print register names in human > readable format, but this is a high priority on my TODO list too. > > If you want to use pretty_print_command_stream.tcl you must feed it the > indirect > buffer in hexadecimal format, one value per line, with no "0x" prefix. > > deadbeef > deadbeef > deadbeef > ... Alright, I actually have glxtest decoding one of the command streams. At some point, it gives me a pointer to an indirect buffer. However, I have NO idea where that indirect pointer refers to. (I have 8 other map files will many k of data...) The README of glxtest says that you should look into the "maps.log" file in order to find where the indirect buffere is mapped. I was wondering how Dave found the indirect buffer to do the decoding. > If you want revenge to dump in this format, you would have to modify > analyze.c:analyze_indirect_buffer. > > Change the following line. > > analyze_packets (0, ib_size, ib_mapped_addr); > > To. > > int i; > for (i = 0; i < ib_size; i++) > { > printf ("%80lx\n", ib_mapped_addr[i]); > } > > > I downloaded glxtest from sourceforge/r300. Is there a more updated > > version that works? > > It should work, but a lot of the R300 tools are very hard-coded, so sometimes > they require some work. I hope that my tool will become a lot easier to use > and > more dynamic. > > I do have more work to do on it, though. I'd like to hear feedback, too. :) > Any > wanted features, bugs, annoyances, etc. > Ok, will do Oliver. Thanks for the help. --Phil ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
