Re: R300: Recovering from lockups
Vladimir Dergachev wrote: Hi Nikolai, I merged your patches - thank you very much ! I wonder if a similar approach could allow us to reset the radeon/r200 after lockups? There's historically been code which tried to do that, but it just never ever worked... Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
ColorOffset: Example usage.
Attached is a screen shoot of the effect of adding 1024 to the ColorOffset. I still have to find where rmesa-state.color.drawOffset comes from and what effect the first 4 bits(define RADEON_COLOROFFSET_MASK 0xfff0) are for(Why RADEON_COLOROFFSET_MASK was missing from _lock.c and _ioctl.c). At this time I also don't see pCliprect[i].x1 being grater then 0, but this could just be my code. With the image it sellf shifting right with the 3d-output-viewport I will need to find where I need to undo this effect. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ inline: ColorOffset+1024.jpg
Re: R300: Recovering from lockups
On Wed, 26 May 2004, Keith Whitwell wrote: Vladimir Dergachev wrote: Hi Nikolai, I merged your patches - thank you very much ! I wonder if a similar approach could allow us to reset the radeon/r200 after lockups? Well, Nikolai's patch is not specific to R300 - it uses plain Radeon registers. There's historically been code which tried to do that, but it just never ever worked... I always thought that the code did work, however since the reset usually happened in DRM driver it did not know how to set the mode. There were quite a few occasions where I was able to kill X and then restart it. (though on other occasions killing X resulted in hard lockup). What's different in Nikolai's patch is that the reset is initiated by X itself. It might be that the lockup was due to clocks being switched off, but the DAC left active - or something similar. best Vladimir Dergachev Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage guide
Is there savage guide with lspci names and numbers (TwisterK 5553:8d02 (rev 01) etc) for cards? take a look a the savage DDX (2d driver). it should give you a pretty good idea of which chips fall into which categories. Also my savage guid should give a you a general idea: http://www.botchco.com/alex/savage/Savage_Guide.txt Those device numbers can be found from lspci homepage :) http://pciids.sourceforge.net/iii/?i=5333 And I think those are just only like serial numbers. edie --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM: Finding kernel and friends on debian.
The current dri.freedesktop.org:/cvs/dri/drm/Makefile is missing support
for debian. What I found shoking is that there is support for SuSE, as
well as RedHat. I don't think it's at all whise to duplicate this work.
Surely there is an autoconf ./configure script that will detect the
distribution and install sutable kernel detection code in the Makefile?
However untill that gets setup the Debian dot-config file is
/boot/config-$(uname -r)/ and the source tree, or maby just the headers,
is at /lib/modules/$(uname -r)/build/(usualy a link to
/usr/src/kernel-{headers,source}-$(uname -r)/). autoconf.h should be
there but version.h may be more difficult to find if only the headers are
avalible.
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM() macro
Why are the DRM() macros used in the linux kernel drivers? I'm sure this has been discussed many times, but I can't find anything about it. Any explanations or pointers to webpages (archives) where it's explained are welcome. Thanks -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM: Finding kernel and friends on debian.
As tehre are no debian specific remarksections the Makefile dose support
Debian. There is no make install function thought.
--- Mike Mestnik [EMAIL PROTECTED] wrote:
The current dri.freedesktop.org:/cvs/dri/drm/Makefile is missing support
for debian. What I found shoking is that there is support for SuSE, as
well as RedHat. I don't think it's at all whise to duplicate this work.
Surely there is an autoconf ./configure script that will detect the
distribution and install sutable kernel detection code in the Makefile?
However untill that gets setup the Debian dot-config file is
/boot/config-$(uname -r)/ and the source tree, or maby just the headers,
is at /lib/modules/$(uname -r)/build/(usualy a link to
/usr/src/kernel-{headers,source}-$(uname -r)/). autoconf.h should be
there but version.h may be more difficult to find if only the headers
are
avalible.
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM() macro
Tomas Carnecky wrote: Why are the DRM() macros used in the linux kernel drivers? I'm sure this has been discussed many times, but I can't find anything about it. Any explanations or pointers to webpages (archives) where it's explained are welcome. Each DRM driver contains a slightly customized copy of some functions. The customzations are based on driver-specific #defines. The DRM macro is used to convert the generic name (i.e., addmap) to a device-specific name (i.e., radeon_addmap). This also makes it so that you can load multiple DRM modules into your kernel at once. If every DRM module had a function called addmap, you could only have one at a time. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM() macro
Ian Romanick wrote: Tomas Carnecky wrote: Why are the DRM() macros used in the linux kernel drivers? I'm sure this has been discussed many times, but I can't find anything about it. Any explanations or pointers to webpages (archives) where it's explained are welcome. Each DRM driver contains a slightly customized copy of some functions. The customzations are based on driver-specific #defines. The DRM macro is used to convert the generic name (i.e., addmap) to a device-specific name (i.e., radeon_addmap). This also makes it so that you can load multiple DRM modules into your kernel at once. If every DRM module had a function called addmap, you could only have one at a time. Thanks... but I personally prefer the fbdev approach. The fbdev core calls the appropriate functions (stored in a structure which is filled by the device drivers). Another question.. what interface do the drivers present to the userspace. Is it only the ioctl interface defined in drm.h or do the device specific drivers have their own ioctl additions? -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM() macro
Tomas Carnecky wrote: Ian Romanick wrote: Tomas Carnecky wrote: Why are the DRM() macros used in the linux kernel drivers? I'm sure this has been discussed many times, but I can't find anything about it. Any explanations or pointers to webpages (archives) where it's explained are welcome. Each DRM driver contains a slightly customized copy of some functions. The customzations are based on driver-specific #defines. The DRM macro is used to convert the generic name (i.e., addmap) to a device-specific name (i.e., radeon_addmap). This also makes it so that you can load multiple DRM modules into your kernel at once. If every DRM module had a function called addmap, you could only have one at a time. Thanks... but I personally prefer the fbdev approach. The fbdev core calls the appropriate functions (stored in a structure which is filled by the device drivers). That still doesn't solve the problem of assigning unique names to N similar-but-slightly-different functions. As a concrete example, look at DRM(setup) in drm_drv.h. Each driver has it's own set of __HAVE_* macros. Which ones are set will determine what code gets generated for DRM(setup). Using a C++ style method dispatch table would get rid of the DRM() macros when the functions are called, but they would still be used to declare the concrete instances. What would that buy (other than the additional overhead of calling through a function pointer)? That said, I'll be the first to admit that the DRM() macros are a pain. It's just not clear to me that there's a clean way to get rid of them without either loss of functionality or more pain. Another question.. what interface do the drivers present to the userspace. Is it only the ioctl interface defined in drm.h or do the device specific drivers have their own ioctl additions? There are the device-independent ioctls in drm.h, and there are device-dependent ioctls in driver name_drm.h. So, radeon_drm.h contains ioctl information specific to the radeon DRM module. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
drawable contexts
As it seems, there is the required code for managment of drawables within the drivers, but noone seems to use it (drm_drawable.h). Any reason for that? (I mean for not using it). -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
device drivers (in general)
The dri/drm interface seems to be quite low-level. I heard somewhere that different devices have quite different registers and work in a quite different way. If it is true that it would be better to make a more high-level interface where every driver can do it's stuff as it needs. How much low/high-level should the interface be so you get the best performance out of these many different devices and don't have to make workarounds in the drivers. I have the impression that the newest cards have quite high-level chips interfaces (supporting shaders etc.). -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
The design priciple of the open-source drivers is that the kernel part acts as nothing more than a conduit to shove bits into the chip. It's the first time I hear that. It is a good design principle for hardware with complicated interface. Because of that, the interface is pretty raw and varies from chip to chip. For DMA programmed chips, the user-mode driver works by filling buffers with stuff and asking the kernel to kick of a DMA operation with the buffer. That's why so much of the ioctl inferface is device-dependent. This doesn't make for workarounds in the drivers, it just means that the user-mode is written to work with its own low-level kernel-mode interface. This reminds me to XFree86. XFree86 requires root rights to run, because it accesses the hardware directly (using /dev/mem) and does other dangerous things. I think that the device driver should avoid that and expose a nice and safe interface to the userspace. DRM does. And it would be possible to expand the range of functions that are safe for unpriveleged access. On advantage of this is that we don't have to modify the kernel drivers very often. Some of the drivers have had regular updates to the user-mode part, but thier kernel driver hasn't been modified in over a year. For us, that's a *big* advantage. This is certainly a very unimportant thing (for me). Because all other parts of the kernel change regularly, why should the graphics drivers not? Well, would you like to be the one to maintain that ? A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc). Harddisk controller is a lot simpler to make use of than a 3d accelerator. Besides, there are only two standards: IDE and SCSI. Same goes for USB and firewire. The device driver should expose an interface, which can be used by all users[1] in a safe way. With the current design, you can't render into a off-screen buffer easily. Either you use X or DirectFB. But it's not possible to use it in a easy and safe way[2]. Look, I would be the first to agree with you - make a good mathematical model for your hardware and then implement the interface in the device driver. The problem is that graphics hardware is changing and just when you made your nice interface you'll get the docs to something new (like programmable pixel shaders) and you have to redesign it. [1]: even /dev/hda or /dev/sda is readable by world (at least on my box). On a personal box this is probably fine. On a public one.. do you want your /etc/shadow file readable ? best Vladimir Dergachev [2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver. -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
Tomas Carnecky wrote: Ian Romanick wrote: Tomas Carnecky wrote: The dri/drm interface seems to be quite low-level. I heard somewhere that different devices have quite different registers and work in a quite different way. If it is true that it would be better to make a more high-level interface where every driver can do it's stuff as it needs. How much low/high-level should the interface be so you get the best performance out of these many different devices and don't have to make workarounds in the drivers. I have the impression that the newest cards have quite high-level chips interfaces (supporting shaders etc.). The design priciple of the open-source drivers is that the kernel part acts as nothing more than a conduit to shove bits into the chip. It's the first time I hear that. Because of that, the interface is pretty raw and varies from chip to chip. For DMA programmed chips, the user-mode driver works by filling buffers with stuff and asking the kernel to kick of a DMA operation with the buffer. That's why so much of the ioctl inferface is device-dependent. This doesn't make for workarounds in the drivers, it just means that the user-mode is written to work with its own low-level kernel-mode interface. This reminds me to XFree86. XFree86 requires root rights to run, because it accesses the hardware directly (using /dev/mem) and does other dangerous things. I think that the device driver should avoid that and expose a nice and safe interface to the userspace. As far as 2D goes, there's been plenty of talk about this. As far as 3D goes, see below. On advantage of this is that we don't have to modify the kernel drivers very often. Some of the drivers have had regular updates to the user-mode part, but thier kernel driver hasn't been modified in over a year. For us, that's a *big* advantage. This is certainly a very unimportant thing (for me). Because all other parts of the kernel change regularly, why should the graphics drivers not? The way it is now works. The only other way that would work is if there were a consistent, defined interface to the driver(s) that DID NOT CHANGE. See below for why this may not be practical. A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc). You're speaking of a generic interface to the hardware. The problem (from what I have seen) with doing this with 3D graphics hardware is that it really -is- all different. Different in design. You -could- put a whole OpenGL driver in the kernel, and that would abstract the hardware successfully, but there are a -LOT- of good arguments against this (bloating the kernel's image size by 2-3 megs would probably not be appreciated -- a LOT of bugs would get in, etc.) Another option would be to design a generic, more low-level wrapper for graphics hardware. In my opinion this is a huge undertaking (ever read chip docs? You try integrating 3000 pages of information (that would be around 5 different chips)). However, if you think this is a good idea, feel free to do it. Just take about 6 months off from life... The device driver should expose an interface, which can be used by all users[1] in a safe way. With the current design, you can't render into a off-screen buffer easily. Either you use X or DirectFB. But it's not possible to use it in a easy and safe way[2]. Actually, there's been a lot of talk about how to fix this kind of thing. Memory management and mode switching is a solvable problem, albeit perhaps not in the nicest way. Nonetheless, I think the current proposals will work. [1]: even /dev/hda or /dev/sda is readable by world (at least on my box). Which is fundamentally insecure. People can find your /etc/shadow file on /dev/hda or whatever and run John the Ripper or its ilk on it. Simple matter of using 'grep'. [2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver. Unneccesary in -your- opinion. How much have you studied it? David I am not a DRI developer Bronaugh --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
David Bronaugh wrote: A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc). You're speaking of a generic interface to the hardware. The problem (from what I have seen) with doing this with 3D graphics hardware is that it really -is- all different. Different in design. You -could- put a whole OpenGL driver in the kernel, and that would abstract the hardware successfully, but there are a -LOT- of good arguments against this (bloating the kernel's image size by 2-3 megs would probably not be appreciated -- a LOT of bugs would get in, etc.) You're right, I had the opengl interface in my mind, but I certainly don't want to put it into the kernel. It's good to separate userspace and kernelspace. Another option would be to design a generic, more low-level wrapper for graphics hardware. In my opinion this is a huge undertaking (ever read chip docs? You try integrating 3000 pages of information (that would be around 5 different chips)). However, if you think this is a good idea, feel free to do it. Just take about 6 months off from life... That's why I think there should be a more high-level interface. My idea is that every card creates a device node in /dev which can be openend by anyone with appropriate rights. With each device is a userspace library associated which has implemented the interface functions (gl*). The interface between userspace library and device node is not defined, each driver/library pair can create's own interface. So it is possible to 1) implement everything in userspace and use the device driver only to access the framebuffer or 2) use hardware acceleration using the device driver. So it's possible that every driver developer can decide for himself what to put into the userspace library and what into the kernel driver. The only interface that is defined is opengl. (Actually, that's not just an idea, but my project. I've done quite a lot of work so far, now I'm looking for some opengl implementations I could use.) [1]: even /dev/hda or /dev/sda is readable by world (at least on my box). Which is fundamentally insecure. People can find your /etc/shadow file on /dev/hda or whatever and run John the Ripper or its ilk on it. Simple matter of using 'grep'. Ahem.. sorry.. I mean readable by anyone who can log into the machine, not many people in my case. And I'm thinking of usual home computers, not servers. (High performance graphics cards on servers?) [2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver. Unneccesary in -your- opinion. How much have you studied it? Just to render a nice picture using opengl (off-screen)? David I am not a DRI developer Bronaugh -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [r200] sigfault in update_light (current DRI and Mesa CVS)
Am Montag, 24. Mai 2004 23:53 schrieb Michel Dnzer:
On Sun, 2004-05-23 at 22:52, Dieter Ntzel wrote:
Program received signal SIGSEGV, Segmentation fault.
0x40670b99 in update_light (ctx=0x805e208) at r200_state.c:1143
1143 for (p = 0 ; p MAX_LIGHTS; p++) {
That doesn't make much sense, I don't see a pointer being dereferenced
here. Please double check your build.
I double checked, now...;-)
SOLVED.
It was -march=athlon-mp related.
With -march=athlon it works.
I've the later in MesaCVS and DRI CVS (host.def), now.
progs/demos gcc --version
gcc (GCC) 3.3.1 (SuSE Linux)
Thanks,
Dieter
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149alloc_id66op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
I think every thing Tomas Carnecky has said here about device driver design is valid and dose apply to the DRM/dri. He may not know every thing about system security, but we also all have our strangths and his strangth is oviously device design. One way of interpeting what he is trying to say is that the DRM should be even lower-level and get back to the basics. There are going tobe alot of gripes and grones, but it's UNIX not windows. ioctl ONLY for registers, even mmaped ones. read/write for DMA. seek for changing where your DMAing or writing to the GART and video mem. select sleeping and waiting. There is no versioning, invalid ioctls will be enuff to find out it's not supported by the card or driver. To identify the modual /proc/devices major number lookups. For security using diffrent minor numbers, 0 for mode setting, 1 for 2d, 2 for 3d, ext. Where 2 has the same modes as /dev/mem and games/users have to be setuid root they do directly access the hardware. The idea is to reduce the kernel mod to nothing more then device enumeration and detection. --- Tomas Carnecky [EMAIL PROTECTED] wrote: Ian Romanick wrote: Tomas Carnecky wrote: The dri/drm interface seems to be quite low-level. I heard somewhere that different devices have quite different registers and work in a quite different way. If it is true that it would be better to make a more high-level interface where every driver can do it's stuff as it needs. How much low/high-level should the interface be so you get the best performance out of these many different devices and don't have to make workarounds in the drivers. I have the impression that the newest cards have quite high-level chips interfaces (supporting shaders etc.). The design priciple of the open-source drivers is that the kernel part acts as nothing more than a conduit to shove bits into the chip. It's the first time I hear that. Because of that, the interface is pretty raw and varies from chip to chip. For DMA programmed chips, the user-mode driver works by filling buffers with stuff and asking the kernel to kick of a DMA operation with the buffer. That's why so much of the ioctl inferface is device-dependent. This doesn't make for workarounds in the drivers, it just means that the user-mode is written to work with its own low-level kernel-mode interface. This reminds me to XFree86. XFree86 requires root rights to run, because it accesses the hardware directly (using /dev/mem) and does other dangerous things. I think that the device driver should avoid that and expose a nice and safe interface to the userspace. On advantage of this is that we don't have to modify the kernel drivers very often. Some of the drivers have had regular updates to the user-mode part, but thier kernel driver hasn't been modified in over a year. For us, that's a *big* advantage. This is certainly a very unimportant thing (for me). Because all other parts of the kernel change regularly, why should the graphics drivers not? A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc). The device driver should expose an interface, which can be used by all users[1] in a safe way. With the current design, you can't render into a off-screen buffer easily. Either you use X or DirectFB. But it's not possible to use it in a easy and safe way[2]. [1]: even /dev/hda or /dev/sda is readable by world (at least on my box). [2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver. -- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland (GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-develel 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click --
Re: device drivers (in general)
--- Tomas Carnecky [EMAIL PROTECTED] wrote: My idea is that every card creates a device node in /dev which can be openend by anyone with appropriate rights. With each device is a userspace library associated which has implemented the interface functions (gl*). The interface between userspace library and device node is not defined, each driver/library pair can create's own interface. So it is possible to 1) implement everything in userspace and use the device driver only to access the framebuffer or 2) use hardware acceleration using the device driver. So it's possible that every driver developer can decide for himself what to put into the userspace library and what into the kernel driver. The only interface that is defined is opengl. (Actually, that's not just an idea, but my project. I've done quite a lot of work so far, now I'm looking for some opengl implementations I could use.) You are rebulding mesa-solo. http://www.mesa3d.org/fbdev-dri.html = 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
Tomas Carnecky wrote: David Bronaugh wrote: Another option would be to design a generic, more low-level wrapper for graphics hardware. In my opinion this is a huge undertaking (ever read chip docs? You try integrating 3000 pages of information (that would be around 5 different chips)). However, if you think this is a good idea, feel free to do it. Just take about 6 months off from life... That's why I think there should be a more high-level interface. My idea is that every card creates a device node in /dev which can be openend by anyone with appropriate rights. With each device is a userspace library associated which has implemented the interface functions (gl*). The interface between userspace library and device node is not defined, each driver/library pair can create's own interface. So it is possible to 1) implement everything in userspace and use the device driver only to access the framebuffer or 2) use hardware acceleration using the device driver. So it's possible that every driver developer can decide for himself what to put into the userspace library and what into the kernel driver. The only interface that is defined is opengl. Essentially, this is what the Mesa/DRI/DRM combo do now (as I understand it; feel free to correct me). (Actually, that's not just an idea, but my project. I've done quite a lot of work so far, now I'm looking for some opengl implementations I could use.) [1]: even /dev/hda or /dev/sda is readable by world (at least on my box). Which is fundamentally insecure. People can find your /etc/shadow file on /dev/hda or whatever and run John the Ripper or its ilk on it. Simple matter of using 'grep'. Ahem.. sorry.. I mean readable by anyone who can log into the machine, not many people in my case. And I'm thinking of usual home computers, not servers. (High performance graphics cards on servers?) I can think of applications. Think render-server with high-powered graphics card as coprocessor. I wouldn't be all that surprised to see CGI apps on the 'net using OpenGL to render stuff within 3 years (if it isn't already done). SVG can't do everything... [2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver. Unneccesary in -your- opinion. How much have you studied it? Just to render a nice picture using opengl (off-screen)? You've studied OpenGL, haven't you? It's rather large. It is (as I understand it) an abstract state machine. It's not fun to map one state machine to another. I haven't done it for graphics cards, but I've done it for network protocols. David Bronaugh --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Development setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 25 May 2004 23:43, Maurice van der Pot wrote: The modifications I made to the driver were visible when I executed an OpenGL app, so I knew it was using the right r200_dri.so. Strangely, I was unable to get most of the debug prints working. The general ones with LIBGL_DEBUG seemed to work, but not the r200 specific ones. Look in r200_context.h for DO_DEBUG, and set it to 1. I assume you've already set the environment variable R200_DEBUG, as well. cu, Nicolai -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtQCKsxPozBga0lwRAitiAJ9opTRg/AbVBlvy6Fq6lyjg5Ji7gACeI9by gqPrSG0hAQi2SdIbn1UFGHQ= =NaxW -END PGP SIGNATURE- --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
Tomas Carnecky wrote: Ian Romanick wrote: Tomas Carnecky wrote: The dri/drm interface seems to be quite low-level. I heard somewhere that different devices have quite different registers and work in a quite different way. If it is true that it would be better to make a more high-level interface where every driver can do it's stuff as it needs. How much low/high-level should the interface be so you get the best performance out of these many different devices and don't have to make workarounds in the drivers. I have the impression that the newest cards have quite high-level chips interfaces (supporting shaders etc.). The design priciple of the open-source drivers is that the kernel part acts as nothing more than a conduit to shove bits into the chip. It's the first time I hear that. Because of that, the interface is pretty raw and varies from chip to chip. For DMA programmed chips, the user-mode driver works by filling buffers with stuff and asking the kernel to kick of a DMA operation with the buffer. That's why so much of the ioctl inferface is device-dependent. This doesn't make for workarounds in the drivers, it just means that the user-mode is written to work with its own low-level kernel-mode interface. This reminds me to XFree86. XFree86 requires root rights to run, because it accesses the hardware directly (using /dev/mem) and does other dangerous things. You must be thinking of UtahGLX. DRI make no such requirement on the user. The reason it doesn't have that requirement is that it has part that lives in the kernel. XFree86 UtahGLX require root because they are completely in user space. I think that the device driver should avoid that and expose a nice and safe interface to the userspace. It does. On advantage of this is that we don't have to modify the kernel drivers very often. Some of the drivers have had regular updates to the user-mode part, but thier kernel driver hasn't been modified in over a year. For us, that's a *big* advantage. This is certainly a very unimportant thing (for me). Because all other parts of the kernel change regularly, why should the graphics drivers not? Because requiring people to upgrade their kernel and 3D driver in lock-step results in a) No benefit to users b) Support headaches for developers whose time is better spent developing. Not only that, putting more stuff in the kernel part makes it more difficult to work on multiple operating systems. The Linux kernel may change every day, but the *BSD kernels do not. A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc). The device driver should expose an interface, which can be used by all users[1] in a safe way. With the current design, you can't render into a off-screen buffer easily. Either you use X or DirectFB. But it's not possible to use it in a easy and safe way[2]. There is a nice interface for using a 3D accelerator. It's called OpenGL. The *entire* driver a disk controller lives inside the kernel. In the case of the 3D accelerator, that is impractical. Part of the *driver* lives in the kernel and part of the *driver* lives in user-space. Nothing about DRI prevents a developer from choosing a different kernel / user split. Based on the size of their kernel modules, I'm pretty sure that both 3dlabs and ATI made a different choice. However, they support Linux only and they aren't distributed with the kernel source. Both of those factors precipitate a different set of technical and practical issues. Because of that, the open-source drivers have the kernel / user split that they have. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: device drivers (in general)
Ian Romanick wrote: Nothing about DRI prevents a developer from choosing a different kernel / user split. Based on the size of their kernel modules, I'm pretty sure that both 3dlabs and ATI made a different choice. However, they support Linux only and they aren't distributed with the kernel source. Both of those factors precipitate a different set of technical and practical issues. Because of that, the open-source drivers have the kernel / user split that they have. Actually, I think you're wrong that ATI made a different choice. Their fglrx kernel module is only ~2 times the size of the radeon kernel module, and that includes their own agpgart. If you subtract that you'll end up with something which is only about 1.5 times the radeon kernel module size. Nvidia OTOH really have a big kernel module, they might have made a different choice, or maybe they integrated some windows device driver emulation code, who knows ;-). They certainly don't follow dri model. Roland --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
