Re: savage-20050205-linux snapshot - problems
Am Donnerstag, den 10.02.2005, 07:21 +0100 schrieb [EMAIL PROTECTED]: On Monday 07 February 2005 15:33, Felix K=FChling wrote: Am Montag, den 07.02.2005, 15:12 +0100 schrieb=20 [EMAIL PROTECTED]: Hardware: Toshiba Libretto L2 Tm5600 with: :00:04.0 VGA compatible controller: S3 Inc. 86C270-294=3D20 Savage/IX-MV (rev 13) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device 0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=3D Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=3D3Dmedium TAbort- =3D TAbort- MAbort- SERR- PERR- Latency: 248 (1000ns min, 63750ns max), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=3D3D128=3D M] Expansion ROM at 000c [disabled] [size=3D3D64K] Capabilities: available only to root Software: Gentoo current with Gentoo supplied X Window System Version 6.8.1.903 (6.8.=3D 2 RC 3) Release Date: 25 January 2005 X Protocol Version 11, Revision 0, Release 6.8.1.903 Build Operating System: Linux 2.4.29-rc3-mhf239 i686 [ELF]=3D20 Current Operating System: Linux mhfl4 2.4.29-rc3-mhf239 #2 Tue Jan 18 17:43=3D :33 CET 2005 i686 Build Date: 05 February 2005 Installed snapshot from savage-20050205-linux.i386.tar.bz2. On starting X: [snip] So, driver in snapshot still reports 1.0. Seems to be quite old (2001). The new Savage DRM 2.0.0 (in fact 2.2.0 by now) is only available for Linux 2.6.=20 Tested with 2.6.11-rc3. DRM functional with glxgears. tuxkart and tuxracer work most the time but sometimes=20 painting occurs outside of games window. Parts of the image=20 appear (sometime mirrored) outside game window or random=20 patterns appear. Cursor and numeric display in game window=20 appear as random patterns. The garbage patters could be that it's getting the texture tiling wrong. I messed with that code recently. Could be that I broke it on Savage/IX. Also please try if the latest snapshot fixes this. Sometimes above games mess up the screen but restart Game a=20 few times fixes it. =46lighgear messes up the entire screen and would never work. Weird. I haven't had this kind of problems in a while. Though I haven't tested on my Savage/IX recently. Looks like it's time to swap cards again. BTW, the games work on i810 HW with 2.6.11-rc3. Since Linux 2.4 is no longer=20 open for new features there is not much point back-porting it to Linux 2.4.=20 See=20 http://dri.freedesktop.org/wiki/S3Savage for more information about the savage driver status. I just added a note about Linux 2.4 to that page. Sorry, have not found any reference to 2.4 being unsupported=20 on that page.=20 Err, I probably pushed Preview instead of Save. :-/ Are there any test programs available to systematically test=20 DRM/GL functionality? For example mesa/progs/demos and Glean (http://glean.sourceforge.net/). For reference you can always run with indirect software rendering. Set LIBGL_ALWAYS_INDIRECT in the environment. Regards Michael -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] texturing performance local/gart on rv250
Am Mittwoch, den 09.02.2005, 22:12 +0100 schrieb Felix Kühling:
Am Mittwoch, den 09.02.2005, 20:58 +0100 schrieb Roland Scheidegger:
[snip]
Performance with gart texturing, even in 4x mode, takes a big hit
(almost 50%).
I was not really able to get consistent performance results when both
texture heaps were active, I guess it's luck of the day which textures
got put in the gart heap and which ones in the local heap. But that
performance indeed got faster with a smaller gart heap is not a good
sign. And even if the maximum obtained in rtcw with 35MB local heap and
29MB gart heap was higher than the score obtained with 35MB local heap
alone, there were clearly areas which ran faster with only the local heap.
It seems to me that the allocator really should try harder to use the
local heap to be useful on r200 cards, moreover it is likely that you'd
get quite a bit better performance when you DO have to put textures into
the gart heap when you revisit that later when more space becomes
available on the local heap and upload the still-used textures from the
gart heap to the local heap (in fact, should be even faster than those
650MB/s, since no in-kernel-copy would be needed, it should be possible
to blit it directly).
The big problem with the current texture allocator is that it can't tell
which areas are really unused. Texture space is only allocated and never
freed. Once the memory is full it starts kicking textures to upload
new ones. This is the only way of freeing memory. Using an LRU
strategy it has a good chance of kicking unused textures first, but
there's no guarantee. It can't tell if a kicked texture will be needed
the next instant. So trying to move textures from GART to local memory
would basically mean that you blindly kick the least recently used
texture(s) from local memory. If those textures are needed again soon
then performance is going to suffer badly.
Therefore I'm proposing a modified allocator that fails when it needs to
start kicking too recently used textures (e.g. textures used in the
current or previous frame). Failure would not be fatal in this case, you
just keep the texture in GART memory and try again later. Actually you
could use the same allocator for normal texture uploads. Just specify
the current texture heap age as the limit.
If you try to move textures back to local memory each time a texture is
used, this would result in some kind of automatic regulation of heap
usage. By kicking only textures that are several frames old in this
process, you'd avoid trashing.
Currently the texture heap age is only incremented on lock contention
(IIRC). In this scheme you'd also increment it on buffer swaps and
remember the texture heap ages of the last two buffer swaps.
I simplified this idea a little further and attached a patch against
texmem.[ch]. It frees stale textures (and also place holders for other
clients' textures) that havn't been used in 1 second when it runs out of
space on a texture heap. This way it will try a bit harder to put
textures into the first heap before using the second heap, without much
risk (I hope) of performance regressions.
I tested this on a ProSavageDDR where rendering speed appears to be the
same with local and GART textures. There was no measurable performance
regression in Quake3 and I noticed no subjective performance regression
in Torcs or Quake1 either.
Now the only thing missing in texmem.c for migrating textures from GART
to local memory would be a flag to driAllocateTexture to stop trying if
kicking stale textures didn't free up enough space (on the first texture
heap).
Anyway, I think the attached patch should already make a difference as
it is. I'd be interested how much it improves your performance numbers
with Quake3 and rtcw on r200 when both texture heaps are enabled.
[snip]
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- ./texmem.h.~1.6.~ 2005-02-02 17:20:40.0 +0100
+++ ./texmem.h 2005-02-10 17:44:40.0 +0100
@@ -101,6 +101,11 @@
* value must be greater than
* or equal to \c firstLevel.
*/
+
+ double clockAge; /** Clock time stamp indicating when
+ * the texture was last used. The unit
+ * is seconds.
+ */
};
--- ./texmem.c.~1.10.~ 2005-02-05 14:16:25.0 +0100
+++ ./texmem.c 2005-02-10 18:39:15.0 +0100
@@ -50,6 +50,7 @@
#include texformat.h
#include assert.h
+#include sys/time.h
@@ -243,6 +244,13 @@
*/
move_to_head( heap-texture_objects, t );
+ {
+ struct timeval tv;
+ if ( gettimeofday( tv, NULL ) == 0 ) {
+ t-clockAge = (double)tv.tv_sec + (double)tv.tv_usec / 1e6;
+ } else
+ t-clockAge = 0.0;
+ }
for (i = start ; i = end ; i++) {
@@ -415,6 +423,15 @@
t-heap = heap;
if (in_use
Re: [patch] texturing performance local/gart on rv250
Am Donnerstag, den 10.02.2005, 15:31 -0500 schrieb Jon Smirl: I haven't looked at the texture heap management code, but one simple idea for heap management would be to cascade the on-board heap to the AGP one. How does the current algorithm work? Does an algorithm like the one below have merit? It should sort the hot textures on-board, and single use textures should fall out of the cache. 1) load all textures initially in the on-board heap. Since if you are loading them you're probably going to use them. Drivers usually upload textures to the hardware just before binding them to a hardware texture unit. So this assumption is always true. 2) Do LRU with the on-board heap. 3) When you run out of space on-board, demote the end of the LRU list to the top of the AGP heap and copy the texture between heaps. This means you copy a texture when you don't know if or when you're going to need it again. So the move of the texture may just be a waste of time. It would be better to just kick the texture and upload it again later when it's really needed. 4) Run LRU on the AGP heap. 5) When it runs out of space lose the item. 6) an added twist would be if the top of the AGP heap gets hit too often knock it out of cache so that it will get reloaded on-board. I'd rather reverse your scheme. Upload a texture to the GART heap first, because that's potentially faster (though not with the current implementation in the radeon drivers). When the texture is needed more frequently, try promoting it to the local texture heap. This scheme would give good results with movie players that need fast texture uploads and typically use each texture exactly once. It would also improve performance with games, simulations, ... that tend to use the same textures many times and benefit from the higher memory bandwidth when accessing local textures. Jon Smirl [EMAIL PROTECTED] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] texturing performance local/gart on rv250
Am Donnerstag, den 10.02.2005, 17:40 -0500 schrieb Jon Smirl: On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling [EMAIL PROTECTED] wrote: This scheme would give good results with movie players that need fast texture uploads and typically use each texture exactly once. It would Movie players aren't even close to being texture bandwidth bound. The That's not my experience. Optimizations in the texture upload path, using the AGP heap and partial texture uploads had a big impact on mplayer -vo gl performance on my ProSavageDDR (factor 2-3 all of them taken together). demote from local to AGP scheme would cause two copies on each frame but there is plenty of bandwidth. But this assumes that the movie player creates a new texture for each frame. A better scheme for a movie player would be to create a single texture and then keep replacing it's contents. You're right, that's what actually happens in mplayer. It uses glTexSubImage2D because it typically changes only a part of a texture with power-of-two dimensions. Or use two textures and double buffer. But once created these textures would not move in the LRU list unless you started something like a game in another window. Yes, they would move in the LRU list. That's why it's called least recently used not least recently created. ;-) So I would have to modify my scheme to reset the usage count/frequency when a texture image is changed, such that a texture that is updated very frequently would not be promoted to local memory. Am Donnerstag, den 10.02.2005, 17:34 -0500 schrieb Jon Smirl: On Thu, 10 Feb 2005 23:13:30 +0100, Felix Kühling [EMAIL PROTECTED] wrote: This means you copy a texture when you don't know if or when you're going to need it again. So the move of the texture may just be a waste of time. It would be better to just kick the texture and upload it again later when it's really needed. I suspect this extra texture copy wouldn't be noticable except when you construct a test program which articifically triggers it. Most games will achieve a steady state with their loaded textures after a frame or two and the copies will stop. Still this copy is unnecessary at the time. Delaying the re-upload to the time when the texture is needed again has only advantages and is not difficult to implement. I'd rather reverse your scheme. Upload a texture to the GART heap first, because that's potentially faster (though not with the current implementation in the radeon drivers). When the texture is needed more frequently, try promoting it to the local texture heap. I thought about this, but there is no automatic way to figure out when to promote from GART to local. Yes there is. In the current scheme, whenever a texture is bound to a hardware tex unit the driver calls driUpdateTexLRU, which moves the texture to the front of the LRU list. In this function you could easily count how often or how frequently a texture has been used. Based on this information and maybe the texture size you could decide which textures to promote and when. You will keep promoting textures until the local heap is full of non-stale textures. Same problem when local overflows, what do you demote to AGP? You still have copies with this scheme too. Textures are sorted in LRU-order on the texture heaps. So you always kick least recently used textures first. It has always worked like this even in the current scheme. For promoting textures I would only kick stale textures from the local heap. Going first to local and then demoting to AGP sorts everything automatically. It may cause a little more churn in the heaps, In my experience texture uploads are quite expensive. So IMO avoiding unnecessary texture uploads or copies should have a high priority. but the advantage is that the algorithm is very simple and doesn't need much tuning. The only tunable parameter is determining when the top of the AGP heap is hot and booting it. You could use something simple like boot after 500 accesses. I don't think my algorithm is much more complicated. It can be implemented by gradual improvements of the current algorithm (freeing stale texture memory is one step) which helps avoiding unexpected performance regressions. At the moment I'm not planning to rewrite it from scratch, especially because I can't test on any hardware where I can actually measure great performance improvements ATM. The only tunable parameter in my algorithm is how often/frequently used a texture must be in order to try to promote it to the local texture heap. Maybe there are a few more degrees of freedom, because you can also consider the texture size for promotion. I think the steady state result would be about the same as with your algorithm, but I expect my scheme to work better when textures are used very infrequently or updated very frequently (movie players). In particular this would make the texture_heaps option unnecessary, which is a good think IMO (good
Re: texturing performance local/gart on rv250
each time a texture is used, this would result in some kind of automatic regulation of heap usage. By kicking only textures that are several frames old in this process, you'd avoid trashing. Currently the texture heap age is only incremented on lock contention (IIRC). In this scheme you'd also increment it on buffer swaps and remember the texture heap ages of the last two buffer swaps. Some numbers just for fun, since those are the numbers everyone wants to see... Some other OS, rtcw: 120 fps Some other OS, q3: 137 fps (this one is a bit cheated. I'm pretty sure non-fullscreen does not use pageflip. Fullscreen score was 174 fps, whereas we only improved from 125 fps to 129 fps...) This ain't that bad. I'd be happy if we'd do that well in say, ut2k4 or doom3... Roland -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon / r200 texture tiling
Am Dienstag, den 08.02.2005, 20:38 +0100 schrieb Roland Scheidegger: Ok, I was FINALLY able to come up with something for texture tiling which seems to work - this was very very annoying, it _almost_ worked literally within minutes, but I needed a lot of time until it finally did really work. I needed to convert back the drivers to use a multi-byte upload scheme again (they did this years ago until it was abandoned for a simpler method), since if the blitter auto-tiles the textures on upload color format and texture pitch need to match the exact texture properties (at least I was unable to make it work otherwise). Also, there are tons of special cases for small textures in the drm, which I don't like but couldn't avoid. I could not make it work for texture rectangles, I think at least on r200 microtiling for that case should work, but it didn't. Well I don't think it's important. It is only tested with normal 16-bit and 32-bit RGB/RGBA textures, in theory all other formats should probably work too I hope. I lack a good test, tests/manytex and redbook/mipmap are a bit too simple (and you can't see if the tiling is actually correct...). 8-bit formats should work too, if I got the math correctly... FWIW, text in foobillard uses an 8bit texture format, at least with the Savage driver, in case someone wants to test it. I don't have my Radeon installed right now to test it myself. Also, there seem to be some minor differences between r100 and r200 chips as far as macro tiling is concerned (didn't have much time to test on r100 though), and for the heck of it I couldn't figure out what that second micro-tile bit is good for on r100. Quake3 got about a 15% boost on a 9000pro, and 11% on a 7200 sdr, if the highest texture setting/trilinear/32bit was used. Well, compressed textures are still faster :-). Cool stuff. I tested HyperZ and color tiling for the first time last weekend on my Radeon 7500. I found the speedup pretty impressive. A shame that this potential had been wasted for such a long time. For the drm, I've also included Andreas Stenglein's cube map patch for the r100 (since this needs a version bump as well). I've only attached the -core version, I actually plan to do a non-core version too, but I've noticed the non-core version does no longer seem to get all fixes the core version does. So am I the only one who still checks things in for that version? In that case I'll immediately stop touching it... Roland -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texturing performance local/gart on r100
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell: btw texdown showed that texture transfers to card memory are faster than to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s in the best case, though the numbers I got fluctuated quite a bit). How are AGP texture uploads being done? The card memory uploads are actually done via agp buffers - ie the data is written by the driver to agp memory, the card then copies that to card memory. If the AGP case is the same, the data probably travels up to the card and then back down again to AGP memory, accounting for the relative slowdown. One benefit of using the card to do the up/downloads is synchronization with the graphics engine - if you were to write the texture data directly you'd have to have some extra mechanisms to ensure that the memory wasn't being used by commands still unprocessed by the GPU. This actually wouldn't be that hard to organize. The Savage driver does this. Currently it waits for engine idle before uploading a texture. I thought there must be some more efficient (age-based) method. I havn't looked into the details yet. Do you have a hint that would get me started in the right direction? Also, note that there is quite a bit of copying going on: - Application calls glTexImage - Mesa allocates system memory and copies image - Driver allocates agp buffers and copies image into them - Card receives blit command and copies image to final destination. Currently Mesa needs to keep the system memory copy because texture images in card or agp memory can be clobbered by other apps at any time - Ian's texture manager will address this. In the via and sis drivers, texture allocations are permanent, so I've been able to try a different strategy: - Application calls glTexImage - Mesa allocates AGP/card memory and copies texture directly to final destination (using memcpy().) This resulted in an approximate 2x speedup in texture downloads against a strategy similar to the first one outlined (but implemented with cpu copies, not a hostdata blit). The Savage driver uploads textures by memcpy (actually a bit more complicated due to texture tiling) to destination memory. I did some optimization of that tiled upload recently. Now oprofile shows that most CPU usage in texdown is not in the tiled upload but in mesa's texstore-functions. I suppose they could use some optimization too. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texturing performance local/gart on r100
Am Montag, den 07.02.2005, 12:14 + schrieb Keith Whitwell: Felix Kühling wrote: Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell: btw texdown showed that texture transfers to card memory are faster than to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s in the best case, though the numbers I got fluctuated quite a bit). How are AGP texture uploads being done? The card memory uploads are actually done via agp buffers - ie the data is written by the driver to agp memory, the card then copies that to card memory. If the AGP case is the same, the data probably travels up to the card and then back down again to AGP memory, accounting for the relative slowdown. One benefit of using the card to do the up/downloads is synchronization with the graphics engine - if you were to write the texture data directly you'd have to have some extra mechanisms to ensure that the memory wasn't being used by commands still unprocessed by the GPU. This actually wouldn't be that hard to organize. The Savage driver does this. Currently it waits for engine idle before uploading a texture. I thought there must be some more efficient (age-based) method. I havn't looked into the details yet. Do you have a hint that would get me started in the right direction? I'm still working on the age stuff, but the general strategy is to not release memory back into the pool until it is guarenteed no longer referenced. This means hanging onto it for a little while until perhaps the end of a frame or until the next time you notice the engine is idle. The Savage driver doesn't have its own texture memory manager (you claimed it had in your other reply). So there is no memory pool managed by the kernel. I'm trying to do this with the current user-space shared memory manager (texmem.[ch]). I think it'll be difficult to do what I want without sacrificing driver-independence or breaking binary compatibility of the sarea structures. I'll have to take a closer look at this. Note that the via doesn't provide any nice IRQ notification for tracking engine progress - you could do a lot better with that sort of mechanism. Yep, though it doesn't use IRQs (yet). Keith -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage-20050205-linux snapshot - problems
name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::00:04.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::00:04.0 (II) SAVAGE(0): [drm] DRM interface version 1.2 (II) SAVAGE(0): [drm] created savage driver at busid pci::00:04.0 (II) SAVAGE(0): [drm] added 8192 byte SAREA at 0xcfa3a000 (II) SAVAGE(0): [drm] mapped SAREA 0xcfa3a000 to 0x40024000 (II) SAVAGE(0): [drm] framebuffer handle =3D 0xe000 (II) SAVAGE(0): [drm] added 1 reserved context for kernel (II) SAVAGE(0): [drm] aperture handle =3D 0xe200 (II) SAVAGE(0): [drm] failure adding 32 65536 byte DMA buffers (-1007)=20 ^ It failed to add DMA buffers (II) SAVAGE(0): [drm] removed 1 reserved context for kernel (II) SAVAGE(0): [drm] unmapping 8192 bytes of SAREA 0xcfa3a000 at 0x40024000 (EE) SAVAGE(0): DRI isn't enabled What's the reason for the failure? DRI never worked for me on this hardware. Anything I can help to fix/test please let me know. Michael --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Is the XvMC supported on Savage?
Am Sonntag, den 06.02.2005, 19:19 +0500 schrieb Dimitry Naldayev: What about XvMC on savage MX chip? as I remember, the driver from S3 had support for XvMC, and what current status of the code? It never worked. AFAIK only Savage4 and later hardware can do it. So your Savage MX won't ever support XvMC. Felix Kühling [EMAIL PROTECTED] writes: [snip] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI lockup on SuperSavage IX/C
Am Samstag, den 05.02.2005, 12:19 -0500 schrieb Owen Taylor: On Sat, 2005-02-05 at 01:31 +0100, Felix Kühling wrote: Aha, you have a SuperSavage. Unfortunately it seems like vertex DMA locks up these cards. Other SuperSavage users reported the same. I don't know why and I can't debug the problem because I don't have a SuperSavage to test (and neither has Alex :( ). If it was a card, it would be in the mail Monday morning... unfortunately, it's the integrated graphics on my laptop. If you have any particular ideas where you would start debugging, I can try investigating more at some point. The only way seems to be to disable vertex DMA. There is a driconf option for that named enable_vdma. It's on by default. Set it to false. That indeed eliminates the problem. I had to work around a hardware bug on Savage IX too. Take a look at drm/shared-core/savage_bci.c (function dispatch_dma_prim) for the details. Maybe you can try if the same helps on your SuperSavage? Doesn't help. You'd have to do the same in dispatch_dma_idx. You may try bigger numbers of NOPs or waiting for engine idle at different points (by emitting an event and then waiting for it, optionally emitting WAIT_2D/3D first). Once you've found any way to make it work you could try reducing the quirks to the minimum needed to keep it working. Anyway, this is a very time-consuming activity, and success is not guaranteed. Maybe the indexed drawing command works differently on SuperSavages, in that case all quirks would be useless. For the time being I'll disable vertex DMA on all SuperSavages until someone finds a way to make it work without lockups. Thanks for your help, Owen -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI lockup on SuperSavage IX/C
Aha, you have a SuperSavage. Unfortunately it seems like vertex DMA locks up these cards. Other SuperSavage users reported the same. I don't know why and I can't debug the problem because I don't have a SuperSavage to test (and neither has Alex :( ). The only way seems to be to disable vertex DMA. There is a driconf option for that named enable_vdma. It's on by default. Set it to false. I had to work around a hardware bug on Savage IX too. Take a look at drm/shared-core/savage_bci.c (function dispatch_dma_prim) for the details. Maybe you can try if the same helps on your SuperSavage? Regards, Felix Am Freitag, den 04.02.2005, 18:16 -0500 schrieb Owen Taylor: I spent some time trying to debug the lockup I'm seeing with the new vertex code and came up pretty empty. The lockup I see is that with even the simplest GL program (say progs/redbook/hello) as soon as rendering starts, the X server first eats 100% CPU and becomes pretty much entirely unresponsive ... the cursor is slowly updated in a corrupted fashion (multiple copies). During this period, the server is spending most (but not all) of the CPU time in ShadowWait(), but I see the same behavior if I turn ShadowStatus off. Then after a maybe 30 seconds the PCI bus locks and the machine becomes unresponsive. I couldn't find an obvious correlation with any particular action being executed by the GL client when I single-stepped through the execution of _mesa_Flush though the fact that it is gradual makes it hard to be certain. Assuming that I didn't screw up the build somehow (not impossible) this should be with CVS head of xorg/xc/programs/Xserver, drm and Mesa. I'm hoping that this sounds like a familiar problem, since I don't have much idea how to debug it further. Regards, Owen -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] Fair usage of all texture heaps
Am Freitag, den 04.02.2005, 01:57 +0530 schrieb Rajsekar Manokaran: seems to improve the perfomance in quake Thanks for the feedback. Could you provide some more info, though? Which quake version? Which hardware and driver? How much local and AGP texture memory are available in your configuration (Xorg.0.log should have information about the memory layout)? Anyway, I'm committing this now. Regards, Felix On Wed, 02 Feb 2005 17:38:21 +0100, Felix Kühling [EMAIL PROTECTED] wrote: I attached an updated patch that applies to latest CVS and includes a fix along the lines of the one I just committed to texmem.c. I havn't heard any feedback in over a week. If no one objects I'll commit this tomorrow. [snip] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] Fair usage of all texture heaps
I attached an updated patch that applies to latest CVS and includes a
fix along the lines of the one I just committed to texmem.c.
I havn't heard any feedback in over a week. If no one objects I'll
commit this tomorrow.
Regards,
Felix
Am Mittwoch, den 26.01.2005, 00:26 +0100 schrieb Felix Kühling:
Hi,
The attached patch is my first cut at implementing a fair strategy for
using all texture heaps. This solves my texture trashing problems with
Torcs on Savage4 and ProSavageDDR. Testing and comments are welcome. I'm
especially interested if anyone sees any performance regressions with
this.
Heaps are now weighted by their sizes. That is, the bigger a heap, the
more data will be kicked from/uploaded to it. If upload performance
differs greatly then it would be quite easy to multiply a heap-specific
factor to that weight in order to introduce a heap preference. This
could be done either directly in the driver just after allocating a
texture heap (heap-weight *= factor) or by adding a new parameter to
driCreateTextureHeap.
Note that the new code in my patch will not be active as long as there
is enough free space on any texture heap. So in order to see any
performance difference you will either have to test with a very
texture-hungry application or artificially reduce the amount of texture
memory on one or both heaps. Also note that you need at least two
texture heaps, so r200 is a bad candidate. ;-)
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: texmem.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/texmem.c,v
retrieving revision 1.8
diff -u -r1.8 texmem.c
--- texmem.c 2 Feb 2005 15:52:29 - 1.8
+++ texmem.c 2 Feb 2005 16:34:56 -
@@ -477,6 +477,8 @@
+#define INDEX_ARRAY_SIZE 6 /* I'm not aware of driver with more than 2 heaps */
+
/**
* Allocate memory from a texture heap to hold a texture object. This
* routine will attempt to allocate memory for the texture from the heaps
@@ -528,39 +530,91 @@
*/
if ( t-memBlock == NULL ) {
- for ( id = 0 ; (t-memBlock == NULL) (id nr_heaps) ; id++ ) {
+ unsigned index[INDEX_ARRAY_SIZE];
+ unsigned nrGoodHeaps = 0;
+
+ /* Trying to avoid dynamic memory allocation. If you have more
+ * heaps, increase INDEX_ARRAY_SIZE. I'm not aware of any
+ * drivers with more than 2 tex heaps. */
+ assert( nr_neaps INDEX_ARRAY_SIZE );
+
+ /* Sort large enough heaps by duty. Insertion sort should be
+ * fast enough for such a short array. */
+ for ( id = 0 ; id nr_heaps ; id++ ) {
heap = heap_array[ id ];
- if ( heap == NULL )
- continue;
+ if ( heap != NULL t-totalSize = heap-size ) {
+ unsigned j;
- if ( t-totalSize = heap-size ) {
+ for ( j = 0 ; j nrGoodHeaps; j++ ) {
+ if ( heap-duty heap_array[ index[ j ] ]-duty )
+ break;
+ }
- for ( cursor = heap-texture_objects.prev, temp = cursor-prev;
- cursor != heap-texture_objects ;
- cursor = temp, temp = cursor-prev ) {
-
- /* The the LRU element. If the texture is bound to one of
- * the texture units, then we cannot kick it out.
- */
- if ( cursor-bound /* || cursor-reserved */ ) {
- continue;
- }
+ if ( j nrGoodHeaps ) {
+ memmove( index[ j+1 ], index[ j ],
+ sizeof(index[ 0 ]) * (nrGoodHeaps - j) );
+ }
- /* If this is a placeholder, there's no need to keep it */
- if (cursor-tObj)
- driSwapOutTextureObject( cursor );
- else
- driDestroyTextureObject( cursor );
+ index[ j ] = id;
- t-memBlock = mmAllocMem( heap-memory_heap, t-totalSize,
- heap-alignmentShift, 0 );
+ nrGoodHeaps++;
+ }
+ }
- if (t-memBlock)
- break;
+ for ( id = 0 ; (t-memBlock == NULL) (id nrGoodHeaps) ; id++ ) {
+ heap = heap_array[ index[ id ] ];
+
+ for ( cursor = heap-texture_objects.prev, temp = cursor-prev;
+ cursor != heap-texture_objects ;
+ cursor = temp, temp = cursor-prev ) {
+
+ /* The the LRU element. If the texture is bound to one of
+ * the texture units, then we cannot kick it out.
+ */
+ if ( cursor-bound /* || cursor-reserved */ ) {
+ continue;
}
- } /* if ( t-totalSize = heap-size ) ... */
+
+ if ( cursor-memBlock )
+ heap-duty -= cursor-memBlock-size;
+
+ /* If this is a placeholder, there's no need to keep it */
+ if (cursor-tObj)
+ driSwapOutTextureObject( cursor );
+ else
+ driDestroyTextureObject( cursor );
+
+ t-memBlock = mmAllocMem( heap-memory_heap, t-totalSize,
+ heap-alignmentShift, 0 );
+
+ if (t-memBlock)
+ break;
+ }
}
+
+ /* Rebalance duties. If a heap kicked more data than its duty,
+ * then all
Re: How to turn on direct rendering on Savage MX?
Am Mittwoch, den 02.02.2005, 22:06 +0500 schrieb Dimitry Naldayev: Felix Kühling [EMAIL PROTECTED] writes: Am Dienstag, den 01.02.2005, 23:13 +0500 schrieb Dimitry Naldayev: May will be better to make rm -rf /usr/X11R6 and build from CVS full Xorg, not only DRI part? But how host.def must look for this? If you really want to do this, I am not sure... Is this a good idea? why? It's a good idea if you want to play with the source code. Otherwise the snapshots are easier to install and are quite up-to-date as well. It's your choice. then an empty host.def would be a good start. You may want to keep some custom compiler optimization options though. And #define NothingOutsideProjectRoot YES is a good idea too. About hardware: I have ASUS L8400C notebook... with Savage MX graphic chip. It should work. It work now!!! thanks. I have gotten 380 fps in glxgears vs. 113 fps without direct rendering. Are there farther way to increase perfomans? are there any options wich I can test? You could experiment with AgpMode and AgpSize in xorg.conf. I set AgpMode to 2 and AgpSize to 32 this increase perfomans in gears about 1.5--2 fps ;-) and look like my notebook do not support AgpMode 4x Also lower resolutions and refresh rates tend to improve performance slightly. But don't expect any miracles. 380 FPS on gears is quite good for a Savage/MX. I get about 350 on a Savage/IX. I attach output of glxinfo. What mean table at the end of the output? what mean slow in the table? It's a table of visuals. Visuals with accum buffers or a stencil buffer are slow, which means they cannot use hardware acceleration. For example the queens and endgame hacks (from xscreensaver) need a stencil buffer, so they will be slow. There are mentions about fastpath and dma on savage somewere in dri wiki... What option available to tweak/test this? Take a look at http://dri.freedesktop.org/wiki/DriConf. This tool allows you to tweak driver options per applicaton. It has nothing to do with the display numbers. But only one display can use the DRM at the same time. There was a patch for the Radeon driver once that solved this problem by reinitializing the DRM on VT switches, but the Savage driver doesn't support this now. Is this patch included in CVS? You mean the radeon patch? No. I'm not sure why. -- Dimitry -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Dying X server / Apps with linux-core.
Am Dienstag, den 01.02.2005, 09:37 + schrieb Dave Airlie: Good point. That's my change in non-core which hasn't been propogated to core. It's just a cleanup I wouldn't have expected either version to be crash-prone. I don't think the irq handler gets much of a workout unless you sync-to-vblank at the moment. it may not be that.. but I wonder is there anything else different.. via_irq was the first file I opened :-), I think linux-core may have bugs but I think we'll never find them until it is out in the kernel.. which it is now ... Cool. Is the savage driver included? Dave. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New snapshots
Am Montag, den 31.01.2005, 14:04 +0100 schrieb Felix Kühling: Hi all, I just uploaded a new set of experimental snapshots built on our new snapshot build host kindly sponsored by Eric Anholt. They can be found on http://dri.freedesktop.org/~fxkuehl/snapshots for now. Once the daily build is up and running again they will be available from the usual place http://dri.freedesktop.org/snapshots. A new snapshot (*-20050131-linux.i386.tar.bz2) with the linux-2.6 installation problem fixed is now available at http://dri.freedesktop.org/snapshots. I also uploaded a new Xserver binary and modules to http://dri.freedesktop.org/snapshots/extras. This one was built with the normal ProjectRoot. [snip] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to turn on direct rendering on Savage MX?
Am Dienstag, den 01.02.2005, 23:13 +0500 schrieb Dimitry Naldayev: Felix Kühling [EMAIL PROTECTED] writes: Am Sonntag, den 30.01.2005, 20:26 +0500 schrieb Dimitry Naldayev: Hi All. I have done all as described in Building DRI Wiki page with one exception: I have to compile drm module from linux-core subdir not from linux-2.6 becouse the last have wrong drm module version... (unclear why) Don't use drm/linux-2.6. You need drm/linux-core because this is the only place where you will get the new DRM driver 2.x.y. Why not mention this in Building DRI Wiki? There is. It states that the latest drivers or features are only available in linux-core for 2.6 kernels. Also Alex added a specific note about the Savage driver yesterday. Your kernel log looks like you got the right kernel module. Because I got wrong wersion of drm before, but this was noticeable You still have the Savage driver version 1.1.27 which has no DRI support. You need 2.0.0 or newer. Make sure that you compiled Xorg from CVS. If you did, check if you have mixed .so and .o Ohh... There was mixing !!! :( modules /usr/X11R6/lib/modules and subdirectories. Move the .o modules out of the way and run make install again. May will be better to make rm -rf /usr/X11R6 and build from CVS full Xorg, not only DRI part? But how host.def must look for this? If you really want to do this, then an empty host.def would be a good start. You may want to keep some custom compiler optimization options though. And #define NothingOutsideProjectRoot YES is a good idea too. About hardware: I have ASUS L8400C notebook... with Savage MX graphic chip. It should work. It work now!!! thanks. I have gotten 380 fps in glxgears vs. 113 fps without direct rendering. Are there farther way to increase perfomans? are there any options wich I can test? You could experiment with AgpMode and AgpSize in xorg.conf. Also lower resolutions and refresh rates tend to improve performance slightly. But don't expect any miracles. 380 FPS on gears is quite good for a Savage/MX. I get about 350 on a Savage/IX. PS: are the direct rendering work only on :0 display? If I say startx -- :1 will direct rendering work or not and why? It has nothing to do with the display numbers. But only one display can use the DRM at the same time. There was a patch for the Radeon driver once that solved this problem by reinitializing the DRM on VT switches, but the Savage driver doesn't support this now. -- Dimitry -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
New snapshots
Hi all, I just uploaded a new set of experimental snapshots built on our new snapshot build host kindly sponsored by Eric Anholt. They can be found on http://dri.freedesktop.org/~fxkuehl/snapshots for now. Once the daily build is up and running again they will be available from the usual place http://dri.freedesktop.org/snapshots. Please test these snapshots (*-20050130-linux.i386.tar.bz2) and report any problems you may find, especially with the install script. The new snapshots contain the new linux-core/shared-core DRM for 2.6 kernels. On 2.4 kernels the old linux/shared DRM will be built. The default module format changed in Xorg CVS. However, the snapshots are still built with the old module format because that's the format still in use in the latest Xorg releases. If you compiled Xorg from CVS with the new module format you'll have to restore the last release first before installing the new snapshots. AFAIK the new module format is already used at least in one distribution, namely Gentoo. It would be easy to set up builds for both module formats. Then users would have to choose which module format is the correct one for them. I suggest to make dlloader builds available in http://dri.freedesktop.org/snapshots/dlloader/... for those who know that they need them. So much for now, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p
Am Sonntag, den 30.01.2005, 00:09 -0500 schrieb Vladimir Dergachev: Not sure if anyone else gets it... I have to take a look see if I undertsand why I get it. Looks like everyone gets it - glxgears has begin/end pair with only two vertices for a triangle primitive - maybe a bug.. I saw something like this too, when I implemented and debugged the savage fast path. I don't think it's glxgear's fault. More likely a problem further up in the mesa pipeline. (or are you bypassing the pipeline in the r300 driver?) The t_dd_dmatmp.h template ignores extra vertices that don't add up to a whole primitive. I guess you could do the same. I think we are bypassing it, though I am not really sure. r300 driver does not use any templates - I did not have time to find out how to use those. Both mga and r200 use them in a different way, mga driver way appears to be simpler, but does not use vertex buffers (at least in a way I can understand), also it looks like mga hardware cannot do all primitives natively, while r300 can. The other big difference is that mga has not hardware TCL. There was also a discussion between Daniel Borca and Keith Whitwell recently about some display list oddities. It could be that the incomplete primitives you're seeing are related to these issues. HTH, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to turn on direct rendering on Savage MX?
Am Sonntag, den 30.01.2005, 20:26 +0500 schrieb Dimitry Naldayev: Hi All. I have done all as described in Building DRI Wiki page with one exception: I have to compile drm module from linux-core subdir not from linux-2.6 becouse the last have wrong drm module version... (unclear why) Don't use drm/linux-2.6. You need drm/linux-core because this is the only place where you will get the new DRM driver 2.x.y. Your kernel log looks like you got the right kernel module. But direct rendering do not work :( and I have not an idea why --- there is no meanfull description why it dont want work in xorg log :( at least from my point of view... You still have the Savage driver version 1.1.27 which has no DRI support. You need 2.0.0 or newer. Make sure that you compiled Xorg from CVS. If you did, check if you have mixed .so and .o modules /usr/X11R6/lib/modules and subdirectories. Move the .o modules out of the way and run make install again. I have attached configs I have used to build DRI and run Xorg, as well as output dmesg and glxinfo, and Xorg log... Are there any ideas or reccomendations how to turn on direct rendering? About hardware: I have ASUS L8400C notebook... with Savage MX graphic chip. It should work. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p
Am Samstag, den 29.01.2005, 17:25 -0500 schrieb Vladimir Dergachev: On Sun, 30 Jan 2005, Hamie wrote: It's working... Mostly... I get pretty good rates on glxgears... But get a funny error about not enought verticies... [EMAIL PROTECTED]:~$ glxgears r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 8143 frames in 5.0 seconds = 1628.600 FPS 8310 frames in 5.0 seconds = 1662.000 FPS 8241 frames in 5.0 seconds = 1648.200 FPS 8326 frames in 5.0 seconds = 1665.200 FPS 8304 frames in 5.0 seconds = 1660.800 FPS 8317 frames in 5.0 seconds = 1663.400 FPS Not sure if anyone else gets it... I have to take a look see if I undertsand why I get it. Looks like everyone gets it - glxgears has begin/end pair with only two vertices for a triangle primitive - maybe a bug.. I saw something like this too, when I implemented and debugged the savage fast path. I don't think it's glxgear's fault. More likely a problem further up in the mesa pipeline. (or are you bypassing the pipeline in the r300 driver?) The t_dd_dmatmp.h template ignores extra vertices that don't add up to a whole primitive. I guess you could do the same. best Vladimir Dergachev -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mtrr failure
Am Mittwoch, den 26.01.2005, 17:23 +0200 schrieb [EMAIL PROTECTED]: I compiled DRI CVS for Savage (X.org, Mesa and DRM stuff) with instructions from dri.sf.net and install it, DRI isn't working. I get this failure (from dmesg): mtrr: 0x9000,0x200 overlaps existing 0x9000,0x20 mtrr: no more MTRRs available [drm:drm_unlock] *ERROR* Process 6930 using kernel context 0 The MTRR problem is just a warning, nothing to be worried about. The drm_unlock error is the result of a different problem. See below. My laptop is Acer Aspire 1302xc (VIA,Savage Twister,vanilla 2.6.8.1 and 2.6.10). Before christmas DRI was working (in X.org and XFree86), it was not very fast. I have always used vesafb. Savage DRI worked before christmas with vesafb. Now I tryed with vesafb and also with new savagefb, no success with DRI. (With new savagefb X server starts, but screen is very messed, moving mouse cursor makes things even worse. X is useless with my Twister [8d02] and savagefb.) Yes, I tried savagefb briefly and gave up after the first lockup. It's not playing nice with the Xorg driver, or the Xorg driver is not playing nice with savagefb. Anyway, I don't have time to look into this right now. What's wrong with my MTRR or savage DRI, why DRI isn't working? -edie The real problem is that your 2D driver is incompatible with the new kernel module. See your Xorg.0.log, it reports a version mismatch of the kernel module (though message is misleading because it contains a wrong version number :-/ ). You need a 2D driver version 2.0.0 or newer. See http://dri.freedesktop.org/wiki/S3Savage for the big DRI-related changes in the Savage driver you may have missed and http://dri.freedesktop.org/wiki/Building for updated building instructions. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mtrr failure
Am Mittwoch, den 26.01.2005, 19:29 +0200 schrieb [EMAIL PROTECTED]: # What's wrong with my MTRR or savage DRI, why DRI isn't working? # -edie # # The real problem is that your 2D driver is incompatible with the new # kernel module. See your Xorg.0.log, it reports a version mismatch of the # kernel module (though message is misleading because it contains a wrong # version number :-/ ). You need a 2D driver version 2.0.0 or newer. See # http://dri.freedesktop.org/wiki/S3Savage for the big DRI-related changes # in the Savage driver you may have missed and # http://dri.freedesktop.org/wiki/Building for updated building # instructions. # Felix (I patched xorg cvs with buildtools.patch, I don't know is this important to my error) I used http://freedesktop.org/~fxkuehl/host.def and edited 2D driver list to look like this: #define XF86CardDrivers savage Then make World, make install, ldconfig. Manually this copies 2D driver files? cp exports/lib/modules/drivers/*_drv.o /usr/X11R6/lib/modules/drivers When I look both dirs, savage drivers are the same (or link to same name and size file). Is there something wrong with compiling or installing 2D driver files? Oh, it seems you are another victim of the binary module format change. You still have old .o modules around next to the new .so modules. Unfortunately it's pretty unpredictable which module X chooses to load when both a new .so and an old .o module exits. Try moving the whole /usr/X11R6/lib/modules directory out of the way and run make install again in the xorg tree. This way you should end up with a clean tree that has only the new .so modules. Make sure that you have the latest version of my host.def. Otherwise you don't get a new keyboard driver. Mesa and DRM (drm.ko and savage.ko, from drm/linux-core dir) I builded from cvs also. That should be fine. -edie- -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch] Fair usage of all texture heaps
Hi,
The attached patch is my first cut at implementing a fair strategy for
using all texture heaps. This solves my texture trashing problems with
Torcs on Savage4 and ProSavageDDR. Testing and comments are welcome. I'm
especially interested if anyone sees any performance regressions with
this.
Heaps are now weighted by their sizes. That is, the bigger a heap, the
more data will be kicked from/uploaded to it. If upload performance
differs greatly then it would be quite easy to multiply a heap-specific
factor to that weight in order to introduce a heap preference. This
could be done either directly in the driver just after allocating a
texture heap (heap-weight *= factor) or by adding a new parameter to
driCreateTextureHeap.
Note that the new code in my patch will not be active as long as there
is enough free space on any texture heap. So in order to see any
performance difference you will either have to test with a very
texture-hungry application or artificially reduce the amount of texture
memory on one or both heaps. Also note that you need at least two
texture heaps, so r200 is a bad candidate. ;-)
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- ./texmem.c.~1.7.~ 2004-07-10 13:26:36.0 +0200
+++ ./texmem.c 2005-01-25 23:27:51.0 +0100
@@ -477,6 +477,8 @@
+#define INDEX_ARRAY_SIZE 6 /* I'm not aware of driver with more than 2 heaps */
+
/**
* Allocate memory from a texture heap to hold a texture object. This
* routine will attempt to allocate memory for the texture from the heaps
@@ -528,35 +530,91 @@
*/
if ( t-memBlock == NULL ) {
- for ( id = 0 ; (t-memBlock == NULL) (id nr_heaps) ; id++ ) {
+ unsigned index[INDEX_ARRAY_SIZE];
+ unsigned nrGoodHeaps = 0;
+
+ /* Trying to avoid dynamic memory allocation. If you have more
+ * heaps, increase INDEX_ARRAY_SIZE. I'm not aware of any
+ * drivers with more than 2 tex heaps. */
+ assert( nr_neaps INDEX_ARRAY_SIZE );
+
+ /* Sort large enough heaps by duty. Insertion sort should be
+ * fast enough for such a short array. */
+ for ( id = 0 ; id nr_heaps ; id++ ) {
heap = heap_array[ id ];
- if ( t-totalSize = heap-size ) {
- for ( cursor = heap-texture_objects.prev, temp = cursor-prev;
- cursor != heap-texture_objects ;
- cursor = temp, temp = cursor-prev ) {
-
- /* The the LRU element. If the texture is bound to one of
- * the texture units, then we cannot kick it out.
- */
- if ( cursor-bound /* || cursor-reserved */ ) {
- continue;
- }
+ if ( t-totalSize = heap-size ) {
+ unsigned j;
+
+ for ( j = 0 ; j nrGoodHeaps; j++ ) {
+ if ( heap-duty heap_array[ index[ j ] ]-duty )
+ break;
+ }
- /* If this is a placeholder, there's no need to keep it */
- if (cursor-tObj)
- driSwapOutTextureObject( cursor );
- else
- driDestroyTextureObject( cursor );
+ if ( j nrGoodHeaps ) {
+ memmove( index[ j+1 ], index[ j ],
+ sizeof(index[ 0 ]) * (nrGoodHeaps - j) );
+ }
- t-memBlock = mmAllocMem( heap-memory_heap, t-totalSize,
- heap-alignmentShift, 0 );
+ index[ j ] = id;
- if (t-memBlock)
- break;
+ nrGoodHeaps++;
+ }
+ }
+
+ for ( id = 0 ; (t-memBlock == NULL) (id nrGoodHeaps) ; id++ ) {
+ heap = heap_array[ index[ id ] ];
+
+ for ( cursor = heap-texture_objects.prev, temp = cursor-prev;
+ cursor != heap-texture_objects ;
+ cursor = temp, temp = cursor-prev ) {
+
+ /* The the LRU element. If the texture is bound to one of
+ * the texture units, then we cannot kick it out.
+ */
+ if ( cursor-bound /* || cursor-reserved */ ) {
+ continue;
}
- } /* if ( t-totalSize = heap-size ) ... */
+
+ if ( cursor-memBlock )
+ heap-duty -= cursor-memBlock-size;
+
+ /* If this is a placeholder, there's no need to keep it */
+ if (cursor-tObj)
+ driSwapOutTextureObject( cursor );
+ else
+ driDestroyTextureObject( cursor );
+
+ t-memBlock = mmAllocMem( heap-memory_heap, t-totalSize,
+ heap-alignmentShift, 0 );
+
+ if (t-memBlock)
+ break;
+ }
}
+
+ /* Rebalance duties. If a heap kicked more data than its duty,
+ * then all other heaps get that amount multiplied with their
+ * relative weight added to their duty. The negative duty is
+ * reset to 0. In the end all heaps have a duty = 0.
+ *
+ * CAUTION: we must not change the heap pointer here, because it
+ * is used below to update the texture object.
+ */
+ for ( id = 0 ; id nr_heaps ; id++ )
+ if ( heap_array[ id ]-duty 0) {
+ int duty = -heap_array[ id ]-duty;
+ double weight = heap_array[ id ]-weight;
+ unsigned j;
+
+ for ( j = 0 ; j nr_heaps ; j
Re: Texture heap preference in driAllocateTexture
Am Montag, den 24.01.2005, 11:45 +0100 schrieb Dieter Nützel:
Am Montag, 24. Januar 2005 02:34 schrieb Felix Kühling:
Hi,
After converting the Savage driver to use Ian's common texmem code I
noticed a performance regression in Torcs. It's trashing textures a lot
where it was running very smoothly before. I believe this is due to a
different texture heap preference. If I reverse the preference I get
back to the performance I had with my own texture memory management.
Do you have a hint to reverse it for radeon/r200?
On r200 it won't have any effect because r200 uses only one texture
heap. On a typical r100 configuration the AGP heap is the smaller one,
so the current preference yields good results. Anyway, if you want to
hack up a reversed heap preference, do this:
--- ./texmem.c.~1.7.~ 2004-07-10 13:26:36.0 +0200
+++ ./texmem.c 2005-01-24 13:14:23.0 +0100
@@ -529,7 +529,7 @@
if ( t-memBlock == NULL ) {
for ( id = 0 ; (t-memBlock == NULL) (id nr_heaps) ; id++ ) {
-heap = heap_array[ id ];
+heap = heap_array[ nr_heaps - id - 1 ];
if ( t-totalSize = heap-size ) {
for ( cursor = heap-texture_objects.prev, temp = cursor-prev;
I'll gave it a try then.
Thanks,
Dieter
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture heap preference in driAllocateTexture
not agree with all my conclusions, but you certainly made me consider a few more parameters. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon m7 hang with gears...hopefully fixed..
Am Sonntag, den 23.01.2005, 11:23 + schrieb Dave Airlie: Okay it was an old bug resurfaced by the looks of it.. there used to be code written by Felix in the radeon driver to always emit a zbs atom no matter what, I've spent two days staring at the driver and the attached patch looks to fix the gears crapping out ... AFAIK, the zbs hack was added by Keith originally. It has been in the driver as long as I know it. I wrote some other workaround that emitted state in a well defined order, which fixed some lockups. Maybe someone thought this would make the zbs hack unnecessary, but it looks like whoever it was, was wrong. I've played q3, ut2003 and ut2004 and ran gears.. all for about 5 mins each... no problems.. switching OLD_PACKETS off and arrays on doesn't give a speedup with the hack for zbs (it slows it down..) but adding flush less brings it back nearly on par with OLD_PACKETS... There might be a better way to do this workaround... maybe ATI might know something (docs don't say anything...) Dave. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Texture heap preference in driAllocateTexture
Hi, After converting the Savage driver to use Ian's common texmem code I noticed a performance regression in Torcs. It's trashing textures a lot where it was running very smoothly before. I believe this is due to a different texture heap preference. If I reverse the preference I get back to the performance I had with my own texture memory management. In my setup I have 6MB on the local heap and 30MB on the AGP heap. The common texmem code always tries to allocate a texture on the local heap first. Therefore there can be a lot of texture trashing on the small local heap while the bigger AGP heap is nearly unused, because it is basically only used for textures that are bigger than the local heap. I intend to improve the heuristics that chooses the texture heap in driAllocateTexture. This may involve the texture size to allocate, the heap sizes and the amount of free space on each heap and maybe the ages of textures on each heap. I haven't thought too much about the details yet. If anyone has already put some thought into this I'd appreciate your input. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
Am Donnerstag, den 20.01.2005, 20:43 -0500 schrieb Adam Jackson: On Thursday 20 January 2005 18:28, Felix Kühling wrote: Am Donnerstag, den 20.01.2005, 11:05 -0800 schrieb Adam Jackson: CVSROOT: /cvs/dri Module name: drm Repository: drm/shared/ Changes by: [EMAIL PROTECTED] 05/01/20 11:05:42 Log message: Add a Savage3D PCI ID Modified files: drm/shared-core/: drm_pciids.txt drm/shared/: drm_pciids.txt Revision ChangesPath 1.13 +1 -0 drm/shared-core/drm_pciids.txt 1.11 +1 -0 drm/shared/drm_pciids.txt It seems the problem was a typo. I couldn't find the PCI ID 0x8c20 anywhere in the X.org or kernel trees while 0x8a20 (the one you added) can be found in both. I'm not sure anymore where this list of PCI IDs came from originally, but I'm pretty sure 0x8c20 can be safely removed. 0x8c21 should also be moved down to 0x8a21, it seems: http://pciids.sourceforge.net/iii/?i=5333 Yeah, I fixed both IDs in CVS. BTW, some ProSavage names in pciids.sf.net are a little questionable or inconsistent. Am I right in assuming that pciids.sf.net is the upstream PCI IDs source used in the Linux kernel? Should I report a bug only there or against the kernel too? Other savage3d woes to be detailed later... What woes? - ajax -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage3d bugs
Am Freitag, den 21.01.2005, 11:51 -0500 schrieb Adam Jackson: [snip] I believe that's correct, ie, file bugs at pciids and they'll get pushed outward from there. Thanks. I'll do that. Other savage3d woes to be detailed later... What woes? Something in the last few weeks has made my savage3d highly nonconformant. In 16bpp the corruption is best described as some operations have their Y coordinate scaled down by two, so things looks squished against the top of the screen. In 32bpp these same operations are simply not on the screen at all. So, for example, my background image gets painted on half the screen in 16bpp but not at all in 32bpp. I can try for some screenshots if it'd help. Hopefully this is localizable to one XAA op. This is a dualhead card, two savages behind a PCI bridge. I see this corruption on both heads. GL works pretty well on the first head (runs glxgears, but times out in the quake3 splash screen), but not at all on the second head (times out on everything). This timeout brings down the server too after a few seconds. Hmm, if it affects the Xserver then it's likely a chip lockup. Have you enabled ShadowStatus in xorg.conf? Also try if disabling vertex DMA (added the option to the 3D driver yesterday) makes any difference in stability. Oh yeah, and NoAccel makes the display totally broken, and ShadowFB crashes the server on startup for some vaguely Damage-related reason. On the flipside, my savage2k works in 2D now, so it's not all bad news. - ajax -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
Am Donnerstag, den 20.01.2005, 11:05 -0800 schrieb Adam Jackson: CVSROOT: /cvs/dri Module name: drm Repository: drm/shared/ Changes by: [EMAIL PROTECTED] 05/01/20 11:05:42 Log message: Add a Savage3D PCI ID Modified files: drm/shared-core/: drm_pciids.txt drm/shared/: drm_pciids.txt Revision ChangesPath 1.13 +1 -0 drm/shared-core/drm_pciids.txt 1.11 +1 -0 drm/shared/drm_pciids.txt It seems the problem was a typo. I couldn't find the PCI ID 0x8c20 anywhere in the X.org or kernel trees while 0x8a20 (the one you added) can be found in both. I'm not sure anymore where this list of PCI IDs came from originally, but I'm pretty sure 0x8c20 can be safely removed. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxgears is blank on savage
Am Dienstag, den 18.01.2005, 20:04 -0800 schrieb Mark Cass: savage driver team, when i run glxgears a window appears but nothing is displayed. the shell from which glxgears was run displays the usual frames per second and no other information. i checked glxinfo and dri is enabled. also found nothing unusual in the X log file. i have two options set APGMode to 4 and AGPSize to 32. i tried without using these options with the same result. the system is using the savage twister with 32 MB and AGP 4X. it is detected and reported as such in the X log file. the X server is running at 1280x1024 and using 16 bit color. I had such a problem once too with a Savage4 AGP. A reboot fixed it. I never found out what was wrong. :-/ what is strange is that this same code (no recompile, code was compiled on a intel based machine) works on another system i have. this other system is an AMD Athlon processor using a 32MB AGP 4X savage 4 video card. glxgears runs properly (i see gears spinning). i use the same settings for the x server and savage options as mentioned above. i have had dri working correctly in the past on the twister but it was way back in march of 2004. at that time it worked fine. Can you track down at which change it broke exactly (using cvs update -Ddate)? Mailing list archives of dri-patches and mesa-cvs may be helpful. the code i am using is from an earlier version (before the kernel 2.6, X org change over). i have to use the old driver that works for the linux 2.4 kernel (no choice, blame it on management). i think the version dates back to about May of 2004. I can't offer any support for this old stuff. Sorry. if you have any ideas please let me know. thanks in advance, mark ps. some time ago i worked out the details for texture compression. i did not go as far as to include the 'on the fly' compression stuff. i have tested the loading of compressed textures and sub textures and both perform as expected. if you would like to include this in your latest stuff just let me know and i will post the source code files. all the files are commented quite clearly concerning the changes made. Definitely. You can send it to me personally or to the dri-devel list, whatever you prefer. I might integrate it into the current driver one of the next weekends. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch] spantmp2.h optimization
Hi,
the attached patch optimizes the spantmp2.h template by avoiding
redundant address computations for every pixel in linear spans. Since
the assembler read functions make the same assumptions that should not
affect existing users of the template.
Unfortunately there is hardly any measurable speedup on the Savage. But
I suspect that's a hardware limitation with CPU access to tiled surfaces
(linear mapping of tiled frame buffer). If the effect of my patch is
more significant on other hardware I'll commit this patch to CVS. A good
test should be the glxgears framerate with no_rast=true.
(I only tested it with 16bpp so far, before committing anything I'd make
sure that 32bpp works as well.)
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: spantmp2.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/spantmp2.h,v
retrieving revision 1.6
diff -u -r1.6 spantmp2.h
--- spantmp2.h 15 Jan 2005 14:35:35 - 1.6
+++ spantmp2.h 17 Jan 2005 22:55:04 -
@@ -65,25 +65,21 @@
#if (SPANTMP_PIXEL_FMT == GL_RGB) (SPANTMP_PIXEL_TYPE == GL_UNSIGNED_SHORT_5_6_5)
+#define PIXEL_TYPE GLushort
+
#define INIT_MONO_PIXEL(p, color) \
p = PACK_COLOR_565( color[0], color[1], color[2] )
-#define WRITE_RGBA( _x, _y, r, g, b, a )\
-do {\
- GLshort * _p = (GLshort *) GET_DST_PTR(_x, _y); \
+#define WRITE_RGBA_P( _p, r, g, b, a) \
_p[0] = int)r 0xf8) 8) | (((int)g 0xfc) 3) | \
- (((int)b 0xf8) 3)); \
- } while(0)
+ (((int)b 0xf8) 3))
-#define WRITE_PIXEL( _x, _y, p ) \
- do { \
- GLushort * _p = (GLushort *) GET_DST_PTR(_x, _y); \
- _p[0] = p;\
- } while(0)
+#define WRITE_PIXEL_P( _p, p ) \
+ _p[0] = p
-#define READ_RGBA( rgba, _x, _y ) \
+#define READ_RGBA_P( rgba, _p ) \
do { \
- GLushort p = *(volatile GLshort *) GET_SRC_PTR(_x, _y); \
+ GLushort p = *_p; \
rgba[0] = ((p 8) 0xf8) * 255 / 0xf8;\
rgba[1] = ((p 3) 0xfc) * 255 / 0xfc;\
rgba[2] = ((p 3) 0xf8) * 255 / 0xf8;\
@@ -92,46 +88,42 @@
#elif (SPANTMP_PIXEL_FMT == GL_BGRA) (SPANTMP_PIXEL_TYPE == GL_UNSIGNED_INT_8_8_8_8_REV)
+#define PIXEL_TYPE GLuint
+
# define INIT_MONO_PIXEL(p, color) \
p = PACK_COLOR_(color[3], color[0], color[1], color[2])
-
-# define WRITE_RGBA(_x, _y, r, g, b, a) \
-do {\
- GLuint * _p = (GLuint *) GET_DST_PTR(_x, _y);\
- _p[0] = ((r 16) | (g 8) | (b 0) | (a 24)); \
-} while(0)
-
-#define WRITE_PIXEL(_x, _y, p) \
-do {\
- GLuint * _p = (GLuint *) GET_DST_PTR(_x, _y);\
- _p[0] = p; \
-} while(0)
+
+#define WRITE_RGBA_P( _p, r, g, b, a) \
+ _p[0] = ((r 16) | (g 8) | (b 0) | (a 24))
+
+#define WRITE_PIXEL_P( _p, p ) \
+ _p[0] = p
# if defined( USE_X86_ASM )
-# define READ_RGBA(rgba, _x, _y) \
-do {\
-GLuint p = *(volatile GLuint *) GET_SRC_PTR(_x, _y);\
- __asm__ __volatile__( bswap %0; rorl $8, %0\
-: =r (p) : r (p) ); \
- ((GLuint *)rgba)[0] = p; \
+# define READ_RGBA_P(rgba, _p) \
+do {\
+GLuint p = *_p; \
+ __asm__ __volatile__( bswap %0; rorl $8, %0 \
+: =r (p) : r (p) ); \
+ ((GLuint *)rgba)[0] = p; \
} while (0)
# elif defined( MESA_BIG_ENDIAN )
/* On PowerPC with GCC 3.4.2 the shift madness below becomes a single
* rotlwi instruction. It also produces good code on SPARC.
*/
-# define READ_RGBA( rgba, _x, _y )\
+# define READ_RGBA_P( rgba, _p )\
do {\
-GLuint p = *(volatile GLuint *) GET_SRC_PTR(_x, _y);\
-GLuint t = p; \
-*((uint32_t *) rgba) = (t 24) | (p 8);\
+GLuint p = *_p; \
+ GLuint t = p; \
+ *((uint32_t *) rgba) = (t 24) | (p 8); \
} while (0)
# else
-# define READ_RGBA( rgba, _x, _y )\
+# define READ_RGBA_P( rgba, _p ) \
do
Re: savage dma performance
Am Mittwoch, den 12.01.2005, 17:34 -0800 schrieb Mark Cass: felix, is there a noticable performance difference with DMA versus the non-dma version of the savage driver? It depends on the application. I've noticed a big performance improvement with Torcs for example. The main reason is probably that you can get many more indexed drawing commands (using vertex DMA) onto the command queue than drawing commands with inline vertices. This way parallelism between CPU and GPU can be exploited more effectively. i have concluded that the DMA driver work can only be compiled and used with the linux 2.6 kernel, is this true? Yes, this is correct. If you really need this to work on a 2.4 kernel then you could try to backport it to the old DRM. I ask becuase i am stuck back on the 2.4 kernel. I also believe you mentioned that it will not work for savage 4 and twister (based on savage 4) chipsets. what is the time frame for the savage 4/ twister DMA support? Vertex DMA is working with Savage4-based cards. However, it doesn't work for all vertex formats. The current driver can use DMA for almost everything by choosing an appropriate vertex format, but it can't be used with multi-texturing in most cases. I'm going to implement command DMA for Savage4-based cards at some point. I expect this to have about the same effect as vertex DMA WRT parallelism between CPU and GPU. if it is true that kernel 2.4 is not supported, how difficult would it be for me make the DMA stuff work in the old driver? what would be a good sample driver to work form? If you want a DRM driver that works with the current Mesa driver you need something that has the same binary interface. The only way is to take the Savage DRM driver from linux-core/shared-core and backport it to the old linux/shared DRM. Other drivers that exist both in the old and new DRM might give you a hint what needs to be done. There is also a small bit in the DRM core that would have to be backported to the old DRM, nameley the _DRM_CONSISTENT map type. This is needed for mapping the shadow status page in the Xserver. mark -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Post-processing hook for vertex setup code
Hi,
I'm trying to get projective textures working on hardware that doesn't
support homogenous texture coordinates with the new vertex setup code
(t_vertex.[ch]). The problem with this is that the W coordinate of the
hardware vertex must be computed from two vertex attributes, which is
why the new vertex setup code can't generated it directly.
The solution I'm proposing emits homogenous texture coordinates and then
calls a vertex post-processing hook in the driver that can compute W and
2D tex coords suitable for my crippled hardware from homogenous tex
coords.
I'm attaching two patches. The first one implements the
driver-independent functionality for hooking up a post-processing
function. The second one demonstrates the changes to the Savage driver
to support projective texturing using the post-processing hook.
I'd appreciate feedback (Keith?) if this is good for CVS or if there are
other/better ideas for solving the same problem.
Thanks,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- ./t_context.h.~1.64.~ 2004-07-23 16:18:37.0 +0200
+++ ./t_context.h 2004-12-17 19:56:09.0 +0100
@@ -539,6 +539,10 @@
GLuint start,
GLuint end, void *dest );
+typedef void (*tnl_postproc_func)( GLcontext *ctx,
+ GLuint start,
+ GLuint end, void *dest );
+
/**
* Describes how to convert/move a vertex attribute from a vertex array
@@ -631,6 +635,7 @@
tnl_emit_func emit;
tnl_interp_func interp;
tnl_copy_pv_func copy_pv;
+ tnl_postproc_func postproc;
struct tnl_clipspace_codegen codegen;
};
--- ./t_vertex.c.~1.24.~ 2004-10-27 11:12:58.0 +0200
+++ ./t_vertex.c 2004-12-17 20:07:30.0 +0100
@@ -1177,6 +1177,7 @@
vtx-emit = 0;
vtx-interp = choose_interp_func;
vtx-copy_pv = choose_copy_pv_func;
+ vtx-postproc = 0;
vtx-new_inputs = ~0;
for (j = 0, i = 0; i nr; i++) {
@@ -1225,6 +1226,12 @@
}
+void _tnl_install_postproc( GLcontext *ctx, tnl_postproc_func func )
+{
+ struct tnl_clipspace *vtx = GET_VERTEX_STATE(ctx);
+ vtx-postproc = func;
+}
+
void _tnl_invalidate_vertices( GLcontext *ctx, GLuint newinputs )
{
@@ -1245,8 +1252,11 @@
newinputs |= vtx-new_inputs;
vtx-new_inputs = 0;
- if (newinputs)
+ if (newinputs) {
do_emit( ctx, start, end, vDest );
+ if (vtx-postproc)
+ vtx-postproc( ctx, start, end, vDest );
+ }
}
--- ./t_vertex.h.~1.12.~ 2004-10-27 11:12:58.0 +0200
+++ ./t_vertex.h 2004-12-17 20:07:15.0 +0100
@@ -103,6 +103,9 @@
GLuint nr, const GLfloat *vp,
GLuint unpacked_size );
+extern void _tnl_install_postproc( GLcontext *ctx,
+ tnl_postproc_func func);
+
--- ./savagedma.c.~1.4.~ 2004-12-15 16:37:19.0 +0100
+++ ./savagedma.c 2004-12-17 21:35:56.0 +0100
@@ -312,8 +312,8 @@
};
void savageFakeVertices (savageContextPtr imesa, drmBufPtr buffer) {
-GLuint vertexStride = imesa-vertex_size; /* stride in dwords */
-GLuint vertexSize = imesa-vertex_size; /* the real vertex size in dwords */
+GLuint vertexStride = imesa-HwVertexSize; /* stride in dwords */
+GLuint vertexSize = imesa-HwVertexSize; /* the real vertex size in dwords */
GLuint nVertices = buffer-used / (vertexStride*4);
u_int32_t *data = (u_int32_t*)buffer-address;
u_int32_t vertexFormat = imesa-DrawPrimitiveCmd SAVAGE_HW_SKIPFLAGS;
--- ./savagecontext.h.~1.11.~ 2004-12-17 16:06:50.0 +0100
+++ ./savagecontext.h 2004-12-17 20:35:19.0 +0100
@@ -179,6 +179,7 @@
GLenum render_primitive;
GLuint DrawPrimitiveCmd;
+ GLuint HwVertexSize;
/* Fallback rasterization functions
*/
--- ./savagetris.c.~1.16.~ 2004-12-17 16:34:52.0 +0100
+++ ./savagetris.c 2004-12-17 21:57:58.0 +0100
@@ -99,7 +99,7 @@
savageVertexPtr v0,
savageVertexPtr v1,
savageVertexPtr v2) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize;
u_int32_t *vb = savageAllocDmaLow (imesa, 3*4*vertsize);
GLuint j;
@@ -113,7 +113,7 @@
savageVertexPtr v1,
savageVertexPtr v2,
savageVertexPtr v3) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize;
u_int32_t *vb = savageAllocDmaLow (imesa, 6*4*vertsize);
GLuint j;
@@ -127,7 +127,7 @@
static __inline__ void savage_draw_point (savageContextPtr imesa,
savageVertexPtr tmp) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize;
u_int32_t *vb = savageAllocDmaLow (imesa, 6*4*vertsize);
const GLfloat x = tmp-v.x;
const GLfloat y = tmp-v.y;
@@ -162,7 +162,7 @@
static __inline__ void savage_draw_line (savageContextPtr imesa,
savageVertexPtr v0,
savageVertexPtr v1 ) {
- GLuint vertsize = imesa-vertex_size;
+ GLuint vertsize = imesa-HwVertexSize
Re: [Mesa3d-dev] Artifacts with very large texture coordinates
Sorry folks, I attached the wrong file. This is the second time in a
week. I have to be more careful. Now the correct program.
Am Do, den 16.12.2004 schrieb Felix Kühling um 1:11:
Hi,
I noticed some strange rendering artifacts with the Savage that are
caused by very large texture coordinates on GL_REPEAT'ed textures. Very
large means that it gets noticeable with texture coordinates 255 or
-256. A real world example that exhibits this problem is Torcs with the
Spring track. Right at the start the effect can be seen very nicely.
The track before the start line shows artifacts, directly after the
start line everything looks fine.
My question is, should I consider such problems an application bug or
would it be wise to implement a workaround? I was thinking of
implementing a TNL pipeline stage that normalizes texture coordinates.
I was also wondering if other hardware has similar problems. I'm
attaching a small test program that demonstrates the effect and a
screenshot of what I get on my ProSavageDDR. With software rendering the
output is almost correct. Compile with
cc -lGL -lGLU -lglut teximage.c -o teximage
Thanks in advance,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
#include GL/gl.h
#include GL/glu.h
#include GL/glut.h
#include stdio.h
#include stdlib.h
#define TEX_OFFSET_X 1024.0
#define TEX_OFFSET_Y 1024.0
#define MAX_WIDTH 128
#define MAX_HEIGHT 128
GLubyte texData[MAX_WIDTH * MAX_HEIGHT * 3];
GLuint texture;
GLuint tWidth = 0, tHeight = 0;
void init () {
GLuint x, y;
GLubyte *p;
glClearColor (0.0, 0.0, 0.0, 0.0);
glShadeModel (GL_FLAT);
p = texData;
for (y = 0; y tHeight; ++y)
for (x = 0; x tWidth; ++x, p += 3) {
if ((x 7) == 4 || (y 7) == 4) {
p[0] = 0;
p[1] = 0;
p[2] = 255;
} else {
p[0] = tWidth 1 ? x * 255 / (tWidth-1) : 128;
p[1] = tHeight 1 ? y * 255 / (tHeight-1) : 128;
p[2] = 0;
}
}
glGenTextures (1, texture);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, tWidth, tHeight, 0,
GL_RGB, GL_UNSIGNED_BYTE, texData);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
}
void display () {
glClear (GL_COLOR_BUFFER_BIT);
glEnable(GL_TEXTURE_2D);
glBindTexture (GL_TEXTURE_2D, texture);
glBegin(GL_QUADS);
glColor3f(1.0, 1.0, 0.0);
glTexCoord2f(0.0+TEX_OFFSET_X, 2.0+TEX_OFFSET_Y); glVertex2f(-1.0, -1.0);
glTexCoord2f(2.0+TEX_OFFSET_X, 2.0+TEX_OFFSET_Y); glVertex2f( 1.0, -1.0);
glTexCoord2f(2.0+TEX_OFFSET_X, 0.0+TEX_OFFSET_Y); glVertex2f( 1.0, 1.0);
glTexCoord2f(0.0+TEX_OFFSET_X, 0.0+TEX_OFFSET_Y); glVertex2f(-1.0, 1.0);
glEnd();
glutSwapBuffers();
}
void reshape (int w, int h) {
glViewport (0, 0, (GLsizei) w, (GLsizei) h);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
glOrtho (-1.0, 1.0, -1.0, 1.0, -1.0, 1.0);
glMatrixMode (GL_MODELVIEW);
}
int main (int argc, char *argv[]) {
int winId;
if (argc 2)
tWidth = 128;
else if (sscanf (argv[1], %u, tWidth) != 1) {
fprintf (stderr, Error: invalid width: %s\n, argv[1]);
return 1;
}
if (argc 3)
tHeight = 128;
else if (sscanf (argv[2], %u, tHeight) != 1) {
fprintf (stderr, Error: invalid height: %s\n, argv[2]);
return 1;
}
if (tWidth == 0 || tWidth MAX_WIDTH) {
fprintf (stderr, Error: width out of range [1:%u].\n, MAX_WIDTH);
return 1;
}
if (tHeight == 0 || tHeight MAX_HEIGHT) {
fprintf (stderr, Error: height out of range [1:%u].\n, MAX_HEIGHT);
return 1;
}
glutInit (argc, argv);
glutInitDisplayMode (GLUT_RGBA | GLUT_DOUBLE);
glutInitWindowSize (250, 250);
glutInitWindowPosition (100, 100);
winId = glutCreateWindow (Texture Test);
init ();
glutDisplayFunc (display);
glutReshapeFunc (reshape);
glutMainLoop ();
return 0;
}
Re: Artifacts with very large texture coordinates
Am Do, den 16.12.2004 schrieb Brian Paul um 16:45:
Felix Kühling wrote:
Hi,
I noticed some strange rendering artifacts with the Savage that are
caused by very large texture coordinates on GL_REPEAT'ed textures. Very
large means that it gets noticeable with texture coordinates 255 or
-256. A real world example that exhibits this problem is Torcs with the
Spring track. Right at the start the effect can be seen very nicely.
The track before the start line shows artifacts, directly after the
start line everything looks fine.
My question is, should I consider such problems an application bug or
would it be wise to implement a workaround? I was thinking of
implementing a TNL pipeline stage that normalizes texture coordinates.
That could be tricky. If you're thinking of doing something like t' =
t MOD maxValue, that'll often cause incorrect interpolation.
The trick is that you have to change (add or subtract) all texture
coordinates in one primitive (e.g. triangle) in the same way, that is,
the relative differences between texcoords must not be changed.
I've already hacked up something and the result looks good. It computes
the max and min coordinates per direction and then subtracts
floor((max+min)/2 + 0.5)
from all texture coordinates in the vertex buffer. This is done only for
texture coordinates for which the wrapping mode is GL_REPEAT. I havn't
measured the performance, but I didn't notice a major difference. I
guess the Savage has other bottle-necks. ;-)
A patch is attached for anyone who wants to see the gory details.
I was also wondering if other hardware has similar problems. I'm
attaching a small test program that demonstrates the effect and a
screenshot of what I get on my ProSavageDDR. With software rendering the
output is almost correct. Compile with
cc -lGL -lGLU -lglut teximage.c -o teximage
If the hardware implements texcoord interpolation with fixed point you
can imagine how the bits are used.
If the largest texture dimension is 2048, you'd need at least 11 bits
to address all texels.
Then you need some sub-texel bits for accurate interpolation and for
computing the weighting for linear sampling. You probably need 10
bits there.
Allocate another bit for the sign.
Finally, whatever bits are left in the interpolator will limit the
maximum coordinate range. If the interpolator is 32 bits, then 32 -
11 - 10 - 1 = 10. So the max coordinate would be 2^10 or 1024.
Maybe the savage hardware has a narrow interpolator, or allocates the
bits differently.
When you increase the texture coordinate offset you can see the
artifacts get worse with every power of two. So you can literally take
away bits available for the interpolation on the Savage by making
texture coordinates bigger. :)
I believe one of the differences between pro and consumer cards is
the accuracy and range of interpolators.
Or maybe more expensive hardware does the normalization per
hardware-primitive before it starts interpolating.
-Brian
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
? core.2742
? core.2751
? debugfallback.diff
? depend
? diff-20041215
? savage_mesa_20041019.diff
? savage_texnorm.diff
? savagestate.diff
? savagetris.diff
? throttle_and_front.diff
Index: savage_xmesa.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savage_xmesa.c,v
retrieving revision 1.18
diff -u -r1.18 savage_xmesa.c
--- savage_xmesa.c 15 Dec 2004 17:45:23 - 1.18
+++ savage_xmesa.c 16 Dec 2004 21:16:10 -
@@ -109,6 +109,22 @@
NULL
};
+extern const struct tnl_pipeline_stage _savage_texnorm_stage;
+
+static const struct tnl_pipeline_stage *savage_pipeline[] = {
+
+ _tnl_vertex_transform_stage,
+ _tnl_normal_transform_stage,
+ _tnl_lighting_stage,
+ _tnl_fog_coordinate_stage,
+ _tnl_texgen_stage,
+ _tnl_texture_transform_stage,
+ _savage_texnorm_stage,
+ _tnl_render_stage,
+ 0,
+};
+
+
/* this is first function called in dirver*/
static GLboolean
@@ -455,7 +471,7 @@
/* Install the customized pipeline:
*/
-#if 0
+#if 1
_tnl_destroy_pipeline( ctx );
_tnl_install_pipeline( ctx, savage_pipeline );
#endif
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.14
diff -u -r1.14 savagetris.c
--- savagetris.c 14 Dec 2004 22:37:46 - 1.14
+++ savagetris.c 16 Dec 2004 21:16:11 -
@@ -911,3 +911,189 @@
SAVAGE_CONTEXT(ctx)-verts = (char *)tnl-clipspace.vertex_buf;
}
+
+
+/***
+ * Pipeline stage for texture coordinate normalization
+ * This should probably go somewhere else.
+ ***/
+struct texnorm_stage_data {
+ GLvector4f texcoord[MAX_TEXTURE_UNITS];
+};
+
+#define TEXNORM_STAGE_DATA(stage
Re: New snapshots available at dri.freedesktop.org (was: [Dri-users] Snapshots)
Am Mi, den 15.12.2004 schrieb May Dousak um 12:16: I'm sorry if I'm not following everything about DRI but I was a surprised when I saw there were no more snapshots. Is that an error or have been snapshots removed permamently? No they were not removed permanently. The old place for uploading them disappeared and the new one was not ready yet. I just saw that someone created a virtual server for DRI on freedesktop.org. I uploaded the snapshots from after the fd.o break-in to http://dri.freedesktop.org/snapshots. Daily snapshots should show up there from now on. The extras directory is still missing. I'll have to build an Xorg server and Xorg driver modules for that. Greetings, May Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
Am Mi, den 01.12.2004 schrieb Adam Jackson um 5:27: On Monday 29 November 2004 17:03, Felix Kühling wrote: There is no dri.freedesktop.org yet. I think there is no need for a redirect. The current place is already different from where it was before the break-in (used to be in ~dri/snapshots now it's in dri/snapshots). If you could setup a dri.freedesktop.org that would be great. Maybe we could move our Wiki from sourceforge to the new location. Ajax, are you reading this? What do you think about upgrading to a newer MoinMoin version with ACLs while we're at it. I wasn't reading, sorry, I was blissfully afk over the holiday. The moinmoin version on fd.o is a good one, so we should be able to just copy our old wiki over. I'll see if I can't hit this before I skip town again. What about José's modifications? How important are they and how difficult would it be to port them to the new version? - ajax -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
Am Sa, den 27.11.2004 schrieb Daniel Stone um 12:28: On Fri, 2004-11-26 at 15:46 +0100, Felix Kühling wrote: I just found http://www.freedesktop.org/dri/snapshots/. Now I wonder where I find this in the freedesktop.org filesystem. Is it /srv or /home/srv? Ah, I just saw it's the same thing with a bind mount from /home/srv to /srv. So I guess /srv is the path to use in scripts even it is ever moved to another file system. I'm going to set up a snapshot cron job in my freedesktop account that builds snapshots in my home dir and uploads them to /srv/www.freedesktop.org/dri/snapshots/. No. This should be under /srv/dri.freedesktop.org/snapshots, not www.freedesktop.org. If it is under www.freedesktop.org, I'll gladly set up a redirect for you. There is no dri.freedesktop.org yet. I think there is no need for a redirect. The current place is already different from where it was before the break-in (used to be in ~dri/snapshots now it's in dri/snapshots). If you could setup a dri.freedesktop.org that would be great. Maybe we could move our Wiki from sourceforge to the new location. Ajax, are you reading this? What do you think about upgrading to a newer MoinMoin version with ACLs while we're at it. On a related note, is it safe to put up the old snapshots? There is no guarantee of their integrity unless they come from a backup made before the break-in. Probably not. Only reason we put up the old CVS was that I took a snapshot of the entire CVS repository as of 20041015 and had it on a couple of known-good machines. I removed the snapshots from the public place. They're still in /home/compromised/projects/dri/public_html/snapshots though. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] snapshots status
I just found http://www.freedesktop.org/dri/snapshots/. Now I wonder where I find this in the freedesktop.org filesystem. Is it /srv or /home/srv? Ah, I just saw it's the same thing with a bind mount from /home/srv to /srv. So I guess /srv is the path to use in scripts even it is ever moved to another file system. I'm going to set up a snapshot cron job in my freedesktop account that builds snapshots in my home dir and uploads them to /srv/www.freedesktop.org/dri/snapshots/. On a related note, is it safe to put up the old snapshots? There is no guarantee of their integrity unless they come from a backup made before the break-in. Regards, Felix Am Di, den 23.11.2004 schrieb Job Bob um 18:54: Hello. I want to get the latest dri snapshots from http://dri.freedesktop.org/~dri/snapshots, but that directory doesn't exist anymore. Is this due to the recent rebuild? If so, when will the snapshots be back up? -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Bad display on Radeon when DRI syncd w vblank
Am Do, den 18.11.2004 schrieb Kevin O'Brien um 8:03: I need to get a animated line drawing graphics package working on a Radeon 9000 without artifacts. Currently, I get remnants of the previous frame after glXSwapBuffers on large windows, 1024x768 for example. This results in a tearing effect on the screen. Pseudo code: glFinish(); glXSwapBuffers(dpy, win); glFinish(); PrintCurrentVerticalLine(); // reads current vline from Radeon chip The value reported by the code is approx. the scan line where the tearing occurs. This can also be demonstrated with glxgears by resizing the window to 1024x768 and moving the window up high enough so the title bar is mostly hidden. /etc/drirc has vblank_mode set to 3 for all apps, including glxgears. As a test application, I create a window and draw a vertical line where the x component increases by one each frame. If the window is small enough, there is no problem; large enough, it tears The portion of the previous frame is related to the size of the window. I've also tried setting vblank_mode to 0 and invoking: drm_wait_vblank_t ioctl_arg; glFinish(); ioctl_arg.request.type = _DRM_VBLANK_RELATIVE; ioctl_arg.request.sequence = 1; ioctl(fd, DRM_IOCTL_WAIT_VBLANK, ioctl_arg); glXSwapBuffers(dpy, win); glFinish(); PrintCurrentVerticalLine(); and the results are the same as before. My environment: Multiple computers Xorg 6.8.0-r1 (Gentoo) or XFree 4.3.99 (SuSE 9.1) Radeon Mobility 9000 M9 or Radeon Mobility 7500 M7 Desktop: 1024x768 16bit or 24bit Xorg/XFree w/ DRI/DRM or Xorg w/ ATI's proprietary driver. I don't see this effect when using an nVidia Corporation NV18 [GeForce4 MX] w/ nVidia's drivers. Unfortunately, I have to get a Radeon solution working. Any thoughts where to look for a solution, or why it is related to window size, would be greatly appreciated. There is a problem in the radeon driver WRT to waiting for the refresh. The driver can wait for the refresh but there is no guarantee that the next operation can take place immediately, because there may still be more commands pending in the command queue. Calling glFinish before glXSwapBuffers should normally fix this. If there is still visible tearing the only reason I could imagine is that the blit from back buffer to front buffer takes longer than the vertical retrace. In that case page flipping might solve your problem. Set 'Option EnablePageFlip true' in the Device section of xorg.conf or XF86Config[-4] respectively. Also make sure that interrupts are working. Does the radeon DRM show up in /proc/interrupts? TIA, Kevin O'Brien HTH, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Savage patches
Am Mo, den 15.11.2004 schrieb Daniel J. Michael um 7:52: Well, I got the latest cvs and patches again and tried them on my laptop (TwisterK). I don't remember if it's closer to a savage3d or a savage 4 off the top of my head. 2d seems to still be working fine. I also get over 100 more fps in glxgears. The downside is, I don't see the gears any more, just a black window. The same thing happens it tux racer, instead of showing graphics, it is all just one color. I also can't see the cursor when it's over an opengl window. Chromium is not all one color, but it is definitely not right either. 2d and xv seem to be working at least as well as before, and no instability at this point. TwisterK is based on Savage4, not Savage3D. So it is not supposed to work with these patches. Sorry. BTW, you can make them work by uncommenting #define FAKE_DMA in savageioctl.h. That will disable the non-functional (on Savage4-based cards) vertex DMA experiments. Though there shouldn't be much benefit as compared to the CVS version. To be more specific, the patches should work on Savage3D, Savage IX and Savage MX. I have tested them on a Savage IX here. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
New Savage patches
Hi Savage testers, I uploaded a new set of patches (*_20041114.diff) to http://freedesktop.org/~fxkuehl/savage/. These patches work for Savage3D-based cards only at this point. It will not show the expected results on Savage4-based cards and will most likely lock up. You have been warned. My latest experiments with Savage4 showed that the same approach (using vertex DMA for all rendering) won't work here. It will take major changes to get good support for Savage4 and later-on for Savage2000. Since this is likely to involve binary-incompatible interface changes I don't want to commit anything to CVS yet. However, I won't be able to do much work in the next two weeks, so here is the current state for people to play with. The patches are against CVS HEADs as of about 1 hour ago. Apply the patches in the respective root directories of the DRM, Mesa and X.org source trees. This time they should include all changes needed for compiling. No hand-editing should be needed. Features: * vertex DMA - slight performance improvement * the ShadowStatus option in xorg.conf now also applies to 3D rendering * all access to the hardware is done by the kernel. This is the basis for a secure driver that can be included in X.org, Mesa and kernel releases. It also fixes a couple of bugs. It has been very stable on my Savage IX here as far as I tested it (quakeforge, quake2, q3demo, torcs, fgfs). Neverball has some serious texture mapping problems. I'm not sure if this is a new problem (didn't try with the CVS version of the driver on Savage IX). I'm not aware of any (other) regressions. Happy testing, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Userspace pointers in DRM ioctl structs?
Hi, in the Savage driver I will have to pass vertex data to the kernel. On Savage3D/IX/MX I have worked out how to do real vertex DMA, so this is no problem. On Savage4 the vertex DMA engine can't cope with all vertex formats, so I need to used drawing commands with inline vertex data sometimes. So I see two choices for how to get the vertex data from user space to the kernel: * shared memory buffers created by the Xserver advantages: * as long as I don't use command DMA it avoids one extra copy disadvantages: * limited number of buffers * static allocation at xserver startup * copy from user advantages: * dynamic memory allocation (at client startup) disadvantages: * extra copy if I don't use command DMA (need to use memcpy_mmio which doesn't exist as copy_from_user) Since I'm going to implement command DMA on Savage4 eventually, I'd prefer the copy from user method. However, I remember reading about 64-bit issues with user pointers in data structures passed between kernel and user-space. Is there any 64-bit clean way of copying a vertex buffer from user-space. I guess the only way would be to pass the pointer directly as ioctl argument. Then all extra information (like vertex format and number of vertices) would have to be in a header of that vertex buffer. Am I on the right track so far? Thanks, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: r300 Report.]
Am So, den 07.11.2004 schrieb Ben Skeggs um 2:01: As long as the X server works and uses the ring buffer, that would point towards a simple configuration problem. Perhaps you could post a log of glxinfo with LIBGL_DEBUG=all and RADEON_DEBUG=all? cu, Nicolai Hmm, I believe you may be right about the config problem, I'm not sure why I didn't think of running glxinfo with LIBGL_DEBUG=all before.. [EMAIL PROTECTED] ~ $ LIBGL_DEBUG=all glxinfo name of display: :0.0 libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed (/usr/X11R6/lib/modules/dri/r300_dri.so: undefined symbol: XML_SetElementHandler) libGL error: unable to find driver: r300_dri.so --snip-- I'll have a mess around and try to find out what's going on there. Looks like a libexpat problem. It's not complaining that it doesn't find libexpat, maybe your version is too old? Is libexpat listed by ldd r300_dri.so? Ben. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI
Am Fr, den 05.11.2004 schrieb aurynn um 3:17: Hi, Felix; Well, to be honest, the only other board I have that's DRI-supported is a legacy Voodoo5, and I've been told that programming Glide is a right pain to do. The nVidia stuff doesn't have documentation, and I'm loathe to interrupt my productivity for such a long period to get Linux/FreeBSD running on my main PC with the Radeon 9000 card. About all else I can think of kicking around is the Rendition V2100 card. So, since I do want to start hacking on the DRI, where should I start? The savage2000 is what I'd like to use to start, since it's the only card I can really say that I can't use, even though it's a very nice card. Do you have the sources already and have you compiled them. If not that's the first hurdle for new developers. ;-) Once you've done that, there are some patches of stuff that I'm working on now (freedesktop.org/~fxkuehl/savage). With them applied you'll get a better idea of what the driver is going to look soon. Note that you need a few more changes for it to compile. See the mailing list archives for details. I'm CC-ing to the dri-devel mailing list. This is where DRI developers discuss problems and ideas. You should subscribe to it and maybe mesa3d-dev and the xorg mailing list. Thanks! Aurynn Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch] Re: Making reclaim_buffers OS-independent
A patch is attached. It changes both linux/linux-2.6 and linux-core. I
tested that it compiles (linux-2.6 and linux-core) and loads all modules
(except radeon, which failed because I don't have the necessary i2c bits
in my kernel). Any objections to applying this?
Regards,
Felix
Am Sa, den 30.10.2004 schrieb Felix Kühling um 23:56:
Currenly in linux-core the driver callback reclaim_buffers is called
with a single argument filp. In reclaim_buffers you need OS-specific
knowledge to extract the device pointer from the filp. In the BSD DRM
reclaim_buffers takes two arguments, dev and filp. Could we change
the linux version to use the same API? This would allow implementing an
OS-agnostic reclaim_buffers function in a driver.
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: linux/drmP.h
===
RCS file: /cvs/dri/drm/linux/drmP.h,v
retrieving revision 1.123
diff -u -r1.123 drmP.h
--- linux/drmP.h 9 Oct 2004 10:58:19 - 1.123
+++ linux/drmP.h 31 Oct 2004 10:20:46 -
@@ -528,7 +528,7 @@
void (*irq_preinstall)(struct drm_device *dev);
void (*irq_postinstall)(struct drm_device *dev);
void (*irq_uninstall)(struct drm_device *dev);
- void (*reclaim_buffers)(struct file *filp);
+ void (*reclaim_buffers)(struct drm_device *dev, struct file *filp);
unsigned long (*get_map_ofs)(drm_map_t *map);
unsigned long (*get_reg_ofs)(struct drm_device *dev);
void (*set_version)(struct drm_device *dev, drm_set_version_t *sv);
@@ -870,7 +870,7 @@
extern int DRM(dma_setup)(drm_device_t *dev);
extern void DRM(dma_takedown)(drm_device_t *dev);
extern void DRM(free_buffer)(drm_device_t *dev, drm_buf_t *buf);
-extern void DRM(reclaim_buffers)( struct file *filp );
+extern void DRM(core_reclaim_buffers)(drm_device_t *dev, struct file *filp);
/* IRQ support (drm_irq.h) */
extern int DRM(control)( struct inode *inode, struct file *filp,
Index: linux/drm_dma.h
===
RCS file: /cvs/dri/drm/linux/drm_dma.h,v
retrieving revision 1.34
diff -u -r1.34 drm_dma.h
--- linux/drm_dma.h 5 Sep 2004 10:54:58 - 1.34
+++ linux/drm_dma.h 31 Oct 2004 10:20:46 -
@@ -154,10 +154,8 @@
*
* Frees each buffer associated with \p filp not already on the hardware.
*/
-void DRM(core_reclaim_buffers)( struct file *filp )
+void DRM(core_reclaim_buffers)( drm_device_t *dev, struct file *filp )
{
- drm_file_t*priv = filp-private_data;
- drm_device_t *dev= priv-dev;
drm_device_dma_t *dma = dev-dma;
int i;
Index: linux/drm_drv.h
===
RCS file: /cvs/dri/drm/linux/drm_drv.h,v
retrieving revision 1.91
diff -u -r1.91 drm_drv.h
--- linux/drm_drv.h 8 Oct 2004 14:31:24 - 1.91
+++ linux/drm_drv.h 31 Oct 2004 10:20:56 -
@@ -857,7 +857,7 @@
if (drm_core_check_feature(dev, DRIVER_HAVE_DMA))
{
- dev-fn_tbl.reclaim_buffers(filp);
+ dev-fn_tbl.reclaim_buffers(dev, filp);
}
DRM(fasync)( -1, filp, 0 );
Index: linux/i810_dma.c
===
RCS file: /cvs/dri/drm/linux/i810_dma.c,v
retrieving revision 1.68
diff -u -r1.68 i810_dma.c
--- linux/i810_dma.c 23 Sep 2004 05:39:13 - 1.68
+++ linux/i810_dma.c 31 Oct 2004 10:20:56 -
@@ -996,10 +996,8 @@
}
/* Must be called with the lock held */
-void i810_reclaim_buffers(struct file *filp)
+void i810_reclaim_buffers(drm_device_t *dev, struct file *filp)
{
- drm_file_t*priv = filp-private_data;
- drm_device_t *dev= priv-dev;
drm_device_dma_t *dma = dev-dma;
int i;
@@ -1395,7 +1393,7 @@
static void i810_driver_release(drm_device_t *dev, struct file *filp)
{
- i810_reclaim_buffers(filp);
+ i810_reclaim_buffers(dev, filp);
}
static int i810_driver_dma_quiescent(drm_device_t *dev)
Index: linux/i810_drv.h
===
RCS file: /cvs/dri/drm/linux/i810_drv.h,v
retrieving revision 1.21
diff -u -r1.21 i810_drv.h
--- linux/i810_drv.h 17 Aug 2004 13:10:04 - 1.21
+++ linux/i810_drv.h 31 Oct 2004 10:20:57 -
@@ -99,7 +99,7 @@
extern int i810_dma_cleanup(drm_device_t *dev);
extern int i810_flush_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern void i810_reclaim_buffers(struct file *filp);
+extern void i810_reclaim_buffers(drm_device_t *dev, struct file *filp);
extern int i810_getage(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
extern int i810_mmap_buffers(struct file *filp, struct vm_area_struct *vma);
Index: linux/i830_dma.c
===
RCS file: /cvs/dri/drm/linux/i830_dma.c,v
retrieving revision 1.33
diff -u -r1.33
Re: Problems with compiling new savage patch.
Am Sa, den 30.10.2004 schrieb Daniel J. Michael um 0:51: You are correct about the unresolved symbols, they seem to happen with the cvs code also (but I think they must be new in the last couple of weeks sometime). Here is the output of my LIBGL_DEBUG=verbose glxinfo: [EMAIL PROTECTED] ~ $ LIBGL_DEBUG=verbose glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 1.1.27 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (/usr/X11R6/lib/modules/dri/savage_dri.so: undefined symbol: _mesa_DeleteObjectARB) libGL error: unable to find driver: savage_dri.so This also looks like it's not my fault. There was some breakage in recent Mesa CVS. Either try the latest CVS or maybe a version from 1 or 2 weeks ago. I'm going to avoid updating my copy of Mesa from CVS until the dust has settled a little. [snip] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Observations about DMA buffers and freelist management
Hello, I'm looking into the management of DMA buffers in the Savage driver now. I took a look at the Radeon and MGA drivers. They take very different approaches to the problem. Radeon searches all buffers to find one that is free while MGA has its own list of free buffers from which it always takes the first (oldest) one. A problem I see with the MGA driver is that when a client dies its DMA buffer(s) are not returned to the freelist. At least I couldn't see where that would happen. It looks like there is a driver callback reclaim_buffers that is supposed to do this. However, all drivers use the default implementation drm_core_reclaim_buffers here. I suppose the MGA driver should supply its own function that calls drm_core_reclaim_buffers and puts all reclaimed buffers back on its freelist. The use of the buf-list looks a bit fishy to me. Grep shows that the only place where it is ever set is in drm_core_reclaim_buffers. Is this still used or is it just bit rot? What about buf-next. This seems to be unused too, at least in the common code. Maybe some drivers use it? Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Making reclaim_buffers OS-independent
Currenly in linux-core the driver callback reclaim_buffers is called with a single argument filp. In reclaim_buffers you need OS-specific knowledge to extract the device pointer from the filp. In the BSD DRM reclaim_buffers takes two arguments, dev and filp. Could we change the linux version to use the same API? This would allow implementing an OS-agnostic reclaim_buffers function in a driver. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problems with compiling new savage patch.
Am Do, den 28.10.2004 schrieb Daniel J. Michael um 16:56: Well, it seemed to install fine, but direct rendering is disabled. I also get this error in my Xorg.0.log: Symbol SavageInitStreamsNew from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol SavageInitStreams2000 from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol SavageInitStreamsOld from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Not sure about them, but I doubt they are related to my changes. [EMAIL PROTECTED] ~ $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No Direct rendering is disabled for some reason. Run (in bash) LIBGL_DEBUG=verbose glxinfo to get more information what's going wrong. [snip] [Xorg.0.log ...] (II) SAVAGE(0): [junkers] status:handle:0x (II) SAVAGE(0): [junkers] status:offset:0x (II) SAVAGE(0): [junkers] status:size:0x (II) SAVAGE(0): [junkers] status:map:0x (II) SAVAGE(0): [junkers] sarea_priv_offset:0x0898 (II) SAVAGE(0): Direct rendering enabled This looks ok. The Xserver and 2D driver initialized ok with DRI support enabled. It's something with libGL or the 3D driver. LIBGL_DEBUG=verbose should tell what's going wrong. [snip] -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problems with compiling new savage patch.
Am Fr, den 29.10.2004 schrieb Sérgio M. Basto um 13:04: On Thu, 2004-10-28 at 18:58, Sérgio M. Basto wrote: Hi, Felix I had also problem to compile your patches and after check and recheck if isn't my fault, I get the conclusion that I can compile mesa with make in /opt/trunk/Mesa, but can't compile it if I try compile from xorg cvs ( with extra/Mesa linked to /opt/trunk/Mesa). Reading the wiki pages, you suggest that compiles xorg in one side and mesa in other side. With make linux-x86-dri and install mesa over mesa of xorg this is correct ? if this is possible, Mesa compilation doesn't not depend on X, this could be a great new, because we can begging build Xorg tree without any Mesa sources, and compile Mesa as standalone . Yes, that's how it works now. We can't fix the Xorg tree to compile with the latest Mesa source since that would break the build of the Mesa version that is included in the Xorg tree. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Two module_param problems with Linux 2.6.4
Two small problems I had with Linux 2.6.4: 1. In order to make drm_stub.c compile without errors I had to #include linux/moduleparam explicitly. 2. drm_compat.h defines an empty module_param if it's undefined. It should do the same for module_param_named. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Wiki Spam
Am Mi, den 27.10.2004 schrieb Adam Jackson um 21:46: On Wednesday 27 October 2004 14:49, Alan Swanson wrote: Until someone has the time to upgrade the Wiki to a newer version with anti-spam features could we at least block any commits which don't have comments? Just that none of the spam commits ever have comments, plus it would make tracking changes easier. I'm tempted to just turn off all updates for the moment. I attempted to use one of the antispam scripts for moinmoin but it made everything return with 500 errors. #moin thinks we're insane for using such an old version. The pages themselves should be compatible with the newer versions so we may want to upgrade. The problem seems to be that there's a different version of python in use depending on whether you're on the web server or the shell server. Can someone with more sourceforge-fu than myself clarify the situation? Last thing I heard of it was that the web server uses a ridiculously old python version. One thought that occurred to me was to move the Wiki to fd.o. We don't have to use the fd.o wiki system (Tiki AFAIK) but we could use a local MoinMoin installation in ~dri. The sf.net page could automatically forward to it. Newer MoinMoin versions support user authentication which should put a stop to Wiki spam. Another problem is that José Fonseca made some modifications to MoinMoin that would have to be ported to the new version. I'm not sure what those changes are. José, are you reading this? - ajax -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Savage work
Hi all, I have uploaded patches against the Savage Mesa driver, 2D driver and DRM to http://freedesktop.org/~fxkuehl/savage. This is the current state of my work on the savage driver. It breaks binary compatibility and I'm not sure I'm done doing so. That's why I'm still not committing it. It is the start of a real DRM driver for Savage that features three ioctls so far, init, clear and event. The last one is used for emitting and waiting for events with a centrally managed event counter. This is already used by the patched Mesa driver for frame throttling. Later the same event counter will be used for buffer aging. The patches should work out of the box, except you have to edit mesa/src/mesa/drivers/dri/Makefile.template to use drm/linux-core and drm/shared-core instead of drm/linux and drm/shared. There are also some fixes and cleanups (besides other messups ;-) in there that I meant to commit separately, before the big binary incompatible checkin. But I ran out of time. I won't be around for about a week. So I wanted whatever I have so far out there for people to look at or event try :-P. Cu in a week Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Kernel Oops in drm_set_version
I noticed some kernel oopses in DRM in my kernel log. They don't seem to be fatal as DRI is still working. This is on a machine with Vesa framebuffer. On the other box without kernel framebuffer there are no oopses. Oct 19 18:30:31 trabant kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Oct 19 18:30:31 trabant kernel: [drm] Used old pci detect: framebuffer loaded Oct 19 18:30:31 trabant kernel: Unable to handle kernel paging request at virtual address f000e2c3 Oct 19 18:30:31 trabant kernel: printing eip: Oct 19 18:30:31 trabant kernel: cfdb2af0 Oct 19 18:30:31 trabant kernel: *pde = Oct 19 18:30:31 trabant kernel: Oops: [#1] Oct 19 18:30:31 trabant kernel: Modules linked in: savage drm ipv6 parport_pc lp parport snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd soundcore via_ircc ohci1394 ieee1394 joydev usbhid via_rhine mii ehci_hcd uhci_hcd usbcore via_agp agpgart Oct 19 18:30:31 trabant kernel: CPU:0 Oct 19 18:30:31 trabant kernel: EIP:0060:[pg0+261954288/1069666304]Not tainted Oct 19 18:30:31 trabant kernel: EFLAGS: 00013292 (2.6.8) Oct 19 18:30:31 trabant kernel: EIP is at drm_set_busid+0x90/0xf0 [drm] Oct 19 18:30:31 trabant kernel: eax: ebx: c9439800 ecx: edx: cfdb749c Oct 19 18:30:31 trabant kernel: esi: edi: f000e2c3 ebp: cdd25860 esp: cbd7ff08 Oct 19 18:30:31 trabant kernel: ds: 007b es: 007b ss: 0068 Oct 19 18:30:31 trabant kernel: Process Xorg (pid: 1915, threadinfo=cbd7e000 task=cea58c90) Oct 19 18:30:31 trabant kernel: Stack: cd810b20 0014 cfdb7487 0001 ba80 Oct 19 18:30:31 trabant kernel:c9439800 cbd7ff44 cfdb2e85 0001 0002 0001 0001 Oct 19 18:30:31 trabant kernel:0001 c9439800 0001 cfdb2de0 cfdb1c55 ba80 Oct 19 18:30:31 trabant kernel: Call Trace: Oct 19 18:30:31 trabant kernel: [pg0+261955205/1069666304] drm_setversion+0xa5/0xf0 [drm] Oct 19 18:30:31 trabant kernel: [pg0+261955040/1069666304] drm_setversion+0x0/0xf0 [drm] Oct 19 18:30:31 trabant kernel: [pg0+261950549/1069666304] drm_ioctl+0xe5/0x1ae [drm] Oct 19 18:30:31 trabant kernel: [do_int+167/592] do_int+0xa7/0x250 Oct 19 18:30:31 trabant kernel: [do_int+167/592] do_int+0xa7/0x250 Oct 19 18:30:31 trabant kernel: [sys_ioctl+175/496] sys_ioctl+0xaf/0x1f0 Oct 19 18:30:31 trabant kernel: [syscall_call+7/11] syscall_call+0x7/0xb Oct 19 18:30:31 trabant kernel: [do_int+167/592] do_int+0xa7/0x250 Oct 19 18:30:31 trabant kernel: Code: f2 ae f7 d1 49 03 4b 04 ba d0 00 00 00 8d 41 02 e8 7b 23 38 HTH, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oops in drm_set_version
Am Di, den 19.10.2004 schrieb Jon Smirl um 20:11:
The fault is in drm_set_busid. It's a NULL pointer reference. I'm not
seeing this so it may be savage specific. The only place I can see
where you could get a NULL reference is if the PCI driver didn't set a
name, dev-pdev-driver-name. Can you add a debug statement and check
if there is one? The trap looks like it is in a sprintf.
I added these debug statements:
printk(KERN_ERR dev = %p\n, dev);
printk(KERN_ERR dev-pdev = %p\n, dev-pdev);
printk(KERN_ERR dev-pdev-driver = %p\n, dev-pdev-driver);
printk(KERN_ERR dev-pdev-driver-name = %p\n, dev-pdev-driver-name);
This is the output:
dev = c9438800
dev-pdev = cee8c400
dev-pdev-driver =
dev-pdev-driver-name = f000e2c3
Funny thing is that it doesn't complain about the NULL-pointer
reference. It complains about:
Unable to handle kernel paging request at virtual address f000e2c3
The real problem is that dev-pdev-driver is NULL.
drm_set_busid is called if the minor interface version is = 1. This
interface version is requested by the common DRI code in the Xserver.
This in turn depends on the available libdrm version (quoting
xc/programs/Xserver/GL/dri/dri.c):
if (drmlibmajor == 1 drmlibminor = 2) {
drmSetVersion sv;
/* Get the interface version, asking for 1.1. */
sv.drm_di_major = 1;
sv.drm_di_minor = 1;
sv.drm_dd_major = -1;
err = drmSetInterfaceVersion(pDRIPriv-drmFD, sv);
if (err == 0) {
drmdimajor = sv.drm_di_major;
drmdiminor = sv.drm_di_minor;
} else {
/* failure, so set it to 1.0.0. */
drmdimajor = 1;
drmdiminor = 0;
}
}
else {
/* We can't check the DI DRM interface version, so set it to 1.0.0. */
drmdimajor = 1;
drmdiminor = 0;
}
Are you using an up-to-date libdrm for testing?
BTW, I noticed one small thing in drm_set_version that looks like a
typo:
if_version = DRM_IF_VERSION(sv.drm_di_major, sv.drm_dd_minor);
-^ -^
Does it make sense to mix driver and interface versions? Shouldn't it
be:
if_version = DRM_IF_VERSION(sv.drm_di_major, sv.drm_di_minor);
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?
Am Mi, den 13.10.2004 schrieb Michel Dänzer um 22:57: On Wed, 2004-10-13 at 19:42 +0200, Felix Kühling wrote: Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53: I just changed DRM to alternative between zero and POLLIN This will make the DRM poll() function work like the kernel expects it to and still work with existing X servers. Can someone please get this incorrect code out of the X server? As I mentioned earlier, setting driverSwapMethod to DRI_KERNEL_SWAP seems to work for the savage driver. I bet it works for many others too. AFAICT this tells the common DRI code not to use the DRM file handle. Once this is proven to work with all drivers we could axe the code for the other methods. I doubt it's that simple, e.g. the DDX driver's SwapContext() function is only called with DRI_HIDE_X_CONTEXT AFAICT. [slowly starting to make sense of all this ...] Right. The default Block and Wakeup handlers only call SwapContext if DRI_HIDE_X_CONTEXT is set. But a driver can install its own Block and Wakeup handlers. I think that's what I'm going to do for the Savage driver. I believe it should work for Radeon (for example) too. The custom handlers would lock/unlock and call RADEONEnterServer or RADEONLeaveServer respectively. If I understand Keith correctly then all the modern drivers don't use the SIGIO method (kernel notifies Xserver of context switches) any more. So there is really no need for the full HIDE_X_CONTEXT+SERVER_SWAP overhead. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] New mapping type _DRM_CONSISTENT
Am Sa, den 16.10.2004 schrieb Jon Smirl um 3:22: [snip] --- programs/Xserver/hw/xfree86/os-support/xf86drm.h.~1.3.~ 2004-06-16 11:39:14.0 +0200 +++ programs/Xserver/hw/xfree86/os-support/xf86drm.h2004-10-16 02:00:35.0 +0200 @@ -104,7 +104,8 @@ DRM_REGISTERS = 1, /** no caching, no core dump */ DRM_SHM = 2, /** shared, cached */ DRM_AGP = 3, /** AGP/GART */ -DRM_SCATTER_GATHER = 4 /** PCI scatter/gather */ +DRM_SCATTER_GATHER = 4, /** PCI scatter/gather */ +DRM_CONSISTENT = 5 /** PCI consistent */ } drmMapType; Isn't xf86drm.h supposed to live in drm/libdrm? Or has that been converted yet? There seem to be two copies of it floating around in the Xorg tree. The header file that gets used (in the Savage driver) is definitely the one in os-support. When I commit this I'm going to change both. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] New mapping type _DRM_CONSISTENT
Am So, den 17.10.2004 schrieb Jon Smirl um 0:30: On Sun, 17 Oct 2004 00:27:02 +0200, Felix Kühling [EMAIL PROTECTED] wrote: Isn't xf86drm.h supposed to live in drm/libdrm? Or has that been converted yet? There seem to be two copies of it floating around in the Xorg tree. The header file that gets used (in the Savage driver) is definitely the one in os-support. When I commit this I'm going to change both. Are you going to remove the copies is in the xorg tree? I hate having copies of things around. It's a sure path to bugs when one gets patches and another doesn't. I'm in no position to remove anything from the Xorg tree. I'm CCing to [EMAIL PROTECTED] Can anyone there shed some light on the status if libdrm? Background: there is the (supposedly new) libdrm in extras/drm/libdrm and there are copies of (mostly) the same files on programs/Xserver/hw/xfree86/os-support. Is one of the copies going to be removed? Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to get the physical address of a DRM_SHM map
Am Fr, den 15.10.2004 schrieb Vladimir Dergachev um 5:27: On Fri, 15 Oct 2004, Felix [ISO-8859-1] Kühling wrote: Am Fr, den 15.10.2004 schrieb Jon Smirl um 3:58: On Fri, 15 Oct 2004 03:55:37 +0200, Felix Kühling [EMAIL PROTECTED] wrote: I'm trying to get Shadow status working in the savage driver. I'd like to put the status page into locked shared memory and tell the Savage chips about its physical address. I used a drmAddMap call copied from the MGA driver that looked like it did what I wanted. But I had to find out that the handle returned by drmAddMap is a kernel virtual address, not a physical address. Later I saw that the status page seems to be unused in the MGA driver. The code to get the physical address from the kernel virtual address is #if-ed out, probably for portability reasons. Does the code in drm_pci.c apply? It's only used by the via driver. I'm not sure what it does. I guess if I was only going to use that memory in kernel drm_pci_alloc would be fine. But I want to map the status page at least in the Xserver, maybe also in clients. Take a look at km or v4l drivers - maybe there is something you can use. With 2.4 I used rvmalloc - I don't recall whether there is a standard mechanism for this in 2.6. The point is that I'm not just looking for a way to get a physical address in Linux. In that case I'd just use virt_to_bus on the map handle. Since I only need a single page I also don't need to worry about allocating consistent memory. However, I want to use the mechanisms available in the DRM abstraction layer so that the savage driver stays (at least theoretically) portable to BSD and so that I can use drmMap/drmMapBufs to map the status page in the Xserver and/or in DRI clients. best Vladimir Dergachev Thanks, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to get the physical address of a DRM_SHM map
Am Fr, den 15.10.2004 schrieb Keith Whitwell um 15:50: Felix Kühling wrote: Am Fr, den 15.10.2004 schrieb Vladimir Dergachev um 5:27: On Fri, 15 Oct 2004, Felix [ISO-8859-1] Kühling wrote: Am Fr, den 15.10.2004 schrieb Jon Smirl um 3:58: On Fri, 15 Oct 2004 03:55:37 +0200, Felix Kühling [EMAIL PROTECTED] wrote: I'm trying to get Shadow status working in the savage driver. I'd like to put the status page into locked shared memory and tell the Savage chips about its physical address. I used a drmAddMap call copied from the MGA driver that looked like it did what I wanted. But I had to find out that the handle returned by drmAddMap is a kernel virtual address, not a physical address. Later I saw that the status page seems to be unused in the MGA driver. The code to get the physical address from the kernel virtual address is #if-ed out, probably for portability reasons. Does the code in drm_pci.c apply? It's only used by the via driver. I'm not sure what it does. I guess if I was only going to use that memory in kernel drm_pci_alloc would be fine. But I want to map the status page at least in the Xserver, maybe also in clients. Take a look at km or v4l drivers - maybe there is something you can use. With 2.4 I used rvmalloc - I don't recall whether there is a standard mechanism for this in 2.6. The point is that I'm not just looking for a way to get a physical address in Linux. In that case I'd just use virt_to_bus on the map handle. Since I only need a single page I also don't need to worry about allocating consistent memory. However, I want to use the mechanisms available in the DRM abstraction layer so that the savage driver stays (at least theoretically) portable to BSD and so that I can use drmMap/drmMapBufs to map the status page in the Xserver and/or in DRI clients. I'm not sure that such a mechanism exists. If it doesn't, I think the onus falls on the porter to provide one, if a port is ever attempted. I see two alternatives for providing what I need. 1. A new map type _DRM_PCI (or _DRM_CONSISTENT if you prefer that in contrast to _DRM_SCATTER_GATHER) that allocates pages with drm_alloc_pages and returns the physical address as handle. 2. A new map flag for the _DRM_SHM map type, say _DRM_CONSISTENT that makes it allocate with drm_alloc_pages and return the physical address as handle. I think the first one sounds cleaner. If we can agree on this I'd prepare a patch for the linux-core implementation and the corresponding headers in Xorg for review.(*) When BSD gets ported to the core/personality model it would need to get the new PCI map type too in order to support any drivers that use it. Keith Regards, Felix (*) In fact I'm starting right now. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch] New mapping type _DRM_CONSISTENT
The attached patch adds a new mapping type _DRM_CONSISTENT. It works
basically like shared memory but allocates consistent memory and returns
the physical address to user space as handle. I wouldn't be surprised if
I missed something, but it works for me. I'm typing this in an X session
with the Savage 2D driver with shadow status, where the status page is a
_DRM_CONSISTENT mapping.
Best regards,
Felix
P.S.: The patch for Xorg is basically a one-liner (for completeness):
--- programs/Xserver/hw/xfree86/os-support/xf86drm.h.~1.3.~
2004-06-16 11:39:14.0 +0200
+++ programs/Xserver/hw/xfree86/os-support/xf86drm.h2004-10-16
02:00:35.0 +0200
@@ -104,7 +104,8 @@
DRM_REGISTERS = 1, /** no caching, no core dump */
DRM_SHM = 2, /** shared, cached */
DRM_AGP = 3, /** AGP/GART */
-DRM_SCATTER_GATHER = 4 /** PCI scatter/gather */
+DRM_SCATTER_GATHER = 4, /** PCI scatter/gather */
+DRM_CONSISTENT = 5 /** PCI consistent */
} drmMapType;
typedef enum {
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- linux-core/drm_bufs.c.~1.50.~ 2004-10-13 23:01:50.0 +0200
+++ linux-core/drm_bufs.c 2004-10-16 01:56:25.0 +0200
@@ -244,7 +244,21 @@
}
map-offset += dev-sg-handle;
break;
-
+ case _DRM_CONSISTENT: {
+ int order, page_order;
+ order = drm_order(map-size);
+ page_order = order - PAGE_SHIFT 0 ? order - PAGE_SHIFT : 0;
+ map-size = PAGE_SIZE page_order;
+ map-handle = (void *)drm_alloc_pages(page_order, DRM_MEM_DMA);
+ DRM_DEBUG(%lu %d %d %p\n,
+ map-size, order, page_order, map-handle);
+ if (!map-handle) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -ENOMEM;
+ }
+ map-offset = virt_to_bus(map-handle);
+ break;
+ }
default:
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -EINVAL;
@@ -348,6 +362,11 @@
case _DRM_AGP:
case _DRM_SCATTER_GATHER:
break;
+ case _DRM_CONSISTENT:
+ drm_free_pages((unsigned long)map-handle,
+ drm_order(map-size)-PAGE_SHIFT,
+ DRM_MEM_DMA);
+ break;
}
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
}
--- linux-core/drm_drv.c.~1.98.~ 2004-10-13 23:01:50.0 +0200
+++ linux-core/drm_drv.c 2004-10-16 01:56:45.0 +0200
@@ -240,6 +240,12 @@
dev-sg = NULL;
}
break;
+case _DRM_CONSISTENT:
+ drm_free_pages(
+ (unsigned long)map-handle,
+ drm_order(map-size)-PAGE_SHIFT,
+ DRM_MEM_DMA);
+ break;
}
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
}
@@ -418,6 +424,7 @@
case _DRM_SHM:
case _DRM_AGP:
case _DRM_SCATTER_GATHER:
+case _DRM_CONSISTENT:
DRM_DEBUG(Extra maplist item\n);
break;
}
--- linux-core/drm_proc.c.~1.21.~ 2004-10-13 23:01:50.0 +0200
+++ linux-core/drm_proc.c 2004-10-16 02:09:34.0 +0200
@@ -211,9 +211,9 @@
struct list_head *list;
/* Hardcoded from _DRM_FRAME_BUFFER,
- _DRM_REGISTERS, _DRM_SHM, _DRM_AGP, and
- _DRM_SCATTER_GATHER. */
- const char *types[] = { FB, REG, SHM, AGP, SG };
+ _DRM_REGISTERS, _DRM_SHM, _DRM_AGP,
+ _DRM_SCATTER_GATHER, and _DRM_CONSISTENT. */
+ const char *types[] = { FB, REG, SHM, AGP, SG, PCI };
const char *type;
int i;
@@ -234,7 +234,7 @@
map = r_list-map;
if (!map)
continue;
- if (map-type 0 || map-type 4)
+ if (map-type 0 || map-type 5)
type = ??;
else
type = types[map-type];
--- linux-core/drm_vm.c.~1.44.~ 2004-10-13 23:01:50.0 +0200
+++ linux-core/drm_vm.c 2004-10-16 02:10:48.0 +0200
@@ -232,6 +232,11 @@
case _DRM_AGP:
case _DRM_SCATTER_GATHER:
break;
+ case _DRM_CONSISTENT:
+drm_free_pages((unsigned long)map-handle,
+ drm_order(map-size)-PAGE_SHIFT,
+ DRM_MEM_DMA);
+break;
}
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
}
@@ -658,6 +663,9 @@
vma-vm_ops = drm_vm_ops;
break;
case _DRM_SHM:
+ case _DRM_CONSISTENT:
+ /* Consistent memory is really like shared memory. It's only
+ * allocated in a different way. */
vma-vm_ops = drm_vm_shm_ops;
vma-vm_private_data = (void *)map;
/* Don't let this area swap. Change when
--- shared-core/drm.h.~1.59.~ 2004-09-30 23:38:48.0 +0200
+++ shared-core/drm.h 2004-10-16 01:46:00.0 +0200
@@ -246,7 +246,8 @@
_DRM_REGISTERS = 1, /** no caching, no core dump */
_DRM_SHM = 2, /** shared, cached */
_DRM_AGP = 3, /** AGP/GART */
- _DRM_SCATTER_GATHER = 4 /** Scatter/gather memory for PCI DMA */
+ _DRM_SCATTER_GATHER = 4, /** Scatter/gather memory for PCI DMA */
+ _DRM_CONSISTENT = 5 /** Consistent memory for PCI DMA */
} drm_map_type_t;
/**
Re: libGL cannot open savage_dri.so
On Wed, 13 Oct 2004 01:47:27 +0200 Felix Kühling [EMAIL PROTECTED] wrote: [snip] I need to make sure that libexpat is compiled in statically. This was the case with the old XFree86-based snapshots. Somehow I must have screwed up with the new ones. Hang on, this should be fixed tomorrow or the day after. Until then try Alex's suggestion (symlink). Today's snapshot (available in about 3 hours) should be fixed. Cheers, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Building page on wiki
Am Do, den 14.10.2004 schrieb Patrick McFarland um 6:51: http://dri.sourceforge.net/cgi-bin/moin.cgi/Building mentions a buildtools.patch, is this still required for xorg cvs? It's only needed if you want to compile the latest versions of glxgears, glxinfo and xdriinfo while not building any other X clients (BuildServersOnly). Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch] drm_core_getmap
In the savage driver I'm going to use permanent maps from the start. So
there is no need for the Xserver to pass the permanent maps back to the
kernel driver in the init ioctl. Instead I want to find the maps by
index in the init ioctl. Therefore I added a drm_core_getmap inline
function similar to drm_core_findmap. Jon, if you like this please apply
to drm/linux-core.
Thanks,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
--- ./drmP.h.~1.133.~ 2004-10-13 23:01:50.0 +0200
+++ ./drmP.h 2004-10-14 16:29:05.0 +0200
@@ -997,6 +997,20 @@
return NULL;
}
+static __inline__ struct drm_map *drm_core_getmap(struct drm_device *dev,
+ unsigned int idx)
+{
+ struct list_head *_list;
+ int i = 0;
+ list_for_each(_list, dev-maplist-head) {
+ if (i == idx) {
+ return list_entry(_list, drm_map_list_t, head)-map;
+ }
+ i++;
+ }
+ return NULL;
+}
+
static __inline__ void drm_core_dropmap(struct drm_map *map)
{
}
Re: [patch] drm_core_getmap
Am Do, den 14.10.2004 schrieb Jon Smirl um 18:38: I did it like this at startup time: /* registers */ if ((ret = drm_initmap(dev, pci_resource_start(dev-pdev, 2), pci_resource_len(dev-pdev, 2), _DRM_REGISTERS, 0))) return ret; if (!(dev_priv-mmio = drm_core_findmap(dev, pci_resource_start(dev-pdev, 2 return DRM_ERR(ENOMEM); Ok, I guess that would work for me too. I haven't checked out the code enough to be sure that getting a map by index number will always return the right map. What about the getmap ioctl? You may be right though, that one might get unexpected results. AFAICT maps are added at the head of the list. So the order is reversed and maps added by the Xserver mess up the indices. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm-core and snapshots
Am Fr, den 15.10.2004 schrieb Jon Smirl um 3:39: Is drm-core being included in the current snapshots? Is it time yet to remove the linux-2.6 drm directory and push more people towards testing drm-core? Reported problems against drm-core are getting more obscure now. Snapshots are still built with linux-2.6. When we really make the change to the linux-core stuff we'll also have to update the path drm/shared to drm/shared-core in the Mesa makefiles so they always build against the latest driver-specific drm includes. I think Xorg doesn't need to be updated until they update their Mesa version. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
How to get the physical address of a DRM_SHM map
I'm trying to get Shadow status working in the savage driver. I'd like to put the status page into locked shared memory and tell the Savage chips about its physical address. I used a drmAddMap call copied from the MGA driver that looked like it did what I wanted. But I had to find out that the handle returned by drmAddMap is a kernel virtual address, not a physical address. Later I saw that the status page seems to be unused in the MGA driver. The code to get the physical address from the kernel virtual address is #if-ed out, probably for portability reasons. It looks like drmAddBufs with count one and size PAGE_SIZE would be a way to get what I want. Though it's probably not what this interface was meant for. Does anyone want to talk me out of it before I start coding? ;-) Thanks for any insight, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
How to enable DRM debug output?
Either I'm to stupid for it or the debug parameter of the drm module is not working correctly. modinfo drm shows that there should be a debug parameter. But when I pass it to modprobe I get an error message: drm: Unknown parameter `debug' and the module refuses to load. With the linux-2.6 savage driver I have a similar problem. It also complains about the unknown parameter, but it loads anyway (with debug output disabled). -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm-core and snapshots
Am Fr, den 15.10.2004 schrieb Jon Smirl um 3:56: On Fri, 15 Oct 2004 03:52:39 +0200, Felix Kühling [EMAIL PROTECTED] wrote: Snapshots are still built with linux-2.6. When we really make the change to the linux-core stuff we'll also have to update the path drm/shared to drm/shared-core in the Mesa makefiles so they always build against the latest driver-specific drm includes. I think Xorg doesn't need to be updated until they update their Mesa version. Are things stable enough to do the swtich next week? We can always switch it back if there are problems. I can fix the mesa makefiles when everything else is ready. It's been pretty stable for me the last two days. I can't tell for sure though, whether it's because of your poll change or because I changed the swapMethod to SWAP_KERNEL locally. Could we alter the snapshot scripts to start including drm-core/shared-core? Why don't the scripts just include the whole drm tree, it's not very large. That's true. But since the kernel driver is built by the installation script I don't need to include anything that is not use by the script. When there was only a single linux DRM the snapshots included a single flat directory with both the linux and shared files. When linux and linux-2.6 were split I decided to package shared, linux and linux-2.6 in separate directories so that shared files would not be duplicated. Now that linux and linux-core use different shared directories I could build two flat directories linux (from linux and shared) and linux-2.6 (from shared-core and linux-core) in the snapshots without duplicating anything. Keeping the old name linux-2.6 I don't need to change the install script and it's clearer to curious users what these directories are good for. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to get the physical address of a DRM_SHM map
Am Fr, den 15.10.2004 schrieb Jon Smirl um 3:58: On Fri, 15 Oct 2004 03:55:37 +0200, Felix Kühling [EMAIL PROTECTED] wrote: I'm trying to get Shadow status working in the savage driver. I'd like to put the status page into locked shared memory and tell the Savage chips about its physical address. I used a drmAddMap call copied from the MGA driver that looked like it did what I wanted. But I had to find out that the handle returned by drmAddMap is a kernel virtual address, not a physical address. Later I saw that the status page seems to be unused in the MGA driver. The code to get the physical address from the kernel virtual address is #if-ed out, probably for portability reasons. Does the code in drm_pci.c apply? It's only used by the via driver. I'm not sure what it does. I guess if I was only going to use that memory in kernel drm_pci_alloc would be fine. But I want to map the status page at least in the Xserver, maybe also in clients. BTW, I don't see any use of it in the via driver. But it is used by mach64. I also see that i810-i915 use pci_alloc_consistent directly. Is that portable to BSD? Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?
Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53: I just changed DRM to alternative between zero and POLLIN This will make the DRM poll() function work like the kernel expects it to and still work with existing X servers. Can someone please get this incorrect code out of the X server? As I mentioned earlier, setting driverSwapMethod to DRI_KERNEL_SWAP seems to work for the savage driver. I bet it works for many others too. AFAICT this tells the common DRI code not to use the DRM file handle. Once this is proven to work with all drivers we could axe the code for the other methods. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
README files invisible on http://freedesktop.org
I just wanted to add a README.Xorg in http://freedesktop.org/~dri/snapshots/extras when I noticed that there are two older README.* files which do not show up in http. A new README.Xorg didn't show up either. However adding an empty file with a different name (I tried `touch xorgstuff`) was reflected on http. Is there something in the httpd configuration that makes README files invisible in directory listings? Why would anyone want to hide README files? Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libGL cannot open savage_dri.so
On Wed, 13 Oct 2004 00:22:34 +0200 David [EMAIL PROTECTED] wrote: I tried the 20041012 common+savage snapshots with the Xorg snapshots today. The only problem I'm seeing is that direct rendering isn't enabled. Xorg.0.log says that DRI is enabled. Output of glxinfo with LIBGL_DEBUG=verbose: name of display: :0.0 libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: cannot open shared object file: No such file or directory) libGL error: unable to find driver: savage_dri.so display: :0 screen: 0 direct rendering: No ... I need to make sure that libexpat is compiled in statically. This was the case with the old XFree86-based snapshots. Somehow I must have screwed up with the new ones. Hang on, this should be fixed tomorrow or the day after. Until then try Alex's suggestion (symlink). [snip] Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
What is driverSwapMethod = DRI_HIDE_X_CONTEXT?
While investigating rare Xserver (errno=22 in select) and X client (losing X connection) crashes that seem to be related to the new linux-core drm I found this in savage_dri.c and several other DDX drivers: ...driverSwapMethod = DRI_HIDE_X_CONTEXT; This seems to indicate that the Xserver is somehow involved in direct rendering buffer swap operations and the driver-independent DRI code installs a DRM signal handler for it. I changed it to DRI_KERNEL_SWAP in the savage driver and have not got any crashes since. I'm going to stress this system a bit more tomorrow. GL apps still work, as expected since in the savage driver the kernel is currently not involved in buffer swaps. It's all done client side. Can anybody tell me what DRI_HIDE_X_CONTEXT means exactly and why it's used in so many drivers? I could imagine it has something to do with page flipping in the radeon driver, but what about MGA for example? How does this influence the way the Xserver interacts with the DRM? I'm trying to understand why the changes in linux-core drm started causing Xserver hickups. Till now I'm lost in the Xserver's use of client connections' and device file handles. Thanks, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: Building the DRI: shader/arbprogparse.c:3630: stray '\240' in program
On Mon, 11 Oct 2004 14:54:07 -0400 (EDT) Karl Rasche [EMAIL PROTECTED] wrote: shader/arbprogparse.c:3630: stray '\240' in program I think this stems from the line #define ARB_DRAW_BUFFERS ï0x80 around line 175-ish. It looks like, at least in the CVS browsing, that there is a bunch of odd crap between the end of ..._BUFFERS and 0x80. I committed a fix. Hexdump showed a series of 20 a0 20 a0 ... between _BUFFERS and 0x80. Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
On Sun, 10 Oct 2004 22:19:18 -0400
Adam Jackson [EMAIL PROTECTED] wrote:
On Sunday 10 October 2004 17:45, Felix Kühling wrote:
On Sun, 10 Oct 2004 22:01:30 +0200 David [EMAIL PROTECTED] wrote:
[snip]
They are forwards compatible but not backwards compatible. 4.4 modules
will work on 6.8, but 6.8 modules won't work on 4.4. So yes, we need
to build an Xorg server snapshot.
- ajax
I don't want to reinstall my whole box every year, so I must find a way
to test current snapshots on XFree86 or give up with testing.
The new snapshots instructions (Xorg binary, etc...) are giving me this:
Adam, can you comment this? How much besides the Xorg server binary is
needed in order to get this working? Is it realistic to make Xorg work
in a XFree86 installation with only a few binary replacements? How soon
is any such thing going to break again?
Looks like we also need libextmod and libxtt. And the unresolved symbols
in the savage driver module look like it requires some newer libxaa and
libfb modules than the XFree86 ones. Anything else? I guess we could add
any new xorg modules to the common snapshots.
The server binary and all of ${PROJECTROOT}/lib/modules should be sufficient.
Note that that's pretty much equivalent to upgrading to Xorg.
I've uploaded a Xorg-modules.tar.bz2 to the snapshots/extras dir. It
contains all (strip -g) modules except the ones included in the binary
snapshots (libGLcore.a, libglx.a, libdri.a, all 2D and 3D drivers).
David, could you give it a try? Proceed as follows:
uninstall common and card-specifc snapshots
cd /usr/X11R6/lib
mv modules modules.backup
tar -tjf ~/Xorg-modules.tar.bz2
reinstall common and card-specific snapshots
If this works I'll update the snapshot installation instructions and add
a README.Xorg in the extras dir.
Regards,
Felix
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
On Sun, 10 Oct 2004 22:01:30 +0200 David [EMAIL PROTECTED] wrote: [snip] They are forwards compatible but not backwards compatible. 4.4 modules will work on 6.8, but 6.8 modules won't work on 4.4. So yes, we need to build an Xorg server snapshot. - ajax I don't want to reinstall my whole box every year, so I must find a way to test current snapshots on XFree86 or give up with testing. The new snapshots instructions (Xorg binary, etc...) are giving me this: Adam, can you comment this? How much besides the Xorg server binary is needed in order to get this working? Is it realistic to make Xorg work in a XFree86 installation with only a few binary replacements? How soon is any such thing going to break again? Looks like we also need libextmod and libxtt. And the unresolved symbols in the savage driver module look like it requires some newer libxaa and libfb modules than the XFree86 ones. Anything else? I guess we could add any new xorg modules to the common snapshots. Symbol FontCacheChangeSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetStatistics from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheCloseCache from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheInsertEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheOpenCache from module /usr/X11R6/lib/modules/fonts/libxtt..a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetBitmap from module /usr/X11R6/lib/modules/fonts/libxtt..a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Fatal server error: Some required symbols were unresolved Maybe you can provide us some binary modules with the Xorg snapshot (libextmod and libxtt). Thanks | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Can't apply S3TC patch anymore with current Mesa
On Sat, 9 Oct 2004 14:14:29 +0200 Marcello Maggioni [EMAIL PROTECTED] wrote: [snip] Hey , I've solved in setting by DRICONF 5 Texture units instead of 6 . There's something wrong in using 6 Texture units with lastest DRI drivers? Marcello The more texture units you have the smaller the maximum texture size gets. The problem is that with N texture units you currently need to be able to have N textures of maximum size and maximum color depth bound to a texture unit. This means they all have to be in texture memory at the same time. With given texture memory that limits the maximum size of textures. Increasing the AGP size (option GARTSize) in xorg.conf would increase the amount of available texture memory which would allow larger textures too. Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
On Sat, 9 Oct 2004 09:09:52 -0400 Adam Jackson [EMAIL PROTECTED] wrote: On Friday 08 October 2004 17:22, David wrote: Hi. Common and savage snapshots from 20041008 are giving me this at the XFree86 startup: You cannot use modules compiled for Xorg 6.8 on XFree86 anything. I thought they were still binary compatible. If they are not then we would have to offer a download of a precompiled Xorg server for snapshot users. - ajax | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Can't apply S3TC patch anymore with current Mesa
On Fri, 8 Oct 2004 16:47:56 +0200 Marcello Maggioni [EMAIL PROTECTED] wrote: [snip] I've also another question . Why ,if I choose in DRICONF Frame Throttling as Usleep or Busy Waiting I get this message if I try to run applications as user, do I get this message ? : IRQ's not enabled, falling back to busy waits: 11 0 201 And why if I run the same application as root I don't get it? That's because root uses a different configuration file. It's in ~/.drirc which is /home/your user name/.drirc or /root/.drirc in either case. Either run driconf as root too, to edit root's .drirc and/or the system-wide /etc/drirc or copy .drirc from your normal user account to /root (or better yet, make a symlink). Thanks Bye Marcello Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Can't apply S3TC patch anymore with current Mesa
On Fri, 8 Oct 2004 17:10:35 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: [snip] When I set 'setenv force_s3tc_enable 1' quake3-smp do NOT start anymore. ATTENTION: default value of option force_s3tc_enable overridden by environment. Fatal error in __driConfigOptions line 75, column 0: illegal default value: 1. That's because 1 is indeed illegal for boolean options such as force_s3tc_enable. Legal values are true and false. -Dieter Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Can't apply S3TC patch anymore with current Mesa
On Fri, 8 Oct 2004 18:09:29 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: [snip] INSTALL/SOURCE ut2004demo [1] 31246 INSTALL/SOURCE Disabling HW TCL support Argh, Felix, what is here wrong? It is due to disabled TCL for doom3! When I delete doom3 settings from drirc driconf device screen=0 driver=r200 application name=all option name=force_s3tc_enable value=true / /application /device /driconf TCL is back. The problem is that the name-attribute is just a descriptive string of your application. Use the executable-attribute to set the name of the executable. Without that attribute your doom3-demo section applies to all applications. Example (assuming the executable is really called doom3-demo): application name=doom3-demo executable=doom3-demo option name=tcl_mode value=0 / /application Or if you're using driconf, don't forget to fill in the Executable field. (Happened to me too, a couple of times ;-) UT2k3 2k4 tested. -Dieter | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Wed, 06 Oct 2004 15:28:21 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2004-10-06 at 13:09, Felix Kühling wrote:
On Wed, 6 Oct 2004 22:03:40 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
[snip]
You're right. Thanks for catching this. I tried to understand what
force_emit in the i830 driver was for, now I understand. An updated
patch is attached. I'm going to commit that.
Still wrong. Sorry. :-/ I can't just use the index because the vertex
format also depends on the number of texture coordinates which is not
reflected in the index. I could go abuse some more unused texture bits,
but I think I'll come up with my own savage-specific bit field. I should
get some sleep before I trying to fix any more bugs.
Ouch. Indeed. I wonder how expensive tnl_install_attrs is -- might we
want to just always do it?
The attached patch is what I committed. When I looked at the diff I
stumbled over this definition, which looks the same in r128 and i830:
#define EMIT_PAD( N ) \
do {\
imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0;\
imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD; \
imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
imesa-vertex_attr_count++; \
} while (0)
It looks like EMIT_PAD is overloaded here, once as a macro with argument
and once without. I didn't know cpp supports overloading. Is this a
gcc-extension or are we just lucky that it works?
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.12
diff -u -r1.12 savagetris.c
--- savagetris.c1 Jul 2004 13:14:06 - 1.12
+++ savagetris.c7 Oct 2004 10:03:36 -
@@ -707,20 +707,43 @@
}
-#define EMIT_ATTR( ATTR, STYLE, SKIP ) \
+#define EMIT_ATTR( ATTR, STYLE, INDEX, SKIP ) \
do { \
imesa-vertex_attrs[imesa-vertex_attr_count].attrib = (ATTR); \
imesa-vertex_attrs[imesa-vertex_attr_count].format = (STYLE); \
imesa-vertex_attr_count++; \
- drawCmd = ~SKIP; \
+ setupIndex |= (INDEX); \
+ drawCmd = ~(SKIP); \
} while (0)
+#define EMIT_PAD( N ) \
+do { \
+ imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0; \
+ imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD;\
+ imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
+ imesa-vertex_attr_count++; \
+} while (0)
+
+#define SAVAGE_EMIT_XYZ 0x0001
+#define SAVAGE_EMIT_W 0x0002
+#define SAVAGE_EMIT_C0 0x0004
+#define SAVAGE_EMIT_C1 0x0008
+#define SAVAGE_EMIT_FOG 0x0010
+#define SAVAGE_EMIT_S0 0x0020
+#define SAVAGE_EMIT_T0 0x0040
+#define SAVAGE_EMIT_ST0 0x0060
+#define SAVAGE_EMIT_S1 0x0080
+#define SAVAGE_EMIT_T1 0x0100
+#define SAVAGE_EMIT_ST1 0x0180
+
+
static void savageRenderStart( GLcontext *ctx )
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
TNLcontext *tnl = TNL_CONTEXT(ctx);
struct vertex_buffer *VB = tnl-vb;
GLuint index = tnl-render_inputs;
+ GLuint setupIndex = SAVAGE_EMIT_XYZ;
GLuint drawCmd = SAVAGE_HW_SKIPFLAGS;
if (imesa-savageScreen-chipset S3_SAVAGE4)
drawCmd = ~SAVAGE_HW_NO_UV1;
@@ -735,18 +758,24 @@
* build up a hardware vertex.
*/
if ((index _TNL_BITS_TEX_ANY) || !(ctx-_TriangleCaps DD_FLATSHADE)) {
- EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, SAVAGE_HW_NO_W );
+ EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, SAVAGE_EMIT_W, SAVAGE_HW_NO_W );
}
else {
- EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0 );
+ EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0, 0 );
}
/* t_context.c always includes a diffuse color */
- EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_HW_NO_CD );
+ EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_EMIT_C0, SAVAGE_HW_NO_CD );
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
- EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
- EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ if ((index _TNL_BIT_COLOR1))
+EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_EMIT_C1,
SAVAGE_HW_NO_CS
Re: [Dri-users] XOrg CVS/DRI on alpha
On Thu, 7 Oct 2004 00:46:38 +0200 (CEST) Torsten Zirzlaff [EMAIL PROTECTED] wrote: Hi It was my fault not running the ldconfig after the build. Not really your fault since the building instructions didn't mention it (only for manual installation). I added a note about it. Alas dri does not work and glxinfo or glxgears dies with the following lines: tinuviel zirzlaff 55 (~):glxinfo name of display: :0.0 Mesa 6.3 implementation error: bad S wrap mode in r200SetTexWrap Please report to the Mesa bug database at www.mesa3d.org [previous messages 15 times] Segmentation fault Any idea what had gone wrong this time? Looks like a driver bug to me. I'm CCing to dri-devel. You're running linux on Alpha, right? In case it matters for this bug. TIA Torsten | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: wierd difference between X built vs Mesa built?
On Thu, 7 Oct 2004 02:10:37 +0100 (IST) Dave Airlie [EMAIL PROTECTED] wrote: I know someone asked a while back but I'm not sure anyone concluded what was happening... Last night I decided to give the d3demo a go on my r9200 under DRI, my first attempt involved pointing LIBGL_DRIVERS_PATH to my S3TC enabled Mesa tree, this works for me for a number of games and seems fine, however Doom 3 report indirect rendering when I do this, it looks like it is something to do with the way it dlopens, if I build the dri driver via my Xorg tree (i.e. just point extras/Mesa at my Mesa tree and rebuild the r200 driver), it works fine.. So whats the major difference between a dri driver built in mesa and in Xorg? (should I suspect PTHREADS?) I get a similar problem with Quake Forge (0.5.2). With LIBGL_DEBUG=verbose it says: libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /home/felix/mesa/lib/savage_dri.so libGL error: dlopen /home/felix/mesa/lib/savage_dri.so failed (/home/felix/mesa/lib/savage_dri.so: undefined symbol: __glXFindDRIScreen) libGL error: unable to find driver: savage_dri.so ldd `which nq-glx` doesn't list any libGL. Some grepping on the source indicates that it loads libGL with dlopen(libGL.so.1, RTLD_NOW). I tried changing this to RTLD_LAZY without any effect. I also made it load /usr/X11R6-XORG/lib/libGL.so.1 with an absolute path without any effect. Last thing I tried after reading the dlopen manpage again was RTLD_GLOBAL. That works. The problem is that without RTLD_GLOBAL libGL.so can't export any symbols to the 3D driver. It seems with the old DRI interface that was not needed. But the drivers build from Mesa with NEW_INTERFACE_ONLY need access to at least one function exported by libGL. Maybe we could workaround the problem by calling dlopen (NULL, RTLD_GLOBAL) in libGL somewhere. Not sure if this works. Or we would have to link the 3D drivers agains libGL. However, libGL may not be available when building the 3D drivers from the mesa tree. | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI building - Radeon module problem
On Tue, 5 Oct 2004 19:04:02 -0300 Paulo R. Dallan [EMAIL PROTECTED] wrote: [snip] At first impression, 3d acceleration seemed really bad (). Glxgears was giving me 130, 140 FPS! And this is an Athlon XP 2600 with the ATI 9200se (I know, this video card is not that good, but results should not be so bad, it has 128 Mb, AGP 8x (though dri is only up to 4X), 64 bits)... Any tip of what could be wrong? PS: Changed XOrg.conf to set 16 bits as the default depth and included ' Option AGPMode 4 '. Got a better performance: 400 FPS. Should I also try ' Option AGPFastWrite boolean ' (in this case, in place of boolean 'true', '1', 'yes')? Anyway, are these 400 FPS what I should be expecting as performance, or is it still considered low (the PIII500 with a Savage4 32Mb at AGP 2X gets 200-250 FPS)? There may be a problem with the new glxgears from X.org. When I run it alone I get the full framerate I can expect (~385 fps on ProSavage DDR). When I run a CPU hog at the same time (while true; do true; done in bash) The frame rate goes down to 10 fps and glxgears gets only 1% of the CPU. With the old glxgears from XFree86 the frame rate reduces to about 195 and the CPU is shared about 50:50 between glxgears and the CPU-hogging bash. In order to draw any meaningful conclusions from the CPU usage with r200 you need to change frame throttling to busy waiting. You can do that using driconf or on the command line with fthrottle_mode=0 glxgears Run top on a different terminal and see how much CPU is used by glxgears. It should be close to 100%. If significant CPU power is used by a different process that would explain the low FPS. If the CPU is idle then there might be something wrong with process scheduling in the kernel. HTH, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon 9200se - driver issues
On Wed, 6 Oct 2004 05:36:02 -0300 Paulo R. Dallan [EMAIL PROTECTED] wrote: On Wednesday 06 October 2004 04:43, you wrote: Paulo R. Dallan schrieb: snip The radeon driver is a hardware-accelerated driver for Radeon 7500 chips. I don't know why it even works on your card. I think Philip is talking about the 3D drivers. There are different ones for radeon (Radeon 7x00) and r200 (Radeon 8500, 9[0-2]00). The radeon 2D driver in the Xserver works for all Radeons from 7000 to 9800. Philipp Hi Philipp, thanks for the reply! Are you sure about that? I've just tried the ati generic driver (option from xorgconfig) and the speed got even slower (however, glxinfo also gave me direct rendering: yes!). Actually, I got a little confused over here. In the dri/wiki, under the building description, it is described that the ati is the 2D driver for the Mach64, Rage128 and Radeon chipsets (so I assume the Radeon 9200se is included here; or is it not?). However, the options at xorgconfig that I could find are: (a) generic ati; (b) generic r128 (which I believe it is the Rage128); and (c) generic radeon (which was my first option)... So, do you know which I should choose? Choose ati or radeon. ati should load the radeon driver automatically after detecting your card. It is interesting to mention that at the ATI Radeon dri/wiki page, when mentioning 3D acceleration, it explains that from the 7800/rv200 and below are supported by the radeon dri driver, and that from the 8500 to 9200 are supported by the r200 driver (in any case, they seem to use the same drm driver, radeon.ko, if not mistaken); So ok, but what would be the option for the r200 dri driver at xorgconfig? Or should I enter it as a parameter directly at xorg.conf? Or is it automatically detected, after the chipset is recognised? xorgconfig selects the 2D driver. The 2D driver tells libGL which 3D driver to use. The radeon 2D driver knows that your card needs the r200 3D driver. So as long as you compiled and installed the r200 3D driver (in the Mesa tree) you're fine. Also note that there is a single radeon.ko DRM kernel driver for all Radeons. Best, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Is there a simpler test case than RTCW? I can't reproduce a segfault
with a simple program that draws triangles with diffuse lighting and
Fog. John, can you try if the attached patch fixes it?
Keith
Regards,
Felix
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.12
diff -u -r1.12 savagetris.c
--- savagetris.c1 Jul 2004 13:14:06 - 1.12
+++ savagetris.c6 Oct 2004 11:46:34 -
@@ -715,6 +715,15 @@
drawCmd = ~SKIP; \
} while (0)
+#define EMIT_PAD( N ) \
+do { \
+ imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0; \
+ imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD;\
+ imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
+ imesa-vertex_attr_count++; \
+} while (0)
+
+
static void savageRenderStart( GLcontext *ctx )
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
@@ -745,8 +754,14 @@
EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_HW_NO_CD );
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
- EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
- EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ if ((index _TNL_BIT_COLOR1))
+EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 3 );
+ if ((index _TNL_BIT_FOG))
+EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 1 );
}
if (index _TNL_BIT_TEX(0)) {
Fw: Snapshot build failed
make[3]: *** [depend] Error 127 make[3]: Leaving directory `/home/projects/dri/snapshots/build/HEAD/mesa/src/mesa' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/projects/dri/snapshots/build/HEAD/mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/projects/dri/snapshots/build/HEAD/mesa' make: *** [linux-dri-x86] Error 2 make: Leaving directory `/home/projects/dri/snapshots/build/HEAD/mesa' = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Tail of logfile log/HEAD-mesa.prepare: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Tail of logfile log/HEAD-xorg.build: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = if test -z true ; then \ cd `dirname xdriinfo` \ ln -s `basename xdriinfo.man` `basename xdriinfo._man`; \ else \ cpp -undef -traditional -D__apploaddir__=/usr/X11R6/lib/X11/app-defaults -D__appmansuffix__=1x -D__filemansuffix__=5x -D__libmansuffix__=3x -D__miscmansuffix__=7x -D__drivermansuffix__=4x -D__adminmansuffix__=8 -D__projectroot__=/usr/X11R6 -D__xconfigfile__=xorg.conf -D__xconfigdir__=/usr/X11R6/lib/X11 -D__xlogfile__=Xorg -D__xservername__=Xorg -D__xorgversion__=' ' -D__vendorversion__=`echo 6 8 1 99 | sed -e 's/ /./g' -e 's/^/Version\\\ /'` X.Org \ xdriinfo.man | sed -e '/^# *[0-9][0-9]* *.*$/d'-e '/^#line *[0-9][0-9]* *.*$/d' -e '/^[ ]*XCOMM$/s/XCOMM/#/'-e '/^[ ]*XCOMM[^a-zA-Z0-9_]/s/XCOMM/#/'-e '/^[ ]*XHASH/s/XHASH/#/' -e '/[EMAIL PROTECTED]@$/s/[EMAIL PROTECTED]@$/\\/' xdriinfo._man; \ fi rm -f xdriinfo.1x.html xdriinfo.1x-html /../config/util/rman -f HTML xdriinfo._man \ xdriinfo.1x-html mv -f xdriinfo.1x-html xdriinfo.1x.html make[4]: Leaving directory `/home/projects/dri/snapshots/build/HEAD/xorg/programs/xdriinfo' make[3]: Leaving directory `/home/projects/dri/snapshots/build/HEAD/xorg/programs' make[2]: Leaving directory `/home/projects/dri/snapshots/build/HEAD/xorg' make[1]: Leaving directory `/home/projects/dri/snapshots/build/HEAD/xorg' Wed Oct 6 07:06:47 PDT 2004 Full build of Release 6.8 complete. make: Leaving directory `/home/projects/dri/snapshots/build/HEAD/xorg' = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Tail of logfile log/HEAD-xorg.prepare: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Tail of logfile log/drm-HEAD.update: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Tail of logfile log/mesa-HEAD.update: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = U src/mesa/drivers/dri/tdfx/tdfx_context.c = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Tail of logfile log/xorg-HEAD.update: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = U ChangeLog U extras/Mesa/src/mesa/drivers/dri/common/dri_util.c U lib/GL/glx/glxext.c U programs/Xserver/hw/xfree86/drivers/savage/savage.man U programs/Xserver/hw/xfree86/drivers/savage/savage_accel.c U programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c U programs/Xserver/hw/xfree86/xf86config/xorgconfig.c = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Wed, 06 Oct 2004 10:16:23 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2004-10-06 at 04:54, Felix Kühling wrote:
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Is there a simpler test case than RTCW? I can't reproduce a segfault
with a simple program that draws triangles with diffuse lighting and
Fog. John, can you try if the attached patch fixes it?
One thing to note is, what happens if you change from, say,
specular-without-fog to specular-with-fog? You won't end up doing the
install_attrs again like you want. For Rage 128, I just stored the
index in the context and checked if that had changed, instead of the
vertex format register's value.
You're right. Thanks for catching this. I tried to understand what
force_emit in the i830 driver was for, now I understand. An updated
patch is attached. I'm going to commit that.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.12
diff -u -r1.12 savagetris.c
--- savagetris.c1 Jul 2004 13:14:06 - 1.12
+++ savagetris.c6 Oct 2004 19:58:10 -
@@ -715,6 +715,15 @@
drawCmd = ~SKIP; \
} while (0)
+#define EMIT_PAD( N ) \
+do { \
+ imesa-vertex_attrs[imesa-vertex_attr_count].attrib = 0; \
+ imesa-vertex_attrs[imesa-vertex_attr_count].format = EMIT_PAD;\
+ imesa-vertex_attrs[imesa-vertex_attr_count].offset = (N); \
+ imesa-vertex_attr_count++; \
+} while (0)
+
+
static void savageRenderStart( GLcontext *ctx )
{
savageContextPtr imesa = SAVAGE_CONTEXT(ctx);
@@ -736,6 +745,11 @@
*/
if ((index _TNL_BITS_TEX_ANY) || !(ctx-_TriangleCaps DD_FLATSHADE)) {
EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, SAVAGE_HW_NO_W );
+ /* We use index below to check if the emit code changed. Since
+ * we're depending on something outside the index here we need
+ * to make sure index reflects the change in the emit
+ * code. Using an otherwise unused bit. */
+ index |= _TNL_BIT_TEX7;
}
else {
EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0 );
@@ -745,8 +759,14 @@
EMIT_ATTR( _TNL_ATTRIB_COLOR0, EMIT_4UB_4F_BGRA, SAVAGE_HW_NO_CD );
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
- EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
- EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ if ((index _TNL_BIT_COLOR1))
+EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 3 );
+ if ((index _TNL_BIT_FOG))
+EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
+ else
+EMIT_PAD( 1 );
}
if (index _TNL_BIT_TEX(0)) {
@@ -770,19 +790,16 @@
EMIT_ATTR( _TNL_ATTRIB_TEX1, EMIT_1F, SAVAGE_HW_NO_U1 );
}
- /* Only need to change the vertex emit code if there has been a
-* statechange to a new hardware vertex format and also when the
-* vertex format is set for the first time. This is indicated by
-* imesa-vertex_size == 0.
-*/
- if (drawCmd != (imesa-DrawPrimitiveCmd SAVAGE_HW_SKIPFLAGS) ||
- imesa-vertex_size == 0) {
+ /* Need to change the vertex emit code if the SetupIndex changed or
+* is set for the first time (indicated by vertex_size == 0). */
+ if (index != imesa-SetupIndex || imesa-vertex_size == 0) {
imesa-vertex_size =
_tnl_install_attrs( ctx,
imesa-vertex_attrs,
imesa-vertex_attr_count,
imesa-hw_viewport, 0 );
imesa-vertex_size = 2;
+ imesa-SetupIndex = index;
imesa-DrawPrimitiveCmd = drawCmd;
}
@@ -802,7 +819,8 @@
/* Flush the last primitive now, before any state is changed.
* Alternatively state could be emitted in all state-changing
-* functions in savagestate.c. */
+* functions
Re: Segfault on RTCW with Savage
On Wed, 6 Oct 2004 22:03:40 +0200 Felix Kühling [EMAIL PROTECTED] wrote: [snip] You're right. Thanks for catching this. I tried to understand what force_emit in the i830 driver was for, now I understand. An updated patch is attached. I'm going to commit that. Still wrong. Sorry. :-/ I can't just use the index because the vertex format also depends on the number of texture coordinates which is not reflected in the index. I could go abuse some more unused texture bits, but I think I'll come up with my own savage-specific bit field. I should get some sleep before I trying to fix any more bugs. Later, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AW: [Dri-users] Update building and installation instructions
On Tue, 5 Oct 2004 08:02:16 +0200 Zirzlaff, Torsten [EMAIL PROTECTED] wrote: Hi. Fine those instructions seem fine to me, but I have thefollowing questions: i) For building the Mesa 3D drivers on linux on other architectures besides x86. Do I have to seek a diferent config file instead of Mesa/configs/linux-dri-x86 or is the give one valid for all linux architectures? I muse that the x86 part denotes the architecture, but I'm not sure about it. Good question. There is a generic target linux-dri which doesn't include any architecture-specific assembler optimizations. There is also linux-dri-x86-64 for the AMD-64 architecture. ii) Could I expect noticeable improvement on an alpha architecture for a r200 card over my previous XFRee86 DIR/CVS? There have been some bug fixes and performance improvements in the r200 driver recently. I'm afraid there may also be new bugs. BTW, there was a discussion about Alpha and r200 on yesterday's IRC session. To me it seemed like it's not working with current CVS. If you got it working somehow I bet some people on dri-devel would be interested in hearing about it. TIA Torsten Bye, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI building - Radeon module problem
On Tue, 5 Oct 2004 14:42:44 -0300 Paulo R. Dallan [EMAIL PROTECTED] wrote: Hi Felix, hi all, how are you doing? Just compiled the dri drivers for the Radeon ATI according to the new procedures (btw, great instructions, thank you for the patience in updating same) and I'm having a problem similar to one of the described to the drm module (but not really the same, relates to another component). Let me explain. I'm running Slackware 10.0 running kernel 2.6.7, and could successfully compile dri, mesa and drm; agpgart and via-agp (this is an Asus av7x8x-x motherboard, kt400 chipset, if not mistaken) are being loaded automatically, however the radeon kernel module is not. After trying the manual insertion, i get this message, similar to the drm problem described in the troubleshooting: FATAL: Error inserting radeon (/lib/modules/2.6.7/kernel/drivers/char/drm/radeon.ko): Unknown symbol in module, or unknown parameter (see dmesg) The relevant parts of dmesg (at least that I could identify) are: mtrr: 0xe800,0x800 overlaps existing 0xe800,0x10 radeon: Unknown symbol i2c_bit_add_bus radeon: Unknown symbol i2c_bit_del_bus radeon: Unknown symbol i2c_bit_add_bus radeon: Unknown symbol i2c_bit_del_bus I think Jon Smirl added some i2c stuff to the radeon kernel module. (I'm not up to speed with radeon stuff, just hear-say ;-) Maybe you have compile some basic i2c support into your kernel. Jon, is there a way for the DRM Makefile to scream at compile time if there is no i2c-support in the kernel? Parts of the XOrg log file: [snip] Regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Snapshot build failed
On Tue, 5 Oct 2004 06:51:40 -0700 (PDT) [EMAIL PROTECTED] (Eric Anholt) wrote: A snapshot build failed at Tue Oct 5 06:51:40 PDT 2004. Please inspect the logfiles in /home/projects/dri/snapshots/log. Summary: Updating sources from CVS ... done. HEAD: Preparing the builds ... failed. Errors occured. Skipping cleanup and archive. Tail of logfile log/HEAD-mesa.prepare: = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = ../prepare.sh: line 48: lndir: command not found Looks like I have to reimplement lndir for the snapshot build on fd.o. I hope I have it ready for tomorrow's build. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = [snip] | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at how
other drivers handle this now to avoid trying to emit FOG when only COLOR1 is
enabled, and vice versa.
Thanks for tracking that down. I'll take a look later.
Keith
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Update building and installation instructions
Hello dri-users, after numerous of mails from frustrated users I finally got around to update the Building instructions at http://dri.sourceforge.net/cgi-bin/moin.cgi/Building. Please report any problems with the new instructions to [EMAIL PROTECTED] BSD is currently not supported by these instructions. Eric Anholt is working on a Mesa build configuration for BSD. Best regards, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
