Re: [Xorg] Damage/Composite + direct rendering clients
On Mon, 17 May 2004, Keith Packard wrote: Around 15 o'clock on May 17, Andy Ritger wrote: [snip] The tricky part here is that the damage event shouldn't be sent to Damage clients until the hardware has completed the damage, but that is the vendor's problem... I'm just trying to make sure everything that is needed is in place so that vendors can solve that. It can't even be seen by the X server until the rendering is complete. When using 'automatic' update mode, there isn't an external application waiting for the event; the X server updates the screen directly. Ah right, good point. One solution would be for the direct rendering client to send private protocol to the X server as soon as the rendering is sent to the hw. Sure; just as long as the X server could then block awaiting completion. BeginComposite/EndComposite bracketing would facilitate that (it would be BeginComposite's job to make sure the hw had completed). There's no need for these extra requests -- the X server just needs to block when using the indicated source window buffer. This way, the X server can actually pend lots of other parts of the compositing operation and only when the affected window finally comes into play will the X server block. I'm debating whether it is better for the X server to not even know of the damage until it has completed in hardware, or if it is better to tell the X server as soon as the rendering has kicked off, and then require X to wait for completion only when it needs to use the drawable as a source. The former will avoid blocking in the server, while the latter may reduce latencies... that will require some experimentation. I just thought of another case here -- we want to allow for direct rendering compositing managers as well. That will require inter-client synchronization along the same lines... This introduces the problem of how to get the pixmap data to the client efficiently. That's a whole separate thread. glxgears is then redrawn (and swapped) before the compositing is performed. When the compositing is performed, the xterm and the portion of the glxgears window beneath the xterm are recomposited into the backing pixmap, which is then blitted to the visible screen. At this point, we have a tear between the portion of the glxgears window that is not beneath the xterm and the part that is (the part that is beneath the xterm is from glxgear's new frame, while the part not beneath the xterm is from the old frame). The window of vulnerability isn't as long as you fear -- the compositing manager can always use the damaged region of each window precisely at the time of the compositing operation, without reference to any events it has received. That's because the damage accumulates inside X server regions where it can be used to compute correct updates. OK, I think that makes sense. As long as the compositing manager holds the server grabbed (which presumably locks out direct clients as well) while it updates the screen, there shouldn't be any tearing. No need to drain the event queue or anything else so dramatic. Yes, if the composite manager grabs the server while updating the screen, then everything will be fine. Your sample xcompmgr doesn't grab the server when updating the screen, and I expect many future composite managers will use xcompmgr as a starting point. information related to a specific drawable. Any future requests for contents from that drawable must delay until that damage has actually occurred. Right, but how is that enforced? Who delays until the damage has actually occurred? The X server would have to stall waiting for the swap to complete. It would know to do this because the direct client would have indicated that the swap was queued to the hardware. OK, so X drivers would have to hook into this and stall when appropriate. True, but window managers can't cause video memory to be freed, which would be really nice to do when you are transitioning into a fullscreen application. They can free the extra buffers used for Composite, and the X server can migrate less used pixmaps from the video card. That seems possible. However, that seems like a lot to ask of all window managers. Would common functionality like that be better contained within an X server extension? Even the RandR implementation naively leaves the video memory allocated for the largest possible root window size. Not in kdrive. OK, that's something I'd like to fix in the monolithic server. OK; how does a driver differentiate the per-window pixmaps from regular pixmaps? The driver can see them associated with windows by wrapping SetWindowPixmap. OK. So if the X server might start compositing, then the driver can't advertise the overlay port; is that correct? It could pretend the overlay port was busy for new apps and
Re: dri with SiS : seg fault
On Mon, May 17, 2004 at 11:21:27PM +0200, Felix K?hling wrote: On Mon, 17 May 2004 16:57:38 +0200 [EMAIL PROTECTED] wrote: [snip] I attach a typescript that shows that there is a problem when sis_dri.so tries to test SSE support This is the normal SSE test. The signal is caught by mesa. Just type cont to proceed to the real problem. sorry, I did not know that. Anyway, is there a solution for the problem ? BTW: the 'install.sh' in the above packages common-* and sis-* overwrites prexisting files, and there is no way to unistall and put back the originals; moreover IMHO 'install.sh' does not log its actions enough If you ran install.sh only once per package you can run install.sh restore to restore the original files maybe this 'install.sh restore' should be better advertised... I found it (googling) in http://dri.sourceforge.net/doc/install_readme.txt but not in the pages http://dri.sourceforge.net/cgi-bin/moin.cgi/ (that are the main entry point for DRI ) you may want to add a copy of install_readme.txt also inside the daily snapshots at http://www.freedesktop.org/~dri/snapshots/ install_readme.txt also states that I must use XFree v4.1 whereas http://dri.sourceforge.net/cgi-bin/moin.cgi/Download says XFree 4.3 are in Debian sid (implicitely suggesting that they are ok) If you feel like logging could be improved you're welcome to submit a patch. ;-) I don't have the time to look into it ATM and as I don't use snapshots myself the install script is always the hardest part for me to test. yep. the idea that I have is that, in Debian, 'install.sh' should use dpkg-divert to move aside files a. -- Andrea Mennucc one houndred and fifty - the chicken sings pgp97A7faZAfD.pgp Description: PGP signature
Re: unresolved symbol pci_get_subsys and pci_dev_put
I only find pci_get_subsys, one time in drm/linux/drm_drv.h ! okay I've checked in some fixes (untested) for 2.4 compat now .. Dave. best regards, -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Damage/Composite + direct rendering clients
Keith Packard [EMAIL PROTECTED] writes: As long as the compositing manager holds the server grabbed (which presumably locks out direct clients as well) while it updates the screen, there shouldn't be any tearing. No need to drain the event queue or anything else so dramatic. What if another client has already grabbed the server for whatever reason? Is screen updating then turned off? Søren --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Damage/Composite + direct rendering clients
On Tue, 18 May 2004, Soeren Sandmann wrote: Keith Packard [EMAIL PROTECTED] writes: As long as the compositing manager holds the server grabbed (which presumably locks out direct clients as well) while it updates the screen, there shouldn't be any tearing. No need to drain the event queue or anything else so dramatic. What if another client has already grabbed the server for whatever reason? Is screen updating then turned off? If a client has grabbed the server, then requests from all other clients (including the XGrabServer request) are not processed until that client has ungrabbed the server. The composite manager would block until the other client had ungrabbed. - Andy Søren --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Re: Damage/Composite + direct rendering clients
On Mon, 17 May 2004, Jim Gettys wrote: On Mon, 2004-05-17 at 16:03, Andy Ritger wrote: 2) some damage occurs, composite manager sends composite request, additional rendering is performed, part of which the composite operation picks up, but the rest of the rendering is not composited until the next frame of the composite manager, and we see visible tearing. Consider this example: a translucent xterm partially overlaps glxgears. If the xterm is damaged, and the composite manager requests a composite, and then glxgears is updated (between when the composite request is sent, and when the composite operation is performed), then the part of the glxgears beneath the xterm will be composited this frame of compositing. Later, the composite manager will receive a damage event for glxgears, and will composite, causing the visible screen to be brought up to date. But in the period of time between the first and second composites, glxgears will tear. The above xterm+glxgears scenario is not limited to direct rendering clients. The same should be reproducible with any regular X rendering -- there is a race between when the composite manager retrieves the damage region(s), when it sends the composite requests, and any rendering protocol (or direct rendering) that is processed in between. It seems that the complete solution would be for the composite manager to perform an XGrabServer(3X11) before retrieving the damage regions, then send the compositing requests, and then XUngrabServer(3X11). Unfortunately, that seems very heavy weight. On the other hand, it may ensure faster compositing by effectively raising the priority of the composite manager's protocol while all other X clients are locked out. Some may be inclined to accept the tearing rather than pay the heavy weight operation of grabbing/ungrabbing around every compositing frame. For X clients, that may be OK, but I expect the tearing will be much more pronounced with OpenGL clients, because by nature they are more often animating. Perhaps the best solution is to introduce two new requests to the Composite extension: a BeginComposite and an EndComposite that composite managers would call, bracketing their compositing requests. The X server would dispatch these requests into the X driver. This would give vendors the flexibility to perform any necessary synchronization to protect against the above race conditions. My thoughts are coming at this from a different but related direction than yours: it is the case of an application updating the state of its window(s), to minimize flashing. The thoughts I've had on this topic is to use an XSync counter: if the counter is even/odd, the contents of the window might be stable/unstable. Incrementing a counter is very fast. This might also fold into XSync counters for vertical retrace, as per the original XSync design/implementation (not implemented on Linux, though recently some work has been started). A similar situation might be usable for DRI synchronization, giving us a common synhronization framework, both for DRI synchronization and for application update synchronization. I suspect some tweaks to XSync may be necessary to get all this to work. Thanks, Jim. That sounds interesting. So an app would increment a counter for a window, indicating the window is in flux, and then increment the counter again when it is done updating the window? Yes. Exactly. Is this meant as a hint to the X server to note send any damage events for that window until the app indicates the window is in a stable state? No, as Keith says, damage accumulates in the region in the X server until the time you need to use the region. Any view a client has of the damaged region is likely to be obsolete by the time it would get it. So while it is possible for clients to get informed of damaged regions, it isn't really the main-line case damage was designed for. OK, I think I misunderstood some of the mechanics of Damage. Storing the region server side and letting the composite manager say use that region, whatever is in it is good. I am still slightly worried that a window could be damaged between when the composite manager decides which windows need recompositing and when it sends the composite requests (resulting in not compositing that window until the next iteration of the composite manager). XGrab/XUngrab would protect against that. What you want to avoid is round trips; the damage accumlation allows a client (say the compositing manager) to rerender
Re: [Xorg] Re: Damage/Composite + direct rendering clients
On Tue, 2004-05-18 at 10:10, Andy Ritger wrote: OK, thanks for the explanation. I'm not sure how applicable this is to the synchronization concerns I have, though. My biggest concern (new damage occuring inbetween when the composite manager decides what to recomposite, and when it does the composite) wouldn't be helped by this XSync mechanism. One strategy is to recomposite *everything* on the screen... Remember, we'll only actually do graphics operations on the damaged part of the screen; the rest get clipped by the damage region. The other concern (how to make sure direct rendering has completed by the time the drawable is used as a source in a composite operation) conceptually would be solved as you describe, but I expect the implementation would be buried deeper -- either an X driver doesn't call into the core X server to notify it of damage until the direct rendered damage has completed, or the X server has to block, as Keith described, when it receives requests that uses the pending damaged drawable as a source. Either way, I think it makes sense to leave this up to each vendor; the implementation details will likely be influenced by their architecture, etc. Yeah, we have to sweat through the details and see if this approach all hangs together, and how DRI and the X server would interact. The devil is in the details, as usual. - Jim -- Jim Gettys [EMAIL PROTECTED] HP Labs, Cambridge Research Laboratory --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Damage/Composite + direct rendering clients
On Tue, 2004-05-18 at 11:53, Soeren Sandmann wrote: Andy Ritger [EMAIL PROTECTED] writes: What if another client has already grabbed the server for whatever reason? Is screen updating then turned off? If a client has grabbed the server, then requests from all other clients (including the XGrabServer request) are not processed until that client has ungrabbed the server. The composite manager would block until the other client had ungrabbed. But if the compositing manager is blocked, nothing appears on the screen, right? This means screen updating is effectively turned off when an application is grabbing the server. Which is why avoiding server grabs is imporant, as much as possible. It takes a global lock out on the X server and needs to be used with great care. - Jim -- Jim Gettys [EMAIL PROTECTED] HP Labs, Cambridge Research Laboratory --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Damage/Composite + direct rendering clients
Andy Ritger [EMAIL PROTECTED] writes: What if another client has already grabbed the server for whatever reason? Is screen updating then turned off? If a client has grabbed the server, then requests from all other clients (including the XGrabServer request) are not processed until that client has ungrabbed the server. The composite manager would block until the other client had ungrabbed. But if the compositing manager is blocked, nothing appears on the screen, right? This means screen updating is effectively turned off when an application is grabbing the server. Søren --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Re: Damage/Composite + direct rendering clients
Around 10 o'clock on May 18, Jim Gettys wrote: One strategy is to recomposite *everything* on the screen... That's pretty much what the current compositing manager does; translucent windows which are damaged cause any related (underlying) windows to be redrawn transitively. Because all of this really depends on efficient rendering of clipped operations, I've started poking around the X server insides to do more computation post-clip instead of pre-clip. There's still a lot of places which assume the bounding box of the operation is closely approximated by the bounding box of the actual arguments. -keith pgpa4Olwfjoim.pgp Description: PGP signature
Re: [Xorg] Damage/Composite + direct rendering clients
Around 1 o'clock on May 18, Andy Ritger wrote: I'm debating whether it is better for the X server to not even know of the damage until it has completed in hardware, or if it is better to tell the X server as soon as the rendering has kicked off, and then require X to wait for completion only when it needs to use the drawable as a source. I don't think we'll be able to know which is best without giving them both a try. I was quite surprised at what method turned out best for the compositing manager -- one has been taught to avoid round trips at all cost, but the lowest latency was accomplished with an XSync call in the middle of the drawing loop. Just goes to show that intuition and reality are often in conflict... I just thought of another case here -- we want to allow for direct rendering compositing managers as well. That will require inter-client synchronization along the same lines... This introduces the problem of how to get the pixmap data to the client efficiently. That's a whole separate thread. If the X server is drawing with GL, then the target GL drawing objects should be reachable by other GL applications. If the X server is drawing through another mechanism, we'll need to create a way to label X pixmaps with GL names. There are already two groups working on GL-based compositing managers, so we'll want to have this sooner, not later... Yes, if the composite manager grabs the server while updating the screen, then everything will be fine. Your sample xcompmgr doesn't grab the server when updating the screen, and I expect many future composite managers will use xcompmgr as a starting point. Fortunately, it's easy to add the grabs. And, it might fix some other problems I've seen... The existing compositing manager code needs to be replaced; it served as a test bed for many different ideas, some of which negatively affected the overall structure. That seems possible. However, that seems like a lot to ask of all window managers. Would common functionality like that be better contained within an X server extension? Not an extension (there's no need), but surely a library would be useful. I've briefly looked into creating a library to help build compositing managers and composite-aware applications. It could pretend the overlay port was busy for new apps and silently translate an existing overlay application to textures. Interesting; this will require some more thought. Yeah, it would be nice to just say overlays are dead, use textures, but overlays remain an important option in many environments (better color, more features, higher performance). So, I think we need to permit them, but find a way to cut over to textures where necessary. -keith pgpugKdlvFYRs.pgp Description: PGP signature
Re: [Xorg] Damage/Composite + direct rendering clients
Around 14 o'clock on May 18, Soeren Sandmann wrote: What if another client has already grabbed the server for whatever reason? Is screen updating then turned off? Currently, yes. We need to fix this... -keith pgpz4qSyLtMVU.pgp Description: PGP signature
Re: Mode manager / Framebuffer management
On Maw, 2004-05-18 at 01:07, Vladimir Dergachev wrote: Alan, perhaps I am missing something, but 4Mb seems a little low. 1280x1024 at 32bpp takes up 5Mb. Or is it a really old card ? Its an old card but happens to have public docs so its one I can talk about without having to work out if there are NDA's involved. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Damage/Composite + direct rendering clients
Around 18 o'clock on May 18, Egbert Eich wrote: It may in fact be necessary to make some 'priviledged' clients like the composition manager immune to server grabs. Yup. Then we'll need some kind of 'super grab' to keep multiple ones of those from stepping on each other. And recurse. -keith pgpuu3gCrut9J.pgp Description: PGP signature
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
--- Alan Cox [EMAIL PROTECTED] wrote: On Maw, 2004-05-18 at 01:13, Jon Smirl wrote: 1) Boot console. This is implement via BIOS support. It is used to printk a processor initialization failure or failure to find initramfs. Some embedded systems might have to build one of these into the kernel but not a normal desktop machine. This is the kind of console you use to write grub/lilo. It looks like all non-86, non-Mac archs already have this. We can't use the BIOS that late. Currently the set up we have is that the normal console kicks in after PCI setup, and might be vga text mode, frame buffer or whatever. This is your system console and probably where predefined modes are used for nonvga devices, no acceleration and so on. We also have an early_vga PC console hack, and firmware console drivers that can kick in earlier (normally for debug) depending upon the platform. In the PC case the 16bit bios console services go away too early but EFI might provide help here if its ever adopted. Thats analogous to your bios console I guess ? Boot console is a platform specific problem. It's only purpose is to get out an error message saying that the system console can't be found or some other similar type error. Agree with this level. The kernel provides the tty layer (Unix 98 ttys) and might need some userspace apps tweaking a little too - no big problems. I was thinking ptmx/pty, or do you want to use tty? With ptmx/pty you can get rid of the tty devices. When User console is up it is using the full OpenGL driver. xserver would use the same OpenGL driver. The User console app and xserver could even be the same program. If User console/xserver dies, you can always user SAK to relaunch if it doesn't happen automatically. s/OpenGL/Some drawing library/ - providing its using the kernel interfaces we don't care what. (eg the bogl console driver is very small, the opengl one would probably be rather larger and nicer) I wasn't thinking that the kernel interface was standardized. For example DRM has some common IOCTLs and then hundreds of per chipset ones. There is no standard bitblt or draw char IOCTL. I definitely don't want to try sharing the device driver on VT switch, that will take us right back to where we are. Each device should have a single client library driving it at a time. But this works if the program implement VT switch is the owner of the device. So you don't have any problem with pulling VT support out of the kernel? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
On Maw, 2004-05-18 at 21:14, Jon Smirl wrote: I was thinking ptmx/pty, or do you want to use tty? With ptmx/pty you can get rid of the tty devices. You need the tty devices for the boot/kernel console and the code specifc to them is tiny. For the usermode one its clearly ptmx/pty I wasn't thinking that the kernel interface was standardized. For example DRM has some common IOCTLs and then hundreds of per chipset ones. There is no standard bitblt or draw char IOCTL. The DRM layer provides the needed basic kernel services, be they standardised or not. The question of what library is used really doesn't matter. Yes someone would have to write a lot of code for many chips with DRI and chip specific code - but thats up to them. I definitely don't want to try sharing the device driver on VT switch, that will take us right back to where we are. Each device should have a single client library driving it at a time. But this works if the program implement VT switch is the owner of the device. So you don't have any problem with pulling VT support out of the kernel? You need the code to handle video context switches. You also need vt's because you have multiple security contexts on the PC console and good reason to keep that when using SELinux. VT switch is easy however. DRI+X already handles that, and we never have two people using the VT at once. Its one device, multiple handles only one currently active - like many other drivers --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Around 19 o'clock on May 18, Alan Cox wrote: VT switch is easy however. DRI+X already handles that, and we never have two people using the VT at once. Its one device, multiple handles only one currently active - like many other drivers No thoughts to supporting multiple sets of VTs, one per physical device then? -keith pgpflcVLboxvW.pgp Description: PGP signature
Re: [Xorg] Damage/Composite + direct rendering clients
Jim Gettys writes: Which is why avoiding server grabs is imporant, as much as possible. It takes a global lock out on the X server and needs to be used with great care. But you cannot rule out that some legacy client apps don't use server grabs for strange purposes. It may in fact be necessary to make some 'priviledged' clients like the composition manager immune to server grabs. Cheers, Egbert. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Damage/Composite + direct rendering clients
On Tue, 18 May 2004, Keith Packard wrote: Around 1 o'clock on May 18, Andy Ritger wrote: I'm debating whether it is better for the X server to not even know of the damage until it has completed in hardware, or if it is better to tell the X server as soon as the rendering has kicked off, and then require X to wait for completion only when it needs to use the drawable as a source. I don't think we'll be able to know which is best without giving them both a try. I was quite surprised at what method turned out best for the compositing manager -- one has been taught to avoid round trips at all cost, but the lowest latency was accomplished with an XSync call in the middle of the drawing loop. Just goes to show that intuition and reality are often in conflict... Yup; this will require some experimentation to get right, but atleast there are several options. Thanks, - Andy --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: separate blend equation / function on r200
Roland Scheidegger wrote: Ok, here's a patch to enable separate blend function / equation on r200, as well as fix glBlendColor. It needs drm changes, I've tried to make it backward/forward compatible in all ways, except the driver will not build with old drm sources (so this needs to be applied first), I've commited the changes to the drm and dri tree (still not sure if the packet defines really should live in the dri tree, radeon_common.h, too, but I didn't feel like ripping out all the duplicated defines). Since I needed to up the minor version of the radeon drm, if someone else has radeon drm changes which require a new minor version, now would probably be a good time to add them (maybe some more tfactor registers or something like that? The driver seems to lack some as far as I can see...), otherwise you'd just need to update to minor version again later... I haven't checked in the changes to the mesa tree yet, but soon, so you have a day or two left to get a new drm version ;-). Roland --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - good news
Mark Cass wrote: my next question involves extensions. should the GL_ARB_texture_compression and GL_EXT_texture_compression_s3tc extensions be enabled? the only reason i ask is that i think the complete description of the extension includes the ability for the driver to compress the textures. as was mentioned previously, adding this ability to the driver could result in legal problems as s3tc is intellectual property of S3/VIA inc. Technically speaking, ARB_texture_compression should be enabled by *all* drivers. That extension by itself, basically, just gives that app the ability to query which compressed formats are available. Look at the ChooseTextureFormat function in the MGA driver to see how this should work. Keep in mind, the MGA hardware does not support any form of texture compression. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
DRI is definitely working in this build, glxgears is 152FPS on a Rage128. But when I do glxinfo it reports the software driver: OpenGL renderer string: Mesa GLX Indirect Or did someone fix the software render? I used to get about 3FPS with it. Maybe something is broken in the DRI into xorg server integration? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ glxinfo Description: glxinfo Xorg.0.log.gz Description: Xorg.0.log.gz
Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
But when I do glxinfo it reports the software driver: OpenGL renderer string: Mesa GLX Indirect aet LIBGL_DEBUG to all and see if it prints anything.. Dave. Or did someone fix the software render? I used to get about 3FPS with it. Maybe something is broken in the DRI into xorg server integration? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current redhat xorg-x11-Mesa-libGL-6.7.0-2.i386.rpm
It looks like something is not built right... name of display: :0.0 libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.s o: undefined symbol: _glapi_Dispatch) libGL error: unable to find driver: r128_dri.so = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
