Re: [Xorg] DRI merging
--- Daniel Stone [EMAIL PROTECTED] wrote: On Sun, Jun 13, 2004 at 10:42:58PM -0700, Jon Smirl wrote: X on GL won't ship anywhere for at least a year. It will probably be two years before it is in wide spread use. You can get good 3D cards for $35 now, in two years due to Longhorn all systems will be shipping with them. So? My sister still uses a P120, and is happy with it. Why should she be forced to upgrade? No one is going to force anyone to upgrade. Just continue using the software that you have installed right now. I've watched several people install Windows XP over Win95 and then complain about how slow their machine became. I still own an 8086 based machine with no protected mode, does that mean that Linux should not support protect mode? You can;t look backwards at hardware support, if you do you will never add any new features. I am not suggesting *removing* support, rather *adding* support. Should we get rid of support for sub-AthlonXP-class while we're at it? No-one uses those old pieces of crap. There are plans for supporting non-accelerated cards, but you can't expect them to perform like a decent 3D one. No amount of software is going to make my 8086 play a reasonable game of Quake. Yeah, but windowing systems shouldn't have the same system requirements as Quake. -- Daniel Stone [EMAIL PROTECTED] freedesktop.org: powering your desktop http://www.freedesktop.org ATTACHMENT part 2 application/pgp-signature name=signature.asc = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: never winter nights and i830 texture compression..
radeon/r200 have some 32 Byte alignment restrictions for all textures), though I just noticed a small error in the patch: + case MESA_FORMAT_RGB_DXT1: + t-texelBytes = 2; + textureFormat = (MAPSURF_COMPRESSED | MT_COMPRESS_DXT1); + break; + case MESA_FORMAT_RGBA_DXT1: + case MESA_FORMAT_RGBA_DXT3: + t-texelBytes = 4; + textureFormat = (MAPSURF_COMPRESSED | MT_COMPRESS_DXT2_3); + break; RGBA_DXT1 (if it works correctly or not is a different matter) almost certainly needs to be set to the same values as RGB_DXT1 to get at least somewhat correct results. Also, if texelBytes is used to calculate memory addresses (like mipmap offsets), then the results will be very wrong (since the average texelBytes for RGB_DXT1 and RGBA_DXT1 is just 0.5, for RGBA_DXT3 and RGBA_DXT5 it's 1). the code that works out the offsets and stuff is bogus for the i830 with compressed textures... I've no idea what it should look like really :-) the intel hardware stores things differently than other things, and relies on the pitch and stuff.. I've no docs (and the NDA my company is under may not cover em :-), I'll try and extrapolate logically from the i810 documentation what a sane person would do.. then I'll try random insane things.. Dave. -- 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 the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
So? My sister still uses a P120, and is happy with it. Why should she be forced to upgrade? I think that is a bit petty really, please try and keep this discussion some way in the bounds of logic, at some point you have to throw away older systems, X works on these systems now, we want to build a new version of X that works on top of newer cards using features of these cards, the older systems can still use X as they do now however development will slow on XAA drivers and newer applications will use newer features stopping them from working on the older systems... Just because we develop a new graphics sub-system, it doesn't mean you have to run it, I belive there is space (if we merge fbdev functionality into the drm) to build an XAA Xserver on top of it using the drm to do the mode setting card resetting, pci access and any locking, it just won't run 3D apps, it can still run X/GNOME etc.. Dave. -- 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 the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On 14-Jun-2004, Dave Airlie wrote: So? My sister still uses a P120, and is happy with it. Why should she be forced to upgrade? I think that is a bit petty really, please try and keep this discussion some way in the bounds of logic, at some point you have to throw away older systems, X works on these systems now, we want to build a new version of X that works on top of newer cards using features of these cards, the older systems can still use X as they do now however development will slow on XAA drivers and newer applications will use newer features stopping them from working on the older systems... I think its possible this thread is almost falling into flamewar land. I think this thread has merit, but people's time is being wasted if we get too far off topic. I agree that users sometimes should be forced to upgrade; but I also agree that users should be allowed to keep their old hardware, even if this limit's their options. If someone is just word processing and emailing all day, as long as the machine can physically keep doing this task, I see nothing wrong with this; but God help you if you want to upgrade software, the example p120 is starting to get too old. However, in addition to this, I also believe users should be forced to upgrade software if it improve's their experience, helps developers, and doesnt run any slower. Infact, I believe that a uber-API that combines fbcon and dri/drm (making a unified graphics acceleration and basic hardware access api, which is what we should have had a decade ago...) would not harm the user's experience in any way, infact, using 3D hardware (as opposed to the very much lacking 2D hardware that is really really slow compared to the 2D over 3D API technique (ie, using, say, opengl to draw 2D graphics) when available would make the user's experience that much more rich. Now, I doubt that example p120 has a supported 3D accelerator, so XAA would still have a traditional 2D backend, which would be used here. This 2D XAA backend would, of course, be recoded to use fbcon concepts instead of the (arguably outdated) X11 methods (which all the useful stuff would be folded into fbcon instead, and help all apps, X11-using and fbcon-using alike). So, either way, it would be a win win situation for all users and developers, and users should be forced to upgrade. In summary, (if you wernt paying attention) hardware upgrades are bad, hardware obsolence are good, and software upgrades are good. (And since these software upgrades are free (contexually, as in beer), the user doesnt have to shell out $$$ like they have to with Microsoft, a company famous for obsoleting software, and forcing users up a flawed upgrade path, so X11 and kernel upgrades are doubly good.) -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 signature.asc Description: Digital signature
Re: [Xorg] DRI merging
On Sun, Jun 13, 2004 at 12:13:43PM -0700, Jon Smirl wrote: So if my ideas are so bad, why don't you propose your own solution to the Longhorn problem? I have no attachment to anything I've proposed, I'll work on any solution that solves the main problem. Project Utopia, fixing window managers to do things like use XSync() whereever possible, migrate toolkits to use XCB and hand-optimise for common paths, et al. I think that's going to buy you a lot more than X on top of GL, for a lot less work. Because you know why? X on GL still requires not-insignificant work on the desktop to make it workable and coherent. More than what I've proposed, I dare say. -- Daniel Stone[EMAIL PROTECTED] freedesktop.org: powering your desktophttp://www.freedesktop.org signature.asc Description: Digital signature
Re: [Xorg] DRI merging
On Sun, Jun 13, 2004 at 11:44:06PM -0700, Jon Smirl wrote: --- Daniel Stone [EMAIL PROTECTED] wrote: On Sun, Jun 13, 2004 at 10:42:58PM -0700, Jon Smirl wrote: X on GL won't ship anywhere for at least a year. It will probably be two years before it is in wide spread use. You can get good 3D cards for $35 now, in two years due to Longhorn all systems will be shipping with them. So? My sister still uses a P120, and is happy with it. Why should she be forced to upgrade? No one is going to force anyone to upgrade. Just continue using the software that you have installed right now. I've watched several people install Windows XP over Win95 and then complain about how slow their machine became. Right; she still uses Win98. As a distributor as well as an upstream hacker, this prospect makes me deeply unhappy. -- Daniel Stone[EMAIL PROTECTED] freedesktop.org: powering your desktophttp://www.freedesktop.org signature.asc Description: Digital signature
Re: [Xorg] DRI merging
On Sun, Jun 13, 2004 at 10:07:59PM -0700, Jon Smirl wrote: X on GL has no impact on remote X. Tests with glitz show a 100:1 speed improvement for local drawing. ... on 3D-heavy cards, no? I wonder what those same tests would show for the S3 Trio64 my sister runs, or the ATI RageIIC my mother runs. I'm not disparaging your efforts, but: * A first-class windowing system is wasted if all the apps around are crap, or don't make use of it, or both. * Have you tested on lower-end cards, or only the new, insane, 3D-centric cards? A performance hit on already-slow graphics hardware would be bad. -- Daniel Stone[EMAIL PROTECTED] freedesktop.org: powering your desktophttp://www.freedesktop.org signature.asc Description: Digital signature
Re: [Xorg] DRI merging
On Mon, Jun 14, 2004 at 08:00:59AM +0100, Dave Airlie wrote: So? My sister still uses a P120, and is happy with it. Why should she be forced to upgrade? I think that is a bit petty really, please try and keep this discussion some way in the bounds of logic, at some point you have to throw away older systems, X works on these systems now, we want to build a new version of X that works on top of newer cards using features of these cards, the older systems can still use X as they do now however development will slow on XAA drivers and newer applications will use newer features stopping them from working on the older systems... Just because we develop a new graphics sub-system, it doesn't mean you have to run it, I belive there is space (if we merge fbdev functionality into the drm) to build an XAA Xserver on top of it using the drm to do the mode setting card resetting, pci access and any locking, it just won't run 3D apps, it can still run X/GNOME etc.. I just do not see the world that Jon envisions, in which old hardware has simply vanished. I know it hasn't, because there are many machines around me - and my friends, and family, and everyone I know - which are simply incapable of running it. Just because 'the competition'[0] is locking older hardware out, doesn't mean we should, too. I'm all for this new infrastructure which allows us to harness the full power of cards which still cost a reasonable amount in $au (I still own a rv250), but surely there must be some sort of fallback for those of us who are still to get with the program, realise that hardware is cheap, and throw a month's rent at a new computer[1]. :) d, stuck in the technology stone-age[2] [0]: While we're at it, 'us' vs. 'them/you' is petty and unconstructive. [1]: You'd be lucky to include a r3xx in a $au800-$au1k machine. [2]: Communicating with you by the graces of a 56k modem. -- Daniel Stone[EMAIL PROTECTED] freedesktop.org: powering your desktophttp://www.freedesktop.org signature.asc Description: Digital signature
RE: [Xorg] DRI merging
-Original Message- From: Ryan Underwood [mailto:[EMAIL PROTECTED] Sent: 14 June 2004 05:40 To: [EMAIL PROTECTED] Cc: Jon Smirl; Alan Cox; Eric Anholt; Alex Deucher; DRI Devel; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Xorg] DRI merging On Sun, Jun 13, 2004 at 08:47:37PM +0100, Matt Sealey wrote: Having a capable accelerated 2D and 3D architecture, something like DirectFB but at more of a core and commercial level would benefit everyone. Building a single DDX driver to interface with this would simplify support for X - no drivers in the X tree but one! Console Framebuffers could be built on top of the same low-level graphics API. In the end losing the 4-driver system for each card would both simplify and optimise the Linux graphics experience. [..] We need a low-level kernel graphics API (much like Windows has, although Windows favours microkernels with high-level kernel functionality, rather than monolithic kernels with user-level functionality.. the two philosophies are at odds) which can perform and accelerate the expected functionality of everything from router to PDA, past desktop to display of remote-served apps. Careful. I think it is wise to consider the difference between what needs to be in the kernel, versus what is convenient to have an API for. We need something to abstract all the stuff required by 2D and 3D APIs - be it an X client, or OpenGL, or Qtopia, without having 3 different sets of drivers (one for each). While I like the idea that Jon has about using OpenGL as the API for basing X on top of, and while it does have some really quite good 2D functionality (mainly blitting..) I would consider it overkill for a lot of devices. I would plead that we implement Jon's ideas if we have a decent low-end alternative that is better than a flat framebuffer with simple BitBlt acceleration :) For instance, it is possible to have a mode setting API without it being in the kernel -- just have a library that talks to a trusted userspace arbiter. That's fine by me. I guess what we need is a kernelspace HAL that talks to cards which does a lot better than just mode setting, providing a big expanse of memory to write to, given the acceleration functionality of most graphics cards. Simple things like scaled or filtered blits, drawing simple primitives like lines and rectangles. Then we need some userspace thing so that if we have hardware that doesn't have a Radeon 9800 attached to it, we can still get decent graphics performance and don't have to run a 32MB ROM for X or use Xvesa to try and eke reduced space and better performance out of it than the fbdev driver (I love in the man page it says: Xvesa records the current BIOS mode when it starts and restores that mode on termination; if the video card has been reprogrammed by another application, the display will almost certainly be trashed. The alternative of saving and restoring the complete video card state has proven unreliable on most video cards. .. solve it easily by making a decent 2D driver that serves more than X, and targetting X at it, and making it respect DRI? VESA is a nice thing as a rule but it doesn't cooperate very well :) I just mashed this down so its probably half baked. Any thoughts? I half-baked agree with you! I am just looking for an accelerated 2D API that isn't permanently in testing and isn't X. The best place for it, in my opinion, is where DRI and DRM sit now, and while using OpenGL as the basis for display is a cool idea, not every Linux device has decent 3D nor requires it, and the framebuffer device currently sucks. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI CVS tree futures, was Re: [Xorg] DRI merging
Eric Anholt wrote: I am definitely in favor of the DRI X tree stuff being a branch on the X.Org tree. I'd prefer to look at it slightly differently: 1) I'd like to get the current work in the DRI tree to a stable state, meaning: a) finish (or part finish) Ian's NEW_INTERFACE work b) import a stable version of mesa and the drivers into xc/extras, breaking the need to track current mesa. 2) I'd like to see that stabilized Mesa and updated libGL work exported to X.org and XFree86. 3) At this point, the DRI tree will contain nothing not in either X.org or XFree86. Now, people can choose what they would like to do: a) Continue using the DRI tree and all the merge hassles it has involved, potentially with the extra bonus of 2 divergent trees to try and merge with. b) Delete/disable the DRI tree. People who want to work on libGL.so, the 2D DDX or indirect rendering can switch over to X.org where presumably everyone who has demonstrated interest aptitude will be able to secure CVS access. or c) Delete/disable the DRI tree and try and do development by submitting patches to XFree86. After splitting off the drivers to Mesa and DRM to it's own project, I don't see why the remaining X development work (DDX changes, libGL.so evolution, indirect rendering changes, etc) can't just take place in the normal development stream of X.org (or XFree86 for that matter) -- IE. I don't see why there even needs to be a branch for DRI work as opposed to other X, DDX or library work -- the distinction seems artificial. Of course, it's not for me to say how X.org (or XFree86) should be developed, but it does seem like the X development to be done by developers formerly known as DRI doesn't differ in any huge respect from the X development done by others. If some particular project were particularly ambitious in its scope, then yes, a branch might be in order, but I don't think that saying oh, this is DRI stuff, it should go on a different branch to regular X development makes a lot of sense. Keith --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
texture compression may be broken..
texcmp isn't working for me but I can't see what is wrong on my machine, something may have broken it recently... it no longer for me prints the extra info .. can someone test it on a radeon? Dave. -- 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 the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Via DDX for DRI?
On Sad, 2004-06-12 at 00:53, Ian Romanick wrote: I think I would actually prefer it if the 3D were named unichrome_dri.so and the DDX were changed. The reason being that there will likely be future via chipsets that may share the 2D driver but not the 3D. The current situation of ati_drv.o and mach64_dri.so, r128_dri.so, radeon_dri.so, and r200_dri.so shows what I'm talking about. It would have been really confusing if r128_dri.so had originally been named ati_dri.so. I talked to VIA about this in the early days. They pointed at ati_drv.o as an example of why they should be able to use via as the top name for all their chipsets 8) Its also now crept into multiple vendors config/distribution tools and into users config files. The _dri.so file OTOH seems to be fair game without breaking anything, and I agree --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote: The DRM is a kernel driver that allowes the user-apps to use a 3D cards API. Fbdev is smaller then the DRM and will be asimulated and it's functions emulated or replaced. On Linux and FreeBSD only, and there isnt yet a consensus on the Fbdev+DRI+text console+security+hotplug pile other than that it needs to be resolved. Hopefully the kernel summit in July will provide some more definitive answers on plans and once Linus has agreed to something (or destroyed all the ideas one by one 8)) it becomes easier to plan. In the shorter term however the sooner the current DRI is in the current X server the better. The kernel expects recent DRI, many users require it (eg for all modern laptops) with Linux and FreeBSD. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sul, 2004-06-13 at 20:20, Torgeir Veimo wrote: At least he is trying. There's no need for bashing people who try to implement new ideas. I'm not. I'd rather he listened to new ideas and took feedback but that is his business and the community has ways of dealing with that problem that work (see GGI, or Eric Raymonds new kernel config tool) I do however object when he tries to use a research project as an execuse for slowing down a much needed merge of the current DRI code into Xorg. Thats an unrelated issue to the mesa solo work. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sul, 2004-06-13 at 20:35, Jon Smirl wrote: The work that would be wasted is extending the XAA 2D drivers to use the 3D hardware to accelerate render. Lots of hardware can do render without 3D operations. Even my TV capture/playback card has blit-with-alpha on it. Extending existing XAA drivers to do render better via DRI may make sense in some cases and in shorter than two years. As it is everyone is having to merge DRI and Xorg themselves right now to get a working useful tree for 2D and 3D. Getting all the code in the right places makes that work a lot easier, and means for example I can viably attack S3virge and SiS6326 support. (Which you'll want for mesa-solo eventually if only to understand the limits of hardware with only primitive 3D support). There are three main solutions to mode/cursors problem that no one can agree on: 1) leave fbdev in charge of mode setting and cursor, port it around to other architectures. For Linux I think everyone has accepted that you have to have a basic fb driver simply to do hotplug. Xorg however has to run everywhere. 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the work as possible in user space and just pass final register values to the IOCTLs. DRM supports two platforms of the entire X world. In most of the proprietary cases the frame buffer layer is vendor controlled and may or may not be doing this. I guess Alan Coopersmith can comment on this for Solaris x86 for example. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sul, 2004-06-13 at 03:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
On Sul, 2004-06-13 at 20:47, Matt Sealey wrote: Linux basically falls behind on two simple fronts at the moment: it has no simple 2D or 3D framework capable of much more than I deal with embedded Linux people on a daily basis. I think they would disagree. For 2D it has several in heavy use - Keith's tiny X server work - Nanogui (2D down to about 50K RAM) - DirectFB (particularly strong at multimedia) For 3D you end up looking back at the mesa-solo work and it shares that same interest with the X over mesa people. We need a low-level kernel graphics API (much like Windows Unfortunately for a lot of hardware the entire design is different per card. You have to deal with an incredible range of hardware and its a tribute to the X DDX and XAA design how well it has coped with this. I've dealt with very little that X couldn't take a good shot at handling well. YUV422 only framebuffers being the one that gave it serious hiccups. Secondly every line of code you put in the kernel has to be audited, analysed and can introduce security holes or crash the machine. Its harder to debug and its harder to write in the first place. There are very good reasons (see the original DRI paper) for putting as much as you can in user space. The Mesa X work also tries to keep as much as possible in user space - including designs for mode computation by kernel-user callback. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sul, 2004-06-13 at 16:34, Jon Smirl wrote: The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't get to work on a response. Getting mesa-solo running everywhere wouldn't take two years if more people would pitch in and quit arguing. Right now we should have a working xserver/mesa-solo this summer, even sooner if there was more help. This isn't relevant to the Xorg server. need to do is pull everything together. xserver on GL is an architecture that will be good for at least another ten years while the current XAA architecture is close to the end of it's life. You have no solution to non 3D heavy cards, you have no solution to non-Linux hardware platforms. Most of your linux ideas have been thrown out repeatedly as half-baked on multiple lists. mesa-solo is a *research* project. If it works out then in two years time its going to be rather cool. In the mean time trying to stop people doing important work to cripple what you perceive as a rival is just wrong. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sun, Jun 13, 2004 at 05:39:12PM -0700, Keith Packard wrote: Around 20 o'clock on Jun 13, Alan Cox wrote: Secondly every line of code you put in the kernel has to be audited, analysed and can introduce security holes or crash the machine. The same is (alas) all too true for code within the X server as well. An ideal situation would have the X server running unprivledged on top of a kernel driver that validated commands to the graphics card. That's one of the motivations to moving to a DRI-like environment for the X server. Using the OpenGL API provides that in a more vendor neutral way than going directly to DRI. However, even for plain 2D only X servers, I would advocate a similar driver architecture, albiet with a significantly simpler kernel module. Do everything possible in user mode, but no more. It sounds to me that what seems like the solution here is a kernel graphic driver that will implement mode handling, graphic acceleration, etc. User space opengl interface for 3D which will have software fallback where needed and for 2D cards, (I don't know opengl so I don't know what is possible here), either implement whatever is possible of opengl using 2D acceleration and the rest in software, or have a second 2D interface driver. Next for X have a high level opengl output driver and if the second option is the case a 2D accelerated driver (with no acceleration you can just use the software opengl solution). In this case X will only have one or two high level drivers independent of hardware. The hardware will have one set of kernel drivers and one set of user-land drivers where kernel and user-land split the functionality between them as they see appropriate (they would be just two halves of the same driver). There is no need to implement a 2D compatible driver for 3D cards, or 3D drivers for 2D cards, just make users use the appropriate interface above the drivers. This way you get a four level flexible approach with no duplications -keith --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 733] kernel total freeze switching X-fb (matrox)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://freedesktop.org/bugzilla/show_bug.cgi?id=733 --- Additional Comments From [EMAIL PROTECTED] 2004-06-14 06:11 --- (In reply to comment #4) i'll try with more stable settings. ram is ok, it still freeze without preemption. ;( -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: never winter nights and i830 texture compression..
the code that works out the offsets and stuff is bogus for the i830 with compressed textures... I've no idea what it should look like really :-) the intel hardware stores things differently than other things, and relies on the pitch and stuff.. I've no docs (and the NDA my company is under may not cover em :-), I'll try and extrapolate logically from the i810 documentation what a sane person would do.. then I'll try random insane things.. yeah I've tracked it down to the code that copies the images being wrong also, I'll try and work out the correct incantation over the next couple of days for DXT1 and 5 (which NWN uses - this is my main goal after all :-) Dave. -- 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 the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI CVS tree futures, was Re: [Xorg] DRI merging
On Mon, 14 Jun 2004 11:01:59 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: [snip] Of course, it's not for me to say how X.org (or XFree86) should be developed, but it does seem like the X development to be done by developers formerly known as DRI doesn't differ in any huge respect from the X development done by others. If some particular project were particularly ambitious in its scope, then yes, a branch might be in order, but I don't think that saying oh, this is DRI stuff, it should go on a different branch to regular X development makes a lot of sense. Sounds good to me. Work on support for _new_ DRI drivers should definitely go into branches. I'm thinking of the Savage DDX driver in particular. Until the 3D and DRM drivers stabilize the DDX will be changing, sometimes depending on binary incompatible changes in the DRM. I'm wondering where a developer needs CVS access to develop a new DRI driver. DDX changes would go directly to Xorg/XFree86 if the DRI tree died. DRM is in its own repository. What about the Mesa driver? Would it be developped in Xorg/XFree86 or directly in Mesa? I guess it depends in which direction you want to merge changes and in which environment you work. Someone developping on Mesa-solo would not need Xorg/XFree86 CVS access at all. 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 the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PATCH: 2.6.7-rc3 drivers/char/drm/gamma_dma.c: several user/kernel pointer bugs
On Iau, 2004-06-10 at 10:46, Dave Airlie wrote: okay I've checked this into the drm bk tree and DRM CVS, I've no way to test it apart from visual inspection and it compiles, I've asked Linus to sync the drm tree again, I probably need to add some __user annotations in a few places.. I've got an Oxygen GMX somewhere, but last time I investigated the drivers didn't work anyway. Not that fixing the security bits isnt a good idea regardless. I'll try and test it at some point --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texture compression may be broken..
Am Montag, 14. Juni 2004 13:42 schrieb Dave Airlie: texcmp isn't working for me but I can't see what is wrong on my machine, something may have broken it recently... it no longer for me prints the extra info .. You mean the text which mode is running? Works fine on r200. Apart from texcyl (reflect) and celestia errors ;-) -Dieter --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texture compression may be broken..
Am Montag, 14. Juni 2004 17:25 schrieb Dieter Nützel: Am Montag, 14. Juni 2004 13:42 schrieb Dave Airlie: texcmp isn't working for me but I can't see what is wrong on my machine, something may have broken it recently... it no longer for me prints the extra info .. You mean the text which mode is running? Works fine on r200. Apart from texcyl (reflect) and celestia errors ;-) See this, too: http://marc.theaimsgroup.com/?l=dri-develm=108710955623137w=2 -Dieter --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Around 10 o'clock on Jun 14, Matt Sealey wrote: I half-baked agree with you! I am just looking for an accelerated 2D API that isn't permanently in testing and isn't X. I'd like to think that cairo fits in this space; it's not X specific and has acceleratable back-ends for GL and X. -keith pgppTOk1pnPjO.pgp Description: PGP signature
Re: [Unichrome-devel] Re: Via DDX for DRI?
Hi! Ian Romanick wrote: Thomas Hellstrom wrote: Ian Romanick wrote: Where can I get / how can I build a DDX driver for the Unichrome chipset that will work with the DRI drivers? I tried just pulling the code from unichorme.sf.net's xfree86 module into xc/programs/Xserver/hw/xfree86/drivers/via in my DRI tree. I couldn't get that to build even after fixing the types that we've removed (i.e., drmHandle, drmContext, etc.). Is there any chance the folks behind unichrome.sf.net could put something in the DRI tree? :) I want to do some work on the client-side 3D driver, but I need a DRI enabled DDX driver to do it. I'd *much* prefer buildable source over a binary because I think I may have to change some stuff in it. For example, the code that creates GLXvisuals in via_dri.c looks wrong. Not long ago I made a small patch to the dri (xc) tree that made the via client side driver in Mesa build as via_dri.so, and it sort of worked. Glxgears and chromium ran fine, but more complicated things did not; Tuxracer resulted in a blank white screen; in the end, VIA's binary driver worked much better. I eventually used an Xorg build with the 3D driver from the Mesa tree. I saw most of what you're talking about. :) I think I would actually prefer it if the 3D were named unichrome_dri.so and the DDX were changed. The reason being that there will likely be future "via" chipsets that may share the 2D driver but not the 3D. The current situation of ati_drv.o and mach64_dri.so, r128_dri.so, radeon_dri.so, and r200_dri.so shows what I'm talking about. It would have been really confusing if r128_dri.so had originally been named ati_dri.so. Ok. In my pre-sleep hurry last night I checked in a "via" 3d client subdir that builds in the xc tree, but I could change it to "unichrome"? Still, presently we cannot easily change that in the _mainstream_ Unichrome (the project) 2d driver since nearly all of our 3D users are using the binary via_dri.so from VIA (the company). Anyway, I've made a "devel-dri-branch" of the Unichrome 2d driver, that would compile in the current dri xc tree, and that would expect a "unichrome_dri.so" 3d driver. Is there still ( I discussed this with Alex Deucher a while ago ) an interest of having a via 2d driver in the dri xc tree? If so, I could check in the "devel-dri-branch" of the Unichrome (the project) 2d driver and possibly also the XvMC client lib and have it synced with the Unichrome project on a (sort-of) regular basis. Regards /Thomas P.S. the lists.sf.net mail servers are presently giving me "connection refused" so mails will probably get very delayed. D.S. Now, apparently some type names have changed, like drmcontext, which probably in the end also affects unichrome's XvMC dri driver, and the via dri client in Mesa no longer builds in the xc tree. Is there a thread that describes the recent changes? I could try to patch up the unichrome 2d client driver to compile in the dri xc tree. There is, but you're best bet is to just look at the diffs between 1.33 and 1.36 of xc/xc/programs/Xserver/programs/xfree86/os-support/xf86drm.h in the DRI tree. I used a shell script (which is attached) to do most of the grunt work. To replace 'drmContextPtr' with 'drm_context_t *' you would do: sh ./replace_source_text 'drmContextPtr' 'drm_context_t \*' It is *VERY* important to do the Ptr version before the non-pointer version. If you do drmContextPtr first, you'll end up with a bunch of 'drm_context_tPtr' through your source. Basically, you'll want to do this with the Ptr and non-Ptr versions of drmHandle, drmContext, drmDrawable, drmMagic, drmContextFlags, and drmClipRect. There *will* be others in the future, but those are the only ones for now. We're basically trying to get all the types out of xf86drm.h (just leaving prototypes). #!/bin/sh old=$1 new=$2 if [ "$old" = "" -o "$new" = "" ]; then echo Silly rabbit! exit 1 fi grep -lr $old . | while read i do expr='s/'$old'/'$new'/g' sed "$expr" $i x mv x $i done
Re: New i915 driver in cvs
On Iau, 2004-06-10 at 20:50, Alan Hourihane wrote: O.k. I've popped the 2D ddx into XFree86's CVS, followed up by a merge of a snapshot of Mesa 6.1 from back in March time. Along with that, I've also merged in the latest DRM kernel modules in XFree86's tree as well. Is the 915 driver code licensed under an Xorg compatible license and going to go into that tree as well ? --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] Re: Via DDX for DRI?
Sorry for the top reply, but I couldn't get the formatting right. Anyway, perhaps we could use the 3d driver name to differenciate between the drivers: via_dri.so - closed source; unichrome_dri.so - open source. we could then have the DDX probe for one first then the other or we could add an option to choose which. That way the DDX would stay in sync as it gets updated since there'd only be one. Alex - Original Message - From: Thomas Hellstrom [EMAIL PROTECTED] Date: Sat, 12 Jun 2004 08:46:53 +0200 Subject: Re: [Unichrome-devel] Re: Via DDX for DRI? To: Ian Romanick [EMAIL PROTECTED] Cc: DRI developer's list [EMAIL PROTECTED], [EMAIL PROTECTED] Hi! Ian Romanick wrote: Thomas Hellstrom wrote: Ian Romanick wrote: Where can I get / how can I build a DDX driver for the Unichrome chipset that will work with the DRI drivers? I tried just pulling the code from unichorme.sf.net's xfree86 module into xc/programs/Xserver/hw/xfree86/drivers/via in my DRI tree. I couldn't get that to build even after fixing the types that we've removed (i.e., drmHandle, drmContext, etc.). Is there any chance the folks behind unichrome.sf.net could put something in the DRI tree? :) I want to do some work on the client-side 3D driver, but I need a DRI enabled DDX driver to do it. I'd *much* prefer buildable source over a binary because I think I may have to change some stuff in it. For example, the code that creates GLXvisuals in via_dri.c looks wrong. Not long ago I made a small patch to the dri (xc) tree that made the via client side driver in Mesa build as via_dri.so, and it sort of worked. Glxgears and chromium ran fine, but more complicated things did not; Tuxracer resulted in a blank white screen; in the end, VIA's binary driver worked much better. I eventually used an Xorg build with the 3D driver from the Mesa tree. I saw most of what you're talking about. :) I think I would actually prefer it if the 3D were named unichrome_dri.so and the DDX were changed. The reason being that there will likely be future via chipsets that may share the 2D driver but not the 3D. The current situation of ati_drv.o and mach64_dri.so, r128_dri.so, radeon_dri.so, and r200_dri.so shows what I'm talking about. It would have been really confusing if r128_dri.so had originally been named ati_dri.so. Ok. In my pre-sleep hurry last night I checked in a via 3d client subdir that builds in the xc tree, but I could change it to unichrome? Still, presently we cannot easily change that in the _mainstream_ Unichrome (the project) 2d driver since nearly all of our 3D users are using the binary via_dri.so from VIA (the company). Anyway, I've made a devel-dri-branch of the Unichrome 2d driver, that would compile in the current dri xc tree, and that would expect a unichrome_dri.so 3d driver. Is there still ( I discussed this with Alex Deucher a while ago ) an interest of having a via 2d driver in the dri xc tree? If so, I could check in the devel-dri-branch of the Unichrome (the project) 2d driver and possibly also the XvMC client lib and have it synced with the Unichrome project on a (sort-of) regular basis. Regards /Thomas P.S. the lists.sf.net mail servers are presently giving me connection refused so mails will probably get very delayed. D.S. Now, apparently some type names have changed, like drmcontext, which probably in the end also affects unichrome's XvMC dri driver, and the via dri client in Mesa no longer builds in the xc tree. Is there a thread that describes the recent changes? I could try to patch up the unichrome 2d client driver to compile in the dri xc tree. There is, but you're best bet is to just look at the diffs between 1.33 and 1.36 of xc/xc/programs/Xserver/programs/xfree86/os-support/xf86drm.h in the DRI tree. I used a shell script (which is attached) to do most of the grunt work. To replace 'drmContextPtr' with 'drm_context_t *' you would do: sh ./replace_source_text 'drmContextPtr' 'drm_context_t \*' It is *VERY* important to do the Ptr version before the non-pointer version. If you do drmContextPtr first, you'll end up with a bunch of 'drm_context_tPtr' through your source. Basically, you'll want to do this with the Ptr and non-Ptr versions of drmHandle, drmContext, drmDrawable, drmMagic, drmContextFlags, and drmClipRect. There *will* be others in the future, but those are the only ones for now. We're basically trying to get all the types out of xf86drm.h (just leaving prototypes). #!/bin/sh old=$1 new=$2 if [ $old = -o $new = ]; then echo Silly rabbit! exit 1 fi grep -lr $old . | while read i do expr='s/'$old'/'$new'/g' sed $expr $i x mv x $i done --- This SF.Net email is sponsored by the new InstallShield X.
Re: Via DDX for DRI?
Hi Ian Romanick wrote: Where can I get / how can I build a DDX driver for the Unichrome chipset that will work with the DRI drivers? I tried just pulling the code from unichorme.sf.net's xfree86 module into xc/programs/Xserver/hw/xfree86/drivers/via in my DRI tree. I couldn't get that to build even after fixing the types that we've removed (i.e., drmHandle, drmContext, etc.). Is there any chance the folks behind unichrome.sf.net could put something in the DRI tree? :) I want to do some work on the client-side 3D driver, but I need a DRI enabled DDX driver to do it. I'd *much* prefer buildable source over a binary because I think I may have to change some stuff in it. For example, the code that creates GLXvisuals in via_dri.c looks wrong. Hi! Not long ago I made a small patch to the dri (xc) tree that made the via client side driver in Mesa build as via_dri.so, and it sort of worked. Glxgears and chromium ran fine, but more complicated things did not; Tuxracer resulted in a blank white screen; in the end, VIA's binary driver worked much better. Now, apparently some type names have changed, like drmcontext, which probably in the end also affects unichrome's XvMC dri driver, and the via dri client in Mesa no longer builds in the xc tree. Is there a thread that describes the recent changes? I could try to patch up the unichrome 2d client driver to compile in the dri xc tree. /Thomas --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] Re: Via DDX for DRI?
Alex Deucher wrote: Sorry for the top reply, but I couldn't get the formatting right. Anyway, perhaps we could use the 3d driver name to differenciate between the drivers: via_dri.so - closed source; unichrome_dri.so - open source. we could then have the DDX probe for one first then the other or we could add an option to choose which. That way the DDX would stay in sync as it gets updated since there'd only be one. I'm not sure how that would work. The client-side libGL asks the X-server, What's the name of the client-side 3D driver? The X-server either responds that there is none or it sends back foo. The client-side libGL then converts foo to path/foo_dri.so. If that driver fails to initialize, it falls back to indirect-rendering. There isn't anyway for the X-server to say, Try 'foo', and if that fails try 'bar'. I think the easier answer is to have people make a symbolic link from via_dri.so to unichrome_dri.so. :) That's what I did (in the opposite direction) to get the 3D driver in Mesa to work with the 2D driver in Xorg. I don't know how people feel about that, though. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Why not help getting mesa-solo working so that we can move to X on top of OpenGL? Where can I find more information about mesa-solo? Is this the same as miniglx? Keithp is hard at work converting xserver to run on OpenGL. We already have the render engine on top of of OpenGL finished in the glitz project. All we are missing is pbuffer support in the mesa hw drivers and some support for multi-head mode setting. In the xserver on OpenGL model XAA disappears. Does mesa-solo handle multiple rendering surfaces or just a single redering surface that is the whole framebuffer? Are multiple visuals supported? --ms --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
Now that *IS* interesting. I was looking at Cairo for the internals of an SVG renderer, the pluggable backends was what piqued my interest in the first place. Sure.. if there was kernel arbitration for all the features of Cairo needed, accelerated on the graphics card, that would be a cool solution. Portability between X and Framebuffer would be possible, along with OpenGL support you'd have everything you'd need. Okay, I'm done here.. I am about to dig into Cairo ;) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations -Original Message- From: Keith Packard [mailto:[EMAIL PROTECTED] Sent: 14 June 2004 17:25 To: [EMAIL PROTECTED] Cc: Ryan Underwood; Jon Smirl; Alan Cox; Eric Anholt; Alex Deucher; DRI Devel; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Keith Packard Subject: Re: [Xorg] DRI merging Around 10 o'clock on Jun 14, Matt Sealey wrote: I half-baked agree with you! I am just looking for an accelerated 2D API that isn't permanently in testing and isn't X. I'd like to think that cairo fits in this space; it's not X specific and has acceleratable back-ends for GL and X. -keith --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texture compression may be broken..
Dieter Nützel wrote: Am Montag, 14. Juni 2004 17:25 schrieb Dieter Nützel: Am Montag, 14. Juni 2004 13:42 schrieb Dave Airlie: texcmp isn't working for me but I can't see what is wrong on my machine, something may have broken it recently... it no longer for me prints the extra info .. You mean the text which mode is running? Works fine on r200. Apart from texcyl (reflect) and celestia errors ;-) See this, too: http://marc.theaimsgroup.com/?l=dri-develm=108710955623137w=2 Ok. The reason it no longer works is the same as the recent ut2k4 problems, the recent changes in teximage.c. Because the compressed formats are not recognized as color formats, this breaks all online compression (specifically, for QuakeIII the internalformat will be 83a1 (GL_RGB4_S3TC) whereas the format is just GL_RGBA). Brian, could you comment on that? Removing the distinction between compressed and uncompressed color formats (i.e. just adding the compressed formats to the is_color_format function) should solve this I guess, but there is probably a good reason that they are not in there? Roland --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: S3TC/DXTC patch status
Ryan Underwood wrote: On Thu, Jun 03, 2004 at 01:34:58AM +0200, Roland Scheidegger wrote: [EMAIL PROTECTED] wrote: Hi, I'd like to know where is the texture compression now? Has it been integrated to the mesa tree or is it still provided in a separate library ? It is still in a separate library, the legal issues have not changed. Is it possible to integrate s3tc but ship with it disabled, similar to how FreeType operates regarding the hinting patents owned by apple? Then individual distributors can choose whether or not to enable it depending on their location. Integrating it into mesa but ifdef it out is an old proposal, it got rejected. Roland --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: texture compression may be broken..
Roland Scheidegger wrote: Dieter Nützel wrote: Am Montag, 14. Juni 2004 17:25 schrieb Dieter Nützel: Am Montag, 14. Juni 2004 13:42 schrieb Dave Airlie: texcmp isn't working for me but I can't see what is wrong on my machine, something may have broken it recently... it no longer for me prints the extra info .. You mean the text which mode is running? Works fine on r200. Apart from texcyl (reflect) and celestia errors ;-) See this, too: http://marc.theaimsgroup.com/?l=dri-develm=108710955623137w=2 Ok. The reason it no longer works is the same as the recent ut2k4 problems, the recent changes in teximage.c. Because the compressed formats are not recognized as color formats, this breaks all online compression (specifically, for QuakeIII the internalformat will be 83a1 (GL_RGB4_S3TC) whereas the format is just GL_RGBA). Brian, could you comment on that? Removing the distinction between compressed and uncompressed color formats (i.e. just adding the compressed formats to the is_color_format function) should solve this I guess, but there is probably a good reason that they are not in there? I think adding the compressed formats to is_color_format() is the way to go. Whether a format is compressed or not is irrelevant to whether or not it represents RGBA color in this case. I'll check in the fix. -Brian --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2004-06-14 18:16 --- Could anybody tell me when this will be in the actual release of Xfree/Xorg? I would really like to use it in my distro without having to bend over backwards to make it work ;) Thanks! -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Ohh I get it, on non dri OSes there is a PROFORMANCE LOSS!!! --- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote: The DRM is a kernel driver that allowes the user-apps to use a 3D cards API. Fbdev is smaller then the DRM and will be asimulated and it's functions emulated or replaced. On Linux and FreeBSD only, and there isnt yet a consensus on the Fbdev+DRI+text console+security+hotplug pile other than that it needs to be resolved. Hopefully the kernel summit in July will provide some more definitive answers on plans and once Linus has agreed to something (or destroyed all the ideas one by one 8)) it becomes easier to plan. In the shorter term however the sooner the current DRI is in the current X server the better. The kernel expects recent DRI, many users require it (eg for all modern laptops) with Linux and FreeBSD. Alan --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote: The DRM is a kernel driver that allowes the user-apps to use a 3D cards API. Fbdev is smaller then the DRM and will be asimulated and it's functions emulated or replaced. SNIP In the shorter term however the sooner the current DRI is in the current X server the better. The kernel expects recent DRI, many users require it (eg for all modern laptops) with Linux and FreeBSD. Is this another reason to not add functionality to XAA for DRI supported cards? Alan __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 03:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? For one, in the two years that is going to take to bear fruit, we need a working X server. Two because mesa-solo isnt supported on most of the Xorg platforms. Alan Where DRI is not supported it's not used, why should any other driver be forced to work every where? __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] Re: Via DDX for DRI?
On Mon, 2004-06-14 at 20:34, Mike Mestnik wrote: Ohh, is it realy that hard of a feature to add?? foo:bar Old systems try to open path/foo:bar_dri.so and maby thay will fail or there will be a symlink there. A simpl parser could be added, making a new system pars for the ':' and try each one. That solution sounds worse than the problem -- break all new DDX vs old libGL for the sake of one (questionable, IMO) DDX's requirement that could be handled easier with a symlink. The thing to do, if this feature were really desired, would be to extend the XF86DRI protocol. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Xorg] DRI merging
--- Alan Cox [EMAIL PROTECTED] wrote: On Sul, 2004-06-13 at 20:47, Matt Sealey wrote: Linux basically falls behind on two simple fronts at the moment: it has no simple 2D or 3D framework capable of much more than I deal with embedded Linux people on a daily basis. I think they would disagree. For 2D it has several in heavy use - Keith's tiny X server work - Nanogui (2D down to about 50K RAM) - DirectFB (particularly strong at multimedia) I looked at DirectFB and found it not maintained, I could try toget it working with mesa-solo cause the old branch(used in the install docs) is not used. Dose this project even still work, I'd love to try it out. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
The second half of the first paragraph controdics with the first. There are patches and the like avalible. The second sentance is refering to the hotplug code, only needed for multi cards(currently not suported)? Or did you mean something else. Your right about adding interfaces into the kernel, but what's proposed(the non hotplug stuff) is small and relitively uninteresting since it's not used by X. There are no currently pkged programs that would use these extentions so there is nothing stoping a rewrite b4 the user part is released. --- Michel Dänzer [EMAIL PROTECTED] wrote: On Sun, 2004-06-13 at 12:35 -0700, Jon Smirl wrote: 2) copy of the user space code from XFree86 into a standalone library - now you have to be root to play with the chip. 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the work as possible in user space and just pass final register values to the IOCTLs. I would like to see #3. I have implemented #3 locally for the radeon but there is no acceptance for adding it to main DRM drivers. Of course, you neglect to mention the reasons for that. For one, you haven't presented an interface yet that you have shown to remove the need to be root and a significant amount of code from the kernel at the same time. Obviously, immature solutions can't go into the DRM trunk and consequently the kernel because if they don't work out, they can become maintenance nightmares. You have repeatedly been encouraged to develop a prototype system on branches or separate trees though. Don't wait for everyone else to drop everything else. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
Non DRI systems don't support DRI and have XAA instead. We should be free to 'rm -rf' any thing we can replace with something better. I can see XAA getting moved into Mesa(YUCK), but it's posible to do all 2d drawing via OGL calls with a modified Xserver. --- Keith Packard [EMAIL PROTECTED] wrote: Around 21 o'clock on Jun 13, Philipp Klaus Krause wrote: There would be no 2d drivers, only some basic mode switching and cursor support and OpenGL? For systems which would support OpenGL, this would be all that was required. However, we still need to deal with the unwashed masses yearning to run X who don't have OpenGL-enabled systems. For them, we're stuck with a 2D-only driver, perhaps with a bit of Render acceleration to make Composite tolerable on them. -keith ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] Re: Via DDX for DRI?
Yes, is this not the esiest way to extend the protocol, by adding a new field to a string value? --- Eric Anholt [EMAIL PROTECTED] wrote: On Mon, 2004-06-14 at 20:34, Mike Mestnik wrote: Ohh, is it realy that hard of a feature to add?? foo:bar Old systems try to open path/foo:bar_dri.so and maby thay will fail or there will be a symlink there. A simpl parser could be added, making a new system pars for the ':' and try each one. That solution sounds worse than the problem -- break all new DDX vs old libGL for the sake of one (questionable, IMO) DDX's requirement that could be handled easier with a symlink. The thing to do, if this feature were really desired, would be to extend the XF86DRI protocol. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Unichrome-devel] Re: Via DDX for DRI?
What are you talking about?? look... radeon == radeon; radeon:r200 != radeon; /* don't fix it if it ant broke */ For ANY driver that is broke. A simple Makefile update to 'ln -s radeon radeon:r200' gets done where we replace radeon with radeon:r200(The calling funtion) and NOT where radeon(The call-e) is built so it's forward and backward compat. So a fue tweaks here and there it's farely straight forward. I'm amazed that any features ever get added to Linux. --- Eric Anholt [EMAIL PROTECTED] wrote: On Mon, 2004-06-14 at 20:34, Mike Mestnik wrote: Ohh, is it realy that hard of a feature to add?? foo:bar Old systems try to open path/foo:bar_dri.so and maby thay will fail or there will be a symlink there. A simpl parser could be added, making a new system pars for the ':' and try each one. That solution sounds worse than the problem -- break all new DDX vs old libGL for the sake of one (questionable, IMO) DDX's requirement that could be handled easier with a symlink. The thing to do, if this feature were really desired, would be to extend the XF86DRI protocol. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sun, Jun 13, 2004 at 09:24:24PM +0100, Matt Sealey wrote: -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED] Sent: 13 June 2004 20:04 To: [EMAIL PROTECTED] Cc: Jon Smirl; Eric Anholt; Alex Deucher; DRI Devel; [EMAIL PROTECTED] Subject: RE: [Xorg] DRI merging On Sul, 2004-06-13 at 20:47, Matt Sealey wrote: Linux basically falls behind on two simple fronts at the moment: it has no simple 2D or 3D framework capable of much more than I deal with embedded Linux people on a daily basis. I think they would disagree. For 2D it has several in heavy use - Keith's tiny X server work - Nanogui (2D down to about 50K RAM) - DirectFB (particularly strong at multimedia) For 3D you end up looking back at the mesa-solo work and it shares that same interest with the X over mesa people. Agreed, but DirectFB doesn't work with Qt, and the company I work for has a perfectly good OS for multimedia work (http://www.morphos.net :) There was an effor to port QT to DirectFB. I'm not sure what happened to it though. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
