Re: [Dri-devel] R200 TexCoord3f patch for cubemaps
On Wed, 2004-05-05 at 04:48, Ian Romanick wrote: This patch enables proper handling of 3f texture coordinates for cubemaps. Up till now, cubemaps only worked if texgen was enabled. As far as I know, this works with all tcl_mode settings (0 through 3 were tested), but I have only tested with progs/demos/cubemap. With this patch, stex3d also seems to work. I'm a bit confused about this. When I enable various driver debug messages, *nothing* gets printed during this test. I thought maybe it was falling back to software, but it looks different than SW R200_DEBUG=fall gives no output either. It's also way too fast for software. :) If this patch works for people (in apps other than cubemap), I will commit it. Looks good with foobillard --cuberef on (too bad it's unplayably slow here); the balls initially show cubemap-like reflections, but that might be a foobillard issue. My next step will be to get the x86 SSE codegen working again. After that I'll try to get point size working on R200. Sounds good. :) Anyone have any ideas about the fog coordinate stuff??? Not really I'm afraid, but some things seem odd to me (I'm using the register names from the register reference here, those in the driver differ slightly): The register reference says 'post-TCL only' about the VTX_DISCRETE_FOG_PRESENT bit in the SE_VTX_FMT_0 register. No idea if that's significant for this though. There's a VTX_DISCRETE_FOG_SEL bit in the SE_TCL_OUTPUT_VTX_COMP_SEL register that the code doesn't seem to handle yet? PS: Is it just me, or is the r200 driver broken with no_rast=true? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Memory management of AGP and VRAM
Is there a document describing how memory management is handled for the overall AGP/VRAM space? I've found where texture memory is handled, but who is allocating space for framebuffers on multi-head cards? If we were to redo the memory management code to support mesa-solo (ie no X present) what would need to be changed? Should this code be in the driver or user space? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Problem with latests CVS DRI and Linux kernel 2.6.5
Hi, I am trying to build the latest (5/5/04) CVS DRI sources with the latest 2.6.5 kernel from within the kernel source tree. I have used scripts/create_lk_drm.sh to copy the cvs dri files to my kernels source tree. So far I have the errors: 1. /src/homeSys/devel/kernel-2.6/linux-2.6.5/drivers/char/drm/drm_drv.h:552:24: drm _pciids.h: No such file or directory It seems that the makefile.kernel has not been updated to match the out of kernel tree Makefile. 2. /src/homeSys/devel/kernel-2.6/linux-2.6.5/drivers/char/drm/drm_vm.h:623: too few arguments to function `remap_page_range' The drmP.h file sets DRM_RPR_ARG based on the REMAP_PAGE_RANGE_5_ARGS paramter. The REMAP_PAGE_RANGE_5_ARGS is not defined in my kernel tree, but should be to get the correct form of DRM_RPR_ARG. Terry -- Dr Terry Barnaby BEAM Ltd Phone: +44 1454 324512 Northavon Business Center, Dean Rd Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK Email: [EMAIL PROTECTED] Web: www.beam.ltd.uk BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Tandems are twice the fun ! --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
--- Jon Smirl [EMAIL PROTECTED] wrote: Is there a document describing how memory management is handled for the overall AGP/VRAM space? I've found where texture memory is handled, but who is allocating space for framebuffers on multi-head cards? Right now the framebuffer is managed in the DDX. Alan Hourihane and Ian Romanick both have done some work on new improved memory managers for X and the DRI. If we were to redo the memory management code to support mesa-solo (ie no X present) what would need to be changed? Should this code be in the driver or user space? That's a good question. Alex = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problem with latests CVS DRI and Linux kernel 2.6.5
Some more points on this: 1. The following line can be added to scripts/create_lk_drm.sh before copying the files to the kernel tree tofix the problem with not having drm_pciids.h (cd linux; sh ../scripts/create_linux_pci_lists.sh ../shared/drm_pciids.txt) 2. If the drmP.h file's line #ifndef REMAP_PAGE_RANGE_5_ARGS is changed to #if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0) this hacks around the problem. I don't no where REMAP_PAGE_RANGE_5_ARGS should really be defined. Terry Terry Barnaby wrote: Hi, I am trying to build the latest (5/5/04) CVS DRI sources with the latest 2.6.5 kernel from within the kernel source tree. I have used scripts/create_lk_drm.sh to copy the cvs dri files to my kernels source tree. So far I have the errors: 1. /src/homeSys/devel/kernel-2.6/linux-2.6.5/drivers/char/drm/drm_drv.h:552:24: drm _pciids.h: No such file or directory It seems that the makefile.kernel has not been updated to match the out of kernel tree Makefile. 2. /src/homeSys/devel/kernel-2.6/linux-2.6.5/drivers/char/drm/drm_vm.h:623: too few arguments to function `remap_page_range' The drmP.h file sets DRM_RPR_ARG based on the REMAP_PAGE_RANGE_5_ARGS paramter. The REMAP_PAGE_RANGE_5_ARGS is not defined in my kernel tree, but should be to get the correct form of DRM_RPR_ARG. Terry -- Dr Terry Barnaby BEAM Ltd Phone: +44 1454 324512 Northavon Business Center, Dean Rd Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK Email: [EMAIL PROTECTED] Web: www.beam.ltd.uk BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Tandems are twice the fun ! --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. Memory management of AGP/VRAM space is identified as a problem area but nobody has proposed any solution for it. Any solution needs to take into account FB, DRM, mesa-solo and existing Xfree. There have been a few minor comments both ways for doing it in a driver and a library. --- Alex Deucher [EMAIL PROTECTED] wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: Is there a document describing how memory management is handled for the overall AGP/VRAM space? I've found where texture memory is handled, but who is allocating space for framebuffers on multi-head cards? Right now the framebuffer is managed in the DDX. Alan Hourihane and Ian Romanick both have done some work on new improved memory managers for X and the DRI. If we were to redo the memory management code to support mesa-solo (ie no X present) what would need to be changed? Should this code be in the driver or user space? That's a good question. Alex = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl wrote: I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. Memory management of AGP/VRAM space is identified as a problem area but nobody has proposed any solution for it. Any solution needs to take into account FB, DRM, mesa-solo and existing Xfree. There have been a few minor comments both ways for doing it in a driver and a library. That's not entirely true. I made a proposal last February (search the dri-devel archives for texmem-0-0-2) that used a combination of in-kernel and user-space. Basically, the memory management mechanism is implemented in-kernel, but the policy is implemented in user-space. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Ian Romanick [EMAIL PROTECTED] wrote: That's not entirely true. I made a proposal last February (search the dri-devel archives for texmem-0-0-2) that used a combination of in-kernel and user-space. Basically, the memory management mechanism is implemented in-kernel, but the policy is implemented in user-space. Here's a link to it: http://www.mail-archive.com/[EMAIL PROTECTED]/msg09472.html Do you have any updates to it? We can put a copy up on fd.o and I'll link it into the next round of discussions. Can any of the kernel memory management code be reused instead of building our own? Obviously this is a different pool but maybe we could use existing allocators. Are there any more design documents like this floating around that should be referenced? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
On Wed, 5 May 2004, Jon Smirl wrote: I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. Memory management of AGP/VRAM space is identified as a problem area but nobody has proposed any solution for it. Any solution needs to take into account FB, DRM, mesa-solo and existing Xfree. There have been a few minor comments both ways for doing it in a driver and a library. This affects video capture as well. It would be nice to be able to reserve chunks of video ram from kernel-space. best Vladimir Dergachev --- Alex Deucher [EMAIL PROTECTED] wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: Is there a document describing how memory management is handled for the overall AGP/VRAM space? I've found where texture memory is handled, but who is allocating space for framebuffers on multi-head cards? Right now the framebuffer is managed in the DDX. Alan Hourihane and Ian Romanick both have done some work on new improved memory managers for X and the DRI. If we were to redo the memory management code to support mesa-solo (ie no X present) what would need to be changed? Should this code be in the driver or user space? That's a good question. Alex = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problem with latests CVS DRI and Linux kernel 2.6.5
On Wed, 05 May 2004 17:19:27 +0100 Terry Barnaby [EMAIL PROTECTED] wrote: Some more points on this: 1. The following line can be added to scripts/create_lk_drm.sh before copying the files to the kernel tree tofix the problem with not having drm_pciids.h (cd linux; sh ../scripts/create_linux_pci_lists.sh ../shared/drm_pciids.txt) 2. If the drmP.h file's line #ifndef REMAP_PAGE_RANGE_5_ARGS is changed to #if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0) this hacks around the problem. I don't no where REMAP_PAGE_RANGE_5_ARGS should really be defined. Currently it is defined in drm/linux/Makefile on the compiler command line. There is some magic in there to detect patched 2.4 kernels (and I think recent stock 2.4 kernels) that have 5 remap_page_range arguments too. If you plug the drm code into a specific kernel version you could #define REMAP_PAGE_RANGE_5_ARGS in a suitable header file. Maybe create_lk_drm.sh could be modified to detect the number of remap_page_range arguments add this definition automatically if needed. Terry Felix --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Which DRI driver/card is usable for modern games?
Is there any hope for open source drivers for high performance cards, taking into consideration the binary alternatives available for cards from ATI, Nvidia or Matrox (Parhelia), etc? One thing to keep in mind about this issue is that ATI and NVidia start working on their 3d drivers even before their cards are released yet. We are still asking for documentation for the next to latest generation of ATI cards (R300) (and, AFAIK, NVidia does not provide docs at all). So open source driver will always be late. However the question of how late depends a lot on how easy it is to program using current frameworks (i.e. Mesa, DRI, X11). best Vladimir Dergachev --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 TexCoord3f patch for cubemaps
Michel Dnzer wrote: On Wed, 2004-05-05 at 04:48, Ian Romanick wrote: Anyone have any ideas about the fog coordinate stuff??? Not really I'm afraid, but some things seem odd to me (I'm using the register names from the register reference here, those in the driver differ slightly): The register reference says 'post-TCL only' about the VTX_DISCRETE_FOG_PRESENT bit in the SE_VTX_FMT_0 register. No idea if that's significant for this though. There's a VTX_DISCRETE_FOG_SEL bit in the SE_TCL_OUTPUT_VTX_COMP_SEL register that the code doesn't seem to handle yet? SE_TCL_OUTPUT_VTX_COMP_SEL or SE_TCL_OUTPUT_VTX_FMT_0? There isn't even a bit for fog in SE_TCL_OUTPUT_VTX_COMP_SEL in r200_reg.h. Hmm... PS: Is it just me, or is the r200 driver broken with no_rast=true? The R200 driver is totally hosed any time when there's a software rasterization fallback (i.e., stencil operations in 16-bit depth mode). It seems to be t_vertex related. :( --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl wrote: --- Ian Romanick [EMAIL PROTECTED] wrote: That's not entirely true. I made a proposal last February (search the dri-devel archives for texmem-0-0-2) that used a combination of in-kernel and user-space. Basically, the memory management mechanism is implemented in-kernel, but the policy is implemented in user-space. Here's a link to it: http://www.mail-archive.com/[EMAIL PROTECTED]/msg09472.html Do you have any updates to it? We can put a copy up on fd.o and I'll link it into the next round of discussions. There was one posted after that. It was posted on 3-Mar-2003. For some reason, the attachment isn't on marc. http://marc.theaimsgroup.com/?l=dri-develm=104673516801006w=2 Since that point the design has changed some, but the document has not. I started writing a simulation of the design using pthreads. Some actual implementation experience exposed some problems in the design. Looking that the modification times on the files, I haven't worked on any of it since 27-May-2003. I *did* start looking at it again today. :) Can any of the kernel memory management code be reused instead of building our own? Obviously this is a different pool but maybe we could use existing allocators. That's a good question. I'd probably have to talk to someone that knows better what is available in the kernel. Are there any more design documents like this floating around that should be referenced? --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] texmem-0-0-2 re-design
In looking for documentation about the texmem work I was doing last year, I found this draft e-mail. After reading this and looking back at the code, the memories started coming back. :) I believe the design had even simplified beyond what's written below. Basically, there are just two types of instructions in the log: allocate and free. Steal is just a special case of free (but only for the context whose memory is stolen!), and I think I worked around needing the other opcodes. Begin old message I've spent the last week and a half working on the client-side portion of texmem-0-0-2. I've completed most of it, the last 10% has proven to be more than the usual 90% the work. The problem is centered around the way block IDs and sequence numbers work. There are a huge number of cases where part of a sequence of blocks is paged out (imagine the middle block of a sequence of 3 is paged out, and the data that took its place is pinned) or replaced. Part of the problem is that, by necessity, multiple object (textures, vertex arrays, etc.) can be stored in a single block. That complicates juggling things around when blocks are paged in. Every time I found a solution for one set of cases, I found two more. All the while the code got more and more complicated. Finally, today, I had enough. When an implementation gets too complicated, the design must be flawed. I looked at the design from a high level. Basically, the current design tries to implement a paged MMU in software. Organizing the global store as blocks, paging blocks in and out one at a time, and shuffling the blocks around to fit are necessary design choices for a hardware implementation, but maybe aren't the best choices for a software implementation. After having that epiphany, I began to look elsewhere for a design model. I cruised around the net, mostly randomly, until I came to freshmeat.net. I came across a release announcement for JFS, and randomly thought about how journaling filesystems work. I worked through a few ideas in my head, and I came to a new plan. :) One of the main design points in the existing texture manager and the originally-proposed texmem-0-0-2 design is that the shared memory area is fixed in size. Having a small, fixed SAREA forces a block oriented design. Why does the SAREA have to be fixed size? The idea is to have two shared memory areas. The first area is a log (or is it a journal? I can never remember which is which) where a process inserts instructions for each allocation, free, or memory-steal that it makes. When a process wants to make an memory operation it replays the log then performs that operation. After performing the operation it adds it to the log. The second SAREA is a snap-shot of the state of memory. This is only used in two cases. It is used to initialize state when a new process opens a GL context. The other case is when a process gets too far behind in processing the log. Basically, if a process detects that the oldest entry left in the log is newer than the last entry it processed, it has to re-initialize its state. That's the 10,000 mile (or 16,093.4 km, if you prefer) view. The log would be small, probably two pages. There would be 5 types of instructions. Each instruction would be one or two words. The low order 3 bits would specify the instruction. The remainder would be the data. 1. Op-code 000: Allocate a block of memory. The remainder of the first word is the size of the allocation. The second word is the offset of the allocation. 2. Op-code 001: Free a block of memory. The remainder of the first word is the size of the memory block to free. The second word is the offset of the free. 3. Op-code 010: Steal a block of memory from another process. The remainder of the first word is the size of the memory block to steal. The second word is the offset of the stolen block. 4. Op-code 011: Add a page to the other shared area. The remainder of the first word is the address of the page. 5. Op-code 100: Remove a page from the other shared area. The remainder of the first word is the address of the page. In addition to those two pages, there would be an additional shared page that would contain a 64-bit counter of the log position. The low bits of the counter specify the position of the next entry in the log to fill. Each process can then compare the global counter with its local copy to determine when the log has wrapped around. This additional page also contains the base pointer(s) for the other shared area. There would probably also be a counter that represents the last update of the second SAREA. This would prevent processes from having to block on the mutex to update the global memory state. The second SAREA is a linked list of memory puddles. The core of each memory puddle is an array of 'sizes'. A region in the puddle is free if the size is positive, and the region is allocated if the size is negative. The array is a buffer-gap data
