Re: Kernel / user interface for new memory manager
Michel Dänzer wrote: On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: Alan Cox wrote: The log design presents numerous opportunities for rogue processes to do bad things. At some level, that's inherent in the nature of direct rendering. If you don't trust the processes, don't enable direct rendering. Thats a very poor answer to the problem. DRI needs to be moving towards being more secure, and building in assumptions of insecurity just makes it worse when better cards are used. Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards. I still think 'we may not succeed 100%, at least in the short term' is a bad excuse for not trying, but that seems to be mostly me. Its critical that the kernel knows what memory on the video space is being used for command queue and protects it. From the description of the SiS turboqueue I suspect you may be able to root a sis video box that way but without full docs I can't tell. Protecting a statically assigned command queue is one thing (something similar to what's currently done on radeon would be sufficient), protecting dynamically allocated video memory is another. If the DRM operated on memory objects instead of with offsets directly, it should be trivial: It only has to check that the caller has permission to access the memory objects involved. Other stuff like textures is merely annoyance value. Knowing who owned a block for cleanup matters and the DRI lock/mem handling on some chips already handles it. Its also cheap because you only have to track some kind of texture handles not pages for cleanup. Actually, the long term idea is to have both dri and ddx allocate from the same memory pool. So we can't rely on texture handles for that. May I ask why we can't, assuming this is done via EXA callbacks into the DDX driver that use the shared memory manager? When thinking about the memory manager, there's far more uses for graphics memory than just textures: The framebuffer (including color, Z, stencil, etc) Pbuffers Renderbuffer/Framebuffer objects Pixel/Vertex buffer objects Texture images OpenGL miscellaneous (e.g. vertex/fragment programs) X server miscellaneous (pixmap cache, etc) So, just constructing a memory manager around texture handles seems short-sighted. Furthermore, different memory objects may have different requirements/properties: 1. The location of the object in memory (perhaps the framebuffer has to be at the start of memory). 2. Particular byte/word alignments 3. Can we use VRAM and/or AGP memory for the object? 4. Can the object can be lost asynchronously (Pbuffers)? ... plus others I'm surely forgetting or not aware of. Bearing in mind that I'm probably among the least knowledgeable of the Linux kernel among those here, here are my thoughts on the subject. 1. I'd like an allocator that can be used outside/independent of the Xserver. Specifically, an allocator that EGL and EGL drivers can use. 2. There needs to be a way to share memory blocks between processes. 3. Blocks should get automatically freed when the process that creates them terminates (unless they're shared w/ another process, perhaps). 4. Blocks should probably be named by an opaque handle. That might help to support some kind of simple security model plus allow memory blocks to be relocated, etc. 5. Blocks would have to be locked in some manner while they were actually in use. We don't want to move a texture image while it's being used. 6. There should be a mechanism for the allocator to notify a process when one of its blocks is moved/ejected/changed. 7. The public interface to the allocator should be OS-independent so that it can be implemented on Linux, FreeBSD, etc. Perhaps the public API would be exposed through a library which wraps an OS-specific interface based on ioctls, etc. 8. Try to keep both the interface and implementation as simple as possible with an eye toward future extensions. I think it would be worthwhile to start a specification document for this project (or perhaps a wiki page) where the requirements, issues and proposed interface could be recorded. Any volunteers? -Brian --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote: Michel Dänzer wrote: On Wed, 2005-08-24 at 00:40 +0200, Stephane Marchesin wrote: Alan Cox wrote: Other stuff like textures is merely annoyance value. Knowing who owned a block for cleanup matters and the DRI lock/mem handling on some chips already handles it. Its also cheap because you only have to track some kind of texture handles not pages for cleanup. Actually, the long term idea is to have both dri and ddx allocate from the same memory pool. So we can't rely on texture handles for that. May I ask why we can't, assuming this is done via EXA callbacks into the DDX driver that use the shared memory manager? When thinking about the memory manager, there's far more uses for graphics memory than just textures: The framebuffer (including color, Z, stencil, etc) Pbuffers Renderbuffer/Framebuffer objects Pixel/Vertex buffer objects Texture images OpenGL miscellaneous (e.g. vertex/fragment programs) X server miscellaneous (pixmap cache, etc) So, just constructing a memory manager around texture handles seems short-sighted. Indeed, I think Alan probably meant the opaque handle for memory objects you mention below, at least that's how I read it. Furthermore, different memory objects may have different requirements/properties: 1. The location of the object in memory (perhaps the framebuffer has to be at the start of memory). 2. Particular byte/word alignments 3. Can we use VRAM and/or AGP memory for the object? 4. Can the object can be lost asynchronously (Pbuffers)? ... plus others I'm surely forgetting or not aware of. Yes, I think these and maybe more should be handled via parameters when allocating a memory object. What I'm not sure is whether it's better to specify these specific but HW-dependent attributes or maybe some kind of abstract attributes (can be rendered to/from / scanned out / ...) which are then translated into specific constraints by a HW specific part of the memory manager. I'm leaning towards the latter. Bearing in mind that I'm probably among the least knowledgeable of the Linux kernel among those here, here are my thoughts on the subject. [...] I agree with all your requirements. I think it would be worthwhile to start a specification document for this project (or perhaps a wiki page) where the requirements, issues and proposed interface could be recorded. Indeed, thanks for such a nice summary! -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: 1. I'd like an allocator that can be used outside/independent of the Xserver. Specifically, an allocator that EGL and EGL drivers can use. 2. There needs to be a way to share memory blocks between processes. So that an off-screen window could be shared by the X-server and the client-side driver? The current designs don't really account for that. I suspect that this would just require a way to associate multiple process IDs with a region ID (see below). The does change the way we'd have to manage region IDs. Hmm... 3. Blocks should get automatically freed when the process that creates them terminates (unless they're shared w/ another process, perhaps). 4. Blocks should probably be named by an opaque handle. That might help to support some kind of simple security model plus allow memory blocks to be relocated, etc. 5. Blocks would have to be locked in some manner while they were actually in use. We don't want to move a texture image while it's being used. 6. There should be a mechanism for the allocator to notify a process when one of its blocks is moved/ejected/changed. In the prototype code that I posted to the list several months ago, these four things were handled together. Each object has an associated region ID. The region IDs are allocated to a process by the kernel, and they can therefore be reclaimed when the process dies. When a process wants to use a region, it calls a function to conver the region ID to an address. Two functions exist. One converts the region ID to a CPU address, and the other, with the help of a device-specific callback, converts the region ID to a card address. This commits the object to memory. After an object is committed to memory, another function is called to get a list of dirty ranges in the region. These are portions of the region that need to be restored. In the original design the commit routine would automatically have the kernel restore precious regions. Since we've made the change that user-mode provides the kernel with backing store for the region, this is no longer necessary. The user-mode driver restores precious regions just like other regions. I had all this spread into 3 layers. There's a kernel layer, a device-independent user-mode layer, and a device-dependent user-mode layer. Almost everything should be doable in the device-independent user-mode layer. 7. The public interface to the allocator should be OS-independent so that it can be implemented on Linux, FreeBSD, etc. Perhaps the public API would be exposed through a library which wraps an OS-specific interface based on ioctls, etc. 8. Try to keep both the interface and implementation as simple as possible with an eye toward future extensions. I think it would be worthwhile to start a specification document for this project (or perhaps a wiki page) where the requirements, issues and proposed interface could be recorded. Any volunteers? Yeah. We've got discussions going on in enough different places that we really need to gather all the information in one place. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDJaaX1gOwKyEAw8RAtysAJsEIE/lB535melOceIMEI2vWJuIWwCdGsQd 9TmFEh93cMn9WDuT/tNqp3U= =ejuh -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Dänzer wrote: On Wed, 2005-08-24 at 09:18 -0600, Brian Paul wrote: 1. The location of the object in memory (perhaps the framebuffer has to be at the start of memory). 2. Particular byte/word alignments 3. Can we use VRAM and/or AGP memory for the object? 4. Can the object can be lost asynchronously (Pbuffers)? ... plus others I'm surely forgetting or not aware of. Yes, I think these and maybe more should be handled via parameters when allocating a memory object. What I'm not sure is whether it's better to specify these specific but HW-dependent attributes or maybe some kind of abstract attributes (can be rendered to/from / scanned out / ...) which are then translated into specific constraints by a HW specific part of the memory manager. I'm leaning towards the latter. That's what the BUFFLAG_ bits in memory_buffer.h were for. When a memory pool is created, the driver specifies a set of attributes for it. For example, cards like the G400 that can put the depth buffer in AGP memory would have (BUFFLAG_DEPTH_BUFFER | BUFFLAG_STENCIL_BUFFER | BUFFLAG_TEXTURE | BUFFLAG_COMMAND) for the AGP pool. A card like the R200 that can't put the depth buffer in AGP but can pull vertex data from AGP would have (BUFFLAG_TEXTURE | BUFFLAG_VERTEX | BUFFLAG_COMMAND). When an object is associated with a region ID (*not* when it is committed to memory, see my other post) these bits are associated with it. The allocator then searches for a pool that meets all the requirements. Note that per-region requirements are only kept (or needed) within the user-mode driver. Since the kernel doesn't make any decisions about where to put an object, it doesn't care. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD4DBQFDDJh2X1gOwKyEAw8RAj5vAJi8jT6pmLFPlPIRdvNCBqeoKV0yAJ9fvPo+ U7X5nlyIKYoeXL6tECfjfQ== =X1VX -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[2.6 patch] drivers/char/drm/: small cleanups
This patch contains the following small cleanups:
- make two needlessly global functions static
- drm_sysfs.c: every file should #include the header with the prototypes
of the global functions it is offering
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/char/drm/drm_bufs.c|2 +-
drivers/char/drm/drm_context.c |2 +-
drivers/char/drm/drm_sysfs.c |1 +
3 files changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_bufs.c.old 2005-08-24
16:55:50.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_bufs.c 2005-08-24
16:56:06.0 +0200
@@ -1041,7 +1041,7 @@
return 0;
}
-int drm_addbufs_fb(drm_device_t *dev, drm_buf_desc_t *request)
+static int drm_addbufs_fb(drm_device_t *dev, drm_buf_desc_t *request)
{
drm_device_dma_t *dma = dev-dma;
drm_buf_entry_t *entry;
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_context.c.old
2005-08-24 16:56:29.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_context.c2005-08-24
16:56:42.0 +0200
@@ -308,7 +308,7 @@
*
* Attempt to set drm_device::context_flag.
*/
-int drm_context_switch( drm_device_t *dev, int old, int new )
+static int drm_context_switch( drm_device_t *dev, int old, int new )
{
if ( test_and_set_bit( 0, dev-context_flag ) ) {
DRM_ERROR( Reentering -- FIXME\n );
--- linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_sysfs.c.old 2005-08-24
16:57:02.0 +0200
+++ linux-2.6.13-rc6-mm2-full/drivers/char/drm/drm_sysfs.c 2005-08-24
16:57:20.0 +0200
@@ -17,6 +17,7 @@
#include linux/err.h
#include drm_core.h
+#include drmP.h
struct drm_sysfs_class {
struct class_device_attribute attr;
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: 1. I'd like an allocator that can be used outside/independent of the Xserver. Specifically, an allocator that EGL and EGL drivers can use. 2. There needs to be a way to share memory blocks between processes. So that an off-screen window could be shared by the X-server and the client-side driver? Right. The X server may create/allocate an off-screen window that a direct rendering client draws into and a compositing manager also binds as a texture for compositing/display. That makes three parties interested in that buffer. The current designs don't really account for that. I suspect that this would just require a way to associate multiple process IDs with a region ID (see below). The does change the way we'd have to manage region IDs. Hmm... 3. Blocks should get automatically freed when the process that creates them terminates (unless they're shared w/ another process, perhaps). 4. Blocks should probably be named by an opaque handle. That might help to support some kind of simple security model plus allow memory blocks to be relocated, etc. 5. Blocks would have to be locked in some manner while they were actually in use. We don't want to move a texture image while it's being used. 6. There should be a mechanism for the allocator to notify a process when one of its blocks is moved/ejected/changed. In the prototype code that I posted to the list several months ago, these four things were handled together. Each object has an associated region ID. The region IDs are allocated to a process by the kernel, and they can therefore be reclaimed when the process dies. When a process wants to use a region, it calls a function to conver the region ID to an address. Two functions exist. One converts the region ID to a CPU address, and the other, with the help of a device-specific callback, converts the region ID to a card address. This commits the object to memory. After an object is committed to memory, another function is called to get a list of dirty ranges in the region. These are portions of the region that need to be restored. In the original design the commit routine would automatically have the kernel restore precious regions. Since we've made the change that user-mode provides the kernel with backing store for the region, this is no longer necessary. The user-mode driver restores precious regions just like other regions. I guess I don't understand how particular ranges within a region would become dirty. It sounds like there's two-levels of allocation going on. It would seem to make sense to put all the images which constitute a texture object into one region (a mipmapped cube texture might have 60 or more images). But what about multiple texture objects in one region? If allocations are slow/expensive, the GL driver might make allocations in large-ish chunks that it divides up for multiple texture objects by itself. I had all this spread into 3 layers. There's a kernel layer, a device-independent user-mode layer, and a device-dependent user-mode layer. Almost everything should be doable in the device-independent user-mode layer. 7. The public interface to the allocator should be OS-independent so that it can be implemented on Linux, FreeBSD, etc. Perhaps the public API would be exposed through a library which wraps an OS-specific interface based on ioctls, etc. 8. Try to keep both the interface and implementation as simple as possible with an eye toward future extensions. I think it would be worthwhile to start a specification document for this project (or perhaps a wiki page) where the requirements, issues and proposed interface could be recorded. Any volunteers? Yeah. We've got discussions going on in enough different places that we really need to gather all the information in one place. -Brian --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
The framebuffer (including color, Z, stencil, etc) Pbuffers Renderbuffer/Framebuffer objects Pixel/Vertex buffer objects Texture images OpenGL miscellaneous (e.g. vertex/fragment programs) X server miscellaneous (pixmap cache, etc) Most of these are fairly static objects. 1. The location of the object in memory (perhaps the framebuffer has to be at the start of memory). 2. Particular byte/word alignments 3. Can we use VRAM and/or AGP memory for the object? 4. Can the object can be lost asynchronously (Pbuffers)? and textures. 3. Blocks should get automatically freed when the process that creates them terminates (unless they're shared w/ another process, perhaps). We normally refcount objects. You have to do that anyway to deal with horrible cases that crop up where you can't just recover an object on the spot because of DMA and the like. 6. There should be a mechanism for the allocator to notify a process when one of its blocks is moved/ejected/changed. Architecturally hard from the kernel side and almost always going to cause bugs. Better that the lock() request discovers the the object is gone than a notification system. 7. The public interface to the allocator should be OS-independent so that it can be implemented on Linux, FreeBSD, etc. Perhaps the public API would be exposed through a library which wraps an OS-specific interface based on ioctls, etc. The natural way to express it in Linux would be mmap and some kind of device or filesystem perhaps not dissimilar to posix shared memory support. Most of the properties just happen when you have such an interface - refcounting, callbacks on exit, address assignment etc. How about BSD - similar ? --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Ian Romanick wrote: In the prototype code that I posted to the list several months ago, these four things were handled together. Each object has an associated region ID. The region IDs are allocated to a process by the kernel, and they can therefore be reclaimed when the process dies. When a process wants to use a region, it calls a function to conver the region ID to an address. Two functions exist. One converts the region ID to a CPU address, and the other, with the help of a device-specific callback, converts the region ID to a card address. This commits the object to memory. After an object is committed to memory, another function is called to get a list of dirty ranges in the region. These are portions of the region that need to be restored. In the original design the commit routine would automatically have the kernel restore precious regions. Since we've made the change that user-mode provides the kernel with backing store for the region, this is no longer necessary. The user-mode driver restores precious regions just like other regions. I guess I don't understand how particular ranges within a region would become dirty. It sounds like there's two-levels of allocation going on. It would seem to make sense to put all the images which constitute a texture object into one region (a mipmapped cube texture might have 60 or more images). But what about multiple texture objects in one region? If allocations are slow/expensive, the GL driver might make allocations in large-ish chunks that it divides up for multiple texture objects by itself. 1. Video card has 8MB. 2. 1MB of the card memory is allocated for the front buffer and pinned. 3. Process A allocates (and commits) a 7MB region for a big texture. 4. Process B allocates (and commits) a 2MB region for a texture. To do this, it kick out part of process A's allocation. 5. Process A re-commits its 7MB texture. At #5 we'd much rather just upload the damaged 1MB than have to upload the whole 7MB. This is just a simple example, but the same scenario happens with larger on-card memory + AGP memory and larger textures. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDKG+X1gOwKyEAw8RAqEIAJ0YFkTG6oe55UpfEg/T5OzhLfDz7QCfdWkb aWOOo91HZrCtcMEyvysEo7U= =3ptv -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote: Brian Paul wrote: I think it would be worthwhile to start a specification document for this project (or perhaps a wiki page) where the requirements, issues and proposed interface could be recorded. Any volunteers? Yeah. We've got discussions going on in enough different places that we really need to gather all the information in one place. Could we use http://dri.freedesktop.org/wiki/DriMemoryManagerDesign ? I've added some bits on XAA/EXA and kernel swapping-out issues. That document is *horribly* out of date. We'll have to start by gutting it and replacing it with something derived from: http://marc.theaimsgroup.com/?l=mesa3d-devm=01398019810w=2 I should be able to do some of that on Friday, if nobody gets to it first. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDKYKX1gOwKyEAw8RAgWNAJ9+KHNat22lCa58V9BpKYzxqLn3hgCfUD1m p3qZb0gduOpwsiid0GknlCM= =On7H -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
Alan Cox wrote: The framebuffer (including color, Z, stencil, etc) Pbuffers Renderbuffer/Framebuffer objects Pixel/Vertex buffer objects Texture images OpenGL miscellaneous (e.g. vertex/fragment programs) X server miscellaneous (pixmap cache, etc) Most of these are fairly static objects. 1. The location of the object in memory (perhaps the framebuffer has to be at the start of memory). 2. Particular byte/word alignments 3. Can we use VRAM and/or AGP memory for the object? 4. Can the object can be lost asynchronously (Pbuffers)? and textures. This is only true if the driver keeps a copy of the texture in RAM, which isn't necessarily desirable. Even if the driver did that, if operations like glCopyTexSubImage() and friends are done entirely on hardware, you'll still end up with cases where the texture can't just be thrown away. Keith --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: xpress 200m
On 8/24/05, Vitja Makarov [EMAIL PROTECTED] wrote: Hi! xorg from cvs works with my card just perfect, it solves some fglrx bugs(xv doesn't work after s3 resume). drm. I've added following string to drm_pciids.txt: 0x1002 0x5955 CHIP_RS300|CHIP_IS_PCIE|CHIP_IS_MOBILITY ATI Radeon XPRESS 200M 5955 (PCIE) I tried also CHIP_RV350 and some combinations of flags.. X hangs system when started with radeon module. Ctrl-Alt-Fx doesnt help while SysRqs still working. dmesg output on modprobe radeon: [drm] Initialized drm 1.0.0 20040925 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :01:05.0 mtrr: 0xf000,0x800 overlaps existing 0xf000,0x400 [drm] Initialized radeon 1.15.0 20050208 on minor 0: [drm] Used old pci detect: framebuffer loaded Xorg.log is attached. 3D won't work period until PCIE is supported properly by the drm. You'll have to wait until them to test. In the mean time, if fglrx works for your card, you might try loading that and then using the radeon dump tools from the r300 project (http://r300.sf.net) to look at the PCIE regs. Alex vitja. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
Ian Romanick wrote:
1. Video card has 8MB.
2. 1MB of the card memory is allocated for the front buffer and pinned.
3. Process A allocates (and commits) a 7MB region for a big texture.
4. Process B allocates (and commits) a 2MB region for a texture. To do
this, it kick out part of process A's allocation.
5. Process A re-commits its 7MB texture.
At #5 we'd much rather just upload the damaged 1MB than have to upload
the whole 7MB. This is just a simple example, but the same scenario
happens with larger on-card memory + AGP memory and larger textures.
This sounds fairly complicated (both for the implementor and the user).
Is there anyway we could live without that feature and just manage
things at the granularity of whole regions for version 1.0?
It's not too bad for the user. It basically amounts to doing:
base_address = get_card_address( region_id );
while ( (dirty = get_next_dirty( region_id )) != NULL ) {
upload_data( base_address + dirty-offset,
backing_store + dirty-offset,
dirty-size );
destroy_dirty( dirty );
}
In the implementation it can get a little messy, but it's not that bad
there for the most part. That said, a 1.0 (or 0.9) could just always
have a single dirty that corresponds to the entire region. In fact,
that is what happens the first time a region is committed to memory anyway.
Of course, there's nothing to prevent a driver from just always
re-uploading the entire object anytime there's any dirty ranges.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDDK42X1gOwKyEAw8RAixmAJ9ymqVQml3GMpWaaLsZ5GebkiQSbgCffRlm
ddBx7tmoVdnazrnC13A6oBE=
=lObb
-END PGP SIGNATURE-
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
On Mer, 2005-08-24 at 11:18 -0600, Brian Paul wrote: 2. 1MB of the card memory is allocated for the front buffer and pinned. 3. Process A allocates (and commits) a 7MB region for a big texture. 4. Process B allocates (and commits) a 2MB region for a texture. To do this, it kick out part of process A's allocation. 5. Process A re-commits its 7MB texture. At #5 we'd much rather just upload the damaged 1MB than have to upload the whole 7MB. This is just a simple example, but the same scenario happens with larger on-card memory + AGP memory and larger textures. This sounds fairly complicated (both for the implementor and the user). Is there anyway we could live without that feature and just manage things at the granularity of whole regions for version 1.0? If you make the API return a bitmap at some sane granularity (say 256K ?) then you can implement 1.0 the naiive way and have the API just continue to work once the underlying code is smarter. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: Ian Romanick wrote: In the prototype code that I posted to the list several months ago, these four things were handled together. Each object has an associated region ID. The region IDs are allocated to a process by the kernel, and they can therefore be reclaimed when the process dies. When a process wants to use a region, it calls a function to conver the region ID to an address. Two functions exist. One converts the region ID to a CPU address, and the other, with the help of a device-specific callback, converts the region ID to a card address. This commits the object to memory. After an object is committed to memory, another function is called to get a list of dirty ranges in the region. These are portions of the region that need to be restored. In the original design the commit routine would automatically have the kernel restore precious regions. Since we've made the change that user-mode provides the kernel with backing store for the region, this is no longer necessary. The user-mode driver restores precious regions just like other regions. I guess I don't understand how particular ranges within a region would become dirty. It sounds like there's two-levels of allocation going on. It would seem to make sense to put all the images which constitute a texture object into one region (a mipmapped cube texture might have 60 or more images). But what about multiple texture objects in one region? If allocations are slow/expensive, the GL driver might make allocations in large-ish chunks that it divides up for multiple texture objects by itself. 1. Video card has 8MB. 2. 1MB of the card memory is allocated for the front buffer and pinned. 3. Process A allocates (and commits) a 7MB region for a big texture. 4. Process B allocates (and commits) a 2MB region for a texture. To do this, it kick out part of process A's allocation. 5. Process A re-commits its 7MB texture. At #5 we'd much rather just upload the damaged 1MB than have to upload the whole 7MB. This is just a simple example, but the same scenario happens with larger on-card memory + AGP memory and larger textures. This sounds fairly complicated (both for the implementor and the user). Is there anyway we could live without that feature and just manage things at the granularity of whole regions for version 1.0? -Brian --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Info dumps on my Mach64:
[ this is the card that crashes when I try to do anything 3D with it.] ### :02:07.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) ### (II) ATI(1): VESA BIOS detected (II) ATI(1): VESA VBE Version 2.0 (II) ATI(1): VESA VBE Total Mem: 8192 kB (II) ATI(1): VESA VBE OEM: ATI MACH64 (II) ATI(1): VESA VBE OEM Software Rev: 1.0 (II) ATI(1): VESA VBE OEM Vendor: ATI Technologies Inc. (II) ATI(1): VESA VBE OEM Product: MACH64GT (II) ATI(1): VESA VBE OEM Product Rev: 01.00 (II) ATI(1): VESA VBE DDC supported (II) ATI(1): VESA VBE DDC Level 2 (II) ATI(1): VESA VBE DDC transfer in appr. 2 sec. (II) ATI(1): VESA VBE DDC read successfully (II) ATI(1): Manufacturer: VSC Model: 9e19 Serial#: 16843009 (II) ATI(1): Year: 2004 Week: 21 (II) ATI(1): EDID Version: 1.3 ,, (==) ATI(1): Write-combining range (0xf800,0x80) (II) ATI(1): [drm] SAREA 2200+1208: 3408 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: Searching for BusID pci::02:07.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports pci::02:07.0 (II) ATI(1): [drm] DRM interface version 1.2 (II) ATI(1): [drm] created mach64 driver at busid pci::02:07.0 (II) ATI(1): [drm] added 8192 byte SAREA at 0xf8a9d000 (II) ATI(1): [drm] mapped SAREA 0xf8a9d000 to 0xaf3a8000 (II) ATI(1): [drm] framebuffer handle = 0xf800 (II) ATI(1): [drm] added 1 reserved context for kernel (II) ATI(1): [drm] Will request pseudo-DMA (MMIO) mode (==) ATI(1): [pci] Using 2 MB DMA buffer size (II) ATI(1): [drm] register handle = 0xe0102000 (II) ATI(1): [dri] Visual configs initialized (II) ATI(1): [dri] Block 0 base at 0xe0102400 (II) ATI(1): Memory manager initialized to (0,0) (1024,4095) (II) ATI(1): Largest offscreen area available: 1024 x 3327 (II) ATI(1): Will use 1598 kB of offscreen memory for XAA (II) ATI(1): Will use back buffer at offset 0x30f800 (II) ATI(1): Will use depth buffer at offset 0x48f800 (II) ATI(1): Will use 1985 kB for local textures at offset 0x60f800 (II) ATI(1): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 18 256x256 slots 6 512x512 slots (==) ATI(1): Backing store disabled (==) ATI(1): Silken mouse enabled (II) ATI(1): X context handle = 0x0001 (II) ATI(1): [drm] installed DRM signal handler (II) ATI(1): [DRI] installation complete (II) ATI(1): [drm] Added 128 16384 byte DMA buffers (II) ATI(1): [drm] Mapped 128 DMA buffers at 0xaf1a8000 (II) ATI(1): [drm] Installed interrupt handler, using IRQ 19 (II) ATI(1): Direct rendering enabled (==) RandR enabled ## display: :0 screen: 1 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_SGI_video_sync, GLX_SGIS_multisample OpenGL vendor string: Gareth Hughes, Leif Delgass, JosE9 Fonseca OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20030502 x86/MMX+/3DNow!+/SSE OpenGL version string: 1.2 Mesa 6.2.1 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_object, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_IBM_rasterpos_clip,
Re: Info dumps on my Mach64:
On 8/24/05, Alan Grimes [EMAIL PROTECTED] wrote:
[ this is the card that crashes when I try to do anything 3D with it.]
you might try some of the driver options for 3d:
#ifdef XF86DRI_DEVEL
{
ATI_OPTION_IS_PCI,
force_pci_mode,
OPTV_BOOLEAN,
{0, },
FALSE,
},
{
ATI_OPTION_DMA_MODE,
dma_mode,
OPTV_STRING,
{0, },
FALSE,
},
{
ATI_OPTION_AGP_MODE,
agp_mode,
OPTV_INTEGER,
{0, },
FALSE,
},
{
ATI_OPTION_AGP_SIZE,
agp_size,
OPTV_INTEGER,
{0, },
FALSE,
},
{
ATI_OPTION_LOCAL_TEXTURES,
local_textures,
OPTV_BOOLEAN,
{0, },
FALSE,
},
{
ATI_OPTION_BUFFER_SIZE,
buffer_size,
OPTV_INTEGER,
{0, },
FALSE,
},
#endif /* XF86DRI_DEVEL */
###
:02:07.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro
215GP (rev 5c)
###
(II) ATI(1): VESA BIOS detected
(II) ATI(1): VESA VBE Version 2.0
(II) ATI(1): VESA VBE Total Mem: 8192 kB
(II) ATI(1): VESA VBE OEM: ATI MACH64
(II) ATI(1): VESA VBE OEM Software Rev: 1.0
(II) ATI(1): VESA VBE OEM Vendor: ATI Technologies Inc.
(II) ATI(1): VESA VBE OEM Product: MACH64GT
(II) ATI(1): VESA VBE OEM Product Rev: 01.00
(II) ATI(1): VESA VBE DDC supported
(II) ATI(1): VESA VBE DDC Level 2
(II) ATI(1): VESA VBE DDC transfer in appr. 2 sec.
(II) ATI(1): VESA VBE DDC read successfully
(II) ATI(1): Manufacturer: VSC Model: 9e19 Serial#: 16843009
(II) ATI(1): Year: 2004 Week: 21
(II) ATI(1): EDID Version: 1.3
,,
(==) ATI(1): Write-combining range (0xf800,0x80)
(II) ATI(1): [drm] SAREA 2200+1208: 3408
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: Searching for BusID pci::02:07.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: drmOpenMinor returns 6
drmOpenByBusid: drmGetBusid reports pci::02:07.0
(II) ATI(1): [drm] DRM interface version 1.2
(II) ATI(1): [drm] created mach64 driver at busid pci::02:07.0
(II) ATI(1): [drm] added 8192 byte SAREA at 0xf8a9d000
(II) ATI(1): [drm] mapped SAREA 0xf8a9d000 to 0xaf3a8000
(II) ATI(1): [drm] framebuffer handle = 0xf800
(II) ATI(1): [drm] added 1 reserved context for kernel
(II) ATI(1): [drm] Will request pseudo-DMA (MMIO) mode
(==) ATI(1): [pci] Using 2 MB DMA buffer size
(II) ATI(1): [drm] register handle = 0xe0102000
(II) ATI(1): [dri] Visual configs initialized
(II) ATI(1): [dri] Block 0 base at 0xe0102400
(II) ATI(1): Memory manager initialized to (0,0) (1024,4095)
(II) ATI(1): Largest offscreen area available: 1024 x 3327
(II) ATI(1): Will use 1598 kB of offscreen memory for XAA
(II) ATI(1): Will use back buffer at offset 0x30f800
(II) ATI(1): Will use depth buffer at offset 0x48f800
(II) ATI(1): Will use 1985 kB for local textures at offset 0x60f800
(II) ATI(1): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Lines
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
18 256x256 slots
6 512x512 slots
(==) ATI(1): Backing store disabled
(==) ATI(1): Silken mouse enabled
(II) ATI(1): X context handle = 0x0001
(II) ATI(1): [drm] installed DRM signal handler
(II) ATI(1): [DRI] installation complete
(II) ATI(1): [drm] Added 128 16384 byte DMA buffers
(II) ATI(1): [drm] Mapped 128 DMA buffers at 0xaf1a8000
(II) ATI(1): [drm] Installed interrupt handler, using IRQ 19
(II) ATI(1): Direct rendering enabled
(==) RandR enabled
##
display: :0 screen: 1
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGIS_multisample, GLX_SGIX_fbconfig
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating,
Re: ColorTiling issue on r420
On Fri, 15 Jul 2005 12:04:43 +0200
Rune Petersen [EMAIL PROTECTED] wrote:
Just to add that login (KDM) is more or less fine (cursor is corrupted
untill its moved).
Attached diff should fix this temporarily.
Im still unsure why MaxSurfaceWidth ends up affecting piches and stuff...
--
Aapo Tahkola
Index: radeon_driver.c
===
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.69
diff -u -b -B -u -r1.69 radeon_driver.c
--- radeon_driver.c 8 Aug 2005 23:42:36 - 1.69
+++ radeon_driver.c 24 Aug 2005 19:24:02 -
@@ -4746,7 +4746,7 @@
/* false by default on R3/4xx */
info-allowColorTiling = xf86ReturnOptValBool(info-Options,
OPTION_COLOR_TILING, FALSE);
- info-MaxSurfaceWidth = 3968; /* one would have thought 4096...*/
+ info-MaxSurfaceWidth = 4096/*3968*/; /* one would have thought
4096...*/
info-MaxLines = 4096;
} else {
info-allowColorTiling = xf86ReturnOptValBool(info-Options,
Re: ColorTiling issue on r420
On 8/24/05, Aapo Tahkola [EMAIL PROTECTED] wrote: On Fri, 15 Jul 2005 12:04:43 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Just to add that login (KDM) is more or less fine (cursor is corrupted untill its moved). Attached diff should fix this temporarily. Im still unsure why MaxSurfaceWidth ends up affecting piches and stuff... Odd... I never saw any problems like that. However, if you set your virtual desktop greater than 3968, the desktop gets VERY corrupt. I don't see why that would affect pitches either. Alex -- Aapo Tahkola --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ColorTiling issue on r420
Alex Deucher wrote: On 8/24/05, Aapo Tahkola [EMAIL PROTECTED] wrote: On Fri, 15 Jul 2005 12:04:43 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Just to add that login (KDM) is more or less fine (cursor is corrupted untill its moved). Attached diff should fix this temporarily. Im still unsure why MaxSurfaceWidth ends up affecting piches and stuff... Odd... I never saw any problems like that. However, if you set your virtual desktop greater than 3968, the desktop gets VERY corrupt. I don't see why that would affect pitches either. But it does fix my problem... still odd Rune Petersen --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel / user interface for new memory manager
Michel Dänzer wrote: Security is more than just the memory manager. To enforce video memory protection, we'd have to audit the code and add memory protection to existing drm modules. That is quite a lot of work, and requires extensive knowledge of each card. So I don't think it's worth the trouble with current cards. I still think 'we may not succeed 100%, at least in the short term' is a bad excuse for not trying, but that seems to be mostly me. Sure, but I have not seen any other design that Ian's. In particular, his design adresses performance concerns by avoiding going into the drm for each allocation. So, if someone knows how we can have both security and performance, I'm all ears. Stephane --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 texture pipe bug still there
On Thu, 2005-08-18 at 14:19 -0500, Alan Grimes wrote: I installed the latest CVS DRM source a few days ago. (the kernel modules), and it is still broken! =( Maybe if someone could point me in the general vicinity of the culprit, I could take a whack at it myself... [EMAIL PROTECTED] ~/Croquet0.3 $ squeak DRM_RADEON_TEXTURE: return = -11 offset=0xea60e000 image width=1024 height=512 blit width=1024 height=2048 data=0x6e656200 Vertex3f: 2 Vertex3fv: 1 Normal3f: 2 [EMAIL PROTECTED] ~/Croquet0.3 $ I think this should be fixed in CVS, though I couldn't test due to libGL issues. Could you test and see if it works now? -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: R280 texture pipe bug still there
I think this should be fixed in CVS, though I couldn't test due to libGL issues. Could you test and see if it works now? I just tried a build and got this error: [EMAIL PROTECTED] ~/source/Mesa $ make linux-dri-x86 (cd configs rm -f current ln -s linux-dri-x86 current) make default make[1]: Entering directory `/home/atg/source/Mesa' make[2]: Entering directory `/home/atg/source/Mesa/src' Making sources for linux-dri-x86 make[3]: Entering directory `/home/atg/source/Mesa/src/glx/x11' gcc -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common `pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -O -g -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER indirect.c -o indirect.o Package libdrm was not found in the pkg-config search path. Perhaps you should add the directory containing `libdrm.pc' to the PKG_CONFIG_PATH environment variable No package 'libdrm' found In file included from ../../../include/GL/internal/dri_interface.h:42, from glxclient.h:82, from indirect.h:56, from indirect.c:30: /usr/local/include/xf86drm.h:39:17: drm.h: No such file or directory In file included from ../../../include/GL/internal/dri_interface.h:42, from glxclient.h:82, from indirect.h:56, from indirect.c:30: /usr/local/include/xf86drm.h:224: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:234: error: syntax error before '}' token /usr/local/include/xf86drm.h:237: error: syntax error before drm_handle_t /usr/local/include/xf86drm.h:241: error: syntax error before '}' token /usr/local/include/xf86drm.h:494: error: syntax error before drm_magic_t /usr/local/include/xf86drm.h:498: error: syntax error before drm_handle_t /usr/local/include/xf86drm.h:518: error: syntax error before drm_magic_t /usr/local/include/xf86drm.h:520: error: syntax error before drm_handle_t /usr/local/include/xf86drm.h:525: error: syntax error before drm_handle_t /usr/local/include/xf86drm.h:526: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:533: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:534: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:536: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:538: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:539: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:540: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:541: error: syntax error before '*' token /usr/local/include/xf86drm.h:542: error: syntax error before '*' token /usr/local/include/xf86drm.h:543: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:544: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:545: error: syntax error before drm_drawable_t /usr/local/include/xf86drm.h:546: error: syntax error before drm_drawable_t /usr/local/include/xf86drm.h:557: error: syntax error before drm_handle_t /usr/local/include/xf86drm.h:564: error: syntax error before drmDMAReqPtr /usr/local/include/xf86drm.h:567: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:569: error: syntax error before drm_context_t /usr/local/include/xf86drm.h:571: error: syntax error before drm_context_t In file included from glxclient.h:82, from indirect.h:56, from indirect.c:30: ../../../include/GL/internal/dri_interface.h:43:17: drm.h: No such file or directory In file included from glxclient.h:82, from indirect.h:56, from indirect.c:30: ../../../include/GL/internal/dri_interface.h:189: error: syntax error before drm_context_t ../../../include/GL/internal/dri_interface.h:201: error: syntax error before drm_drawable_t ../../../include/GL/internal/dri_interface.h:216: error: syntax error before drm_clip_rect_t In file included from indirect.c:30: indirect.h:67: warning: `fastcall' attribute directive ignored indirect.h:70: warning: `fastcall' attribute directive ignored In file included from indirect.c:32: indirect_size.h:64: warning: `fastcall' attribute directive ignored indirect_size.h:65: warning: `fastcall' attribute directive ignored indirect_size.h:66: warning: `fastcall' attribute directive ignored indirect_size.h:67: warning: `fastcall' attribute directive ignored indirect_size.h:68: warning: `fastcall' attribute directive
Re: R280 texture pipe bug still there
On Wed, 2005-08-24 at 23:58 -0500, Alan Grimes wrote: I think this should be fixed in CVS, though I couldn't test due to libGL issues. Could you test and see if it works now? I just tried a build and got this error: [EMAIL PROTECTED] ~/source/Mesa $ make linux-dri-x86 (cd configs rm -f current ln -s linux-dri-x86 current) make default make[1]: Entering directory `/home/atg/source/Mesa' make[2]: Entering directory `/home/atg/source/Mesa/src' Making sources for linux-dri-x86 make[3]: Entering directory `/home/atg/source/Mesa/src/glx/x11' gcc -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common `pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -O -g -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER indirect.c -o indirect.o Package libdrm was not found in the pkg-config search path. ^^^ Just install libdrm from DRM CVS. It's a requirement now. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: R280 texture pipe bug still there [PATCH]
^^^ Just install libdrm from DRM CVS. It's a requirement now. IN FILE xf86drm.h AND include/GL/internal/dri_interface.h CHANGE #include drm.h #include drm/drm.h -- Friends don't let friends use GCC 3.4.4 GCC 3.3.6 produces code that's twice as fast on x86! Non-sequiter item: Charleston, South Carolina --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 TEST RESULTS;
PPRACER: Works but has nasty texture bug affecting the ground textures.. (Problem disappears when I run it on the other, unaccelerated monitor..) n64 emulator: Par behavior (sucks due to my lack of coding skill...) flightgear: Works, no obvious problems. Celestia: Works, no obvious problems (Well, some glitches that seem to affect all platforms/configs... Squeak/Croquet: Hangs as soon as you try to start a (any) 3D environment. Problem is replicable on both accelerated (on the R280) and unaccelerated desktops (on the Mach64) Squeak/Citris (A flavor of Croquet); It differs from Croquet in it's 3D environment is pre-loaded when you start up the VM... It displays error boxes immediately before it crashes, the internal stack dump indicates that it's doing something involving mipmapping... -- Friends don't let friends use GCC 3.4.4 GCC 3.3.6 produces code that's twice as fast on x86! Non-sequiter item: Charleston, South Carolina --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
