Mode manager / Framebuffer management (WAS: Re: [Dri-devel] Memory management of AGP and VRAM)
Mike Mestnik wrote:
Let me start of by saying I think you are on the right track and all of
your ideas look good.
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
How does mergedfb work internally? I don't know.
However we need it to? I think if we cripple X the current mergedfb will
also have to be crippled.
I think this design allows for mergedfb to work however we need it to
by encapsulating all that (setup) logic within the Extended DRM module.
Do you disagree?
Alternatively to this, maybe the best way to do this would be to specify
a double-width mode (eg 2048x768) and an extra feature parameter of
MERGEDFB or some such -- that might work. However, I can't claim to
understand mergedfb (as in, how it's implemented) yet, so this is
probably a naive solution.
I see it more as just a way of pointing a viewport to a framebuffer, like
a screen(FB) swap. What I see is that a FB gets allocated and then modes
get set, with it's viewport looking into this FB. This can all be part of
the modesetting code, then the FB and the viewport should be returned.
That way the FB can be deallocated, after a succsesfull FB change. There
will be rare cases where the card can't handel both FBs then the FB
allocate code might need to handel this NEEDED deallocate/change inorder
to allocate the new/replacing FB.
Hmm, I don't really see any disagreement here. In fact, I think you're
filling in useful missing details in my understanding.
The framebuffer alloc code will be part of the proposed Extended DRM
infrastructure -- which I would rather not be part of (beyond what I
want to do).
Hopefully modes can be set withought FBs this cuts down on the FB
{a,de}lloc code. However inorder to cutdown on card specific code, it may
be best for all cards the deal with worst-case FB alloc, if this is to be
a feature.
All allocation of framebuffers will happen within the kernel. None will
be requested by the mode manager.
- Sharing of FBs should be allowed, for heads on the same card.
Same deal, except instead of a feature of MERGEDFB, the feature
should be CLONE
I don't like the idea of having things so static. Attaching and
deattaching modes(viewports) from FBs should be done via a full API. If
this is at all possible?
I don't know whether it is or not. I kind of like this kind of
simplicity, though -- I think it allows for simply adding numbers if
needed, which would be
- There is no way to ?change?(read as specify) the size of a FB.
If you can specify the resolution, you can specify the size of the
framebuffer. What else did you have in mind?
Size of viewport != FB size, thought I think you got that by the end of my
msg.
Yeah, I understood that.
- Allocating the second/... FB may be difficult,
My comments above and below, as two diffrent cases.
Shouldn't be a problem.
- Have mem free as well as mem total.
This helps with multi-tasking, I.E. Two apps sharing the same VT(context).
For multi-headed cards thay will have to share FB resources.
- Returning hardware capabilitys(like in a termcap type way), not
just
mem sizes. I.E. zbuffer type(how to know it's size).
Allocating a FB on some cards may not be a simple as L*H*D. As I'm not an
expert on hardware I don't know what snags you might hit on, that are not
version but card dependant.
Hmm... I'd love for you to elaborate here, though I -think- I know what
you're getting at.
I wish I could but I realy don't know, it's just something I think the
desing might need. I used the source and saw into the future.
OK; elaborate?
Virtual fb vs Actual FB. IMHO Actual FB is the monitors mode and not the
allocated size of the FB(Virtual fb).
That's the idea.
This is what the mode manager receives:
struct ms_mode {
__u32 xres;
__u32 yres;
__u32 bpp;
__u32 refresh;
};
No FB? This may be positive.
I -did- forget to specify the PCI dev, and the CRTC number (screen
number, whatever). That should be added to the struct -- maybe something
like this:
struct ms_mode {
char * pci_dev;
__u32 crtc_no;
__u32 yres;
__u32 bpp;
__u32 refresh;
};
I can't think of any cases where you'd actually -need- to call the video
BIOS in order to change the framebuffer pointer or offsets (if this were
true, GL would be a nightmare on those cards).
Please. I need more feedback here, people. SPEAK! Destroy my ideas!
Nitpick until this proposal looks like swiss chese! The more feedback
there is, the better it will be.
David Bronaugh
---
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click
--
Re: [Mesa3d-dev] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Sat, May 15, 2004 at 09:27:34AM +0200, Holger Waechtler wrote: Ville Syrjälä wrote: On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote: Does DirectFB work on anything beside Matrox now? It works on any card with a working fbdev driver (vga16fb excluded). Hardware acceleration is available on quite a few chips these days. ati128 cyber5k mach64 neomagic nvidia savage tdfx cle266 i810 matrox nsc radeon sis315 Keep in mind that beside the matrox driver almost none of them implements the full accelerated 2D API cle266 is about the same level as matrox. I could get mach64 into this group with some modifications to the memory allocator. I think for some of the other drivers the biggest problem is lack of developers. and that most are misusing the 3D engine to implement 2D functionality. Alpha blended stretch blits are almost always implemented using the 3D texture engines on PC graphics cards. I don't consider that mis-use, simply use. About one third of these drivers have been written using specs and documentation files that have never been officially released by the hardware vendors, so I'm not really sure whether they are much better from a security point of view than a closed source driver -- what's the point of a open source hardware driver without hardware specs? - you're not really able to review it seriously. I don't think the specs would help in that regard much. For all you know the specs could be all wrong. If you have the code and can see the expected results that usually means the code works correctly. And closed source kernel drivers could do a lot of other nasty stuff even without touching the hardware. The specs for the remaining ones usually showed up as soon the hardware was getting outdated. Basically the same situation like the one you see with DRI drivers. Except now the specs are getting harder to get even for old hardware. The vendors seem to be returning to the old ways :( I use matrox and mach64 drivers daily. It's been a few years since I seriously used XFree86. Have you ever thought about the inherent security risks of memory mapped i/o registers when executing non-trusted applications? Imagine what happens if every single application is allowed to program the blitter and texture engines to copy host memory from anywhere in the system to graphics memory and back - a single misbehaving application can damage your entire system. I am aware of the risks. Currently it's not an issue for me. And if I limit myself to running only XDirectFB the risk is equal to running accelerated XFree86. Of course I would be glad to make it all secure but only without losing any of the nice features. And do you really have the time to review every line of code you execute on your system? Clearly not. There is some stuff you just have to trust (or not care). 2) mesa supports a broad number of cards, basically everything there is doc for Just about as broad as DirectFB. be honest. I am. This is the list of drivers in Mesa cvs: i810 mga radeon tdfx ffbi830r128 savage unichrome gamma mach64 r200 sis The list is almost the same as the DirectFB driver list. Granted that some of the Mesa drivers use more of the hardware's capabilities, but that's only because I don't have the hardware ;) I'm not suggesting that everyone start using DirectFB. Everyong should be able to use any API they want. The kernel should provide just enough to allow these APIs to be implemented. that would be always possible, don't worry. I do worry a bit because of this OpenGL as the one and only API talk. Please keep in mind that we developed DirectFB at Convergence as API to access SettopBox and Game Console functionality in a convenient way, it was never intended and has not been designed for use in security-critical desktop or workstation environments. I am aware of that and that's why I don't recommend it to everyone. Personally I just find it to my liking. Even the code itself makes me a happy camper whereas XFree86 code gives me a headache... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - REALLY CLOSE
Hi Mark, Your description of the problems sounds like the tiling code does the right thing. However, in the driver there were originally some constants for 4bit per pixel texture formats. I thought they were for compressed texture formats. For example one of the texture formats is named TFT_S3TC4Bit. There are now some guessed numbers in the tileInfo_*[0] for 4bit texture formats. They are completely untested as the driver didn't support any such texture formats so far. Have you tried playing with these? Felix On Fri, 14 May 2004 18:30:24 -0700 Mark Cass [EMAIL PROTECTED] wrote: guys, as i have mentioned before i am working on adding s3tc texture compression support to the savage driver. i have added code to the savage driver based upon the radeon driver (and patches). the code i have added only supports uploading pre-compressed textures. as also previously mentioned, i have tested the code and texture on a different computer that uses nvidia's driver and everything works. as it stands now, i have the compressed texture showing up but it does not look right. the colors are all messed up. the proportions and layout of the texture are correct. i set the size of the texture from the compressedSize variable in the texture struct. i set the width and height from the formulas in the radeon driver. width = (ImageWidthUncompressed / 4) x 16. height = ImageHeightUncompressed / 4. the 16 in the width formula is used for DXT3 and DXT5, 8 is used for DXT1. this width and height are used as input to the tile upload code, as well as inputs to the texture registers (width height in power of 2). i have tried using all possible internal formats for s3tc, as enumerated in savage_bci.h, but none make the picture look any better. in fact, most make it look worse so i think i have these right. i have also tried using a diffeerent bytes per texel which affects how the tiles are uploaded. currently i am using 1 byte per texel. it seems that the right amount of data is getting uploaded. i have played with the formulas (i.e. width and height just divided by 4 instead of the current disproportional values) and the texture appears distorted in proportion and composition. does anyone have an idea? mark | 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: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - REALLY CLOSE
there is also an s3tc width field in the tiled surface regs (0x48c40, etc.). you may need to mess with that. Alex --- Felix Kühling [EMAIL PROTECTED] wrote: Hi Mark, Your description of the problems sounds like the tiling code does the right thing. However, in the driver there were originally some constants for 4bit per pixel texture formats. I thought they were for compressed texture formats. For example one of the texture formats is named TFT_S3TC4Bit. There are now some guessed numbers in the tileInfo_*[0] for 4bit texture formats. They are completely untested as the driver didn't support any such texture formats so far. Have you tried playing with these? Felix On Fri, 14 May 2004 18:30:24 -0700 Mark Cass [EMAIL PROTECTED] wrote: guys, as i have mentioned before i am working on adding s3tc texture compression support to the savage driver. i have added code to the savage driver based upon the radeon driver (and patches). the code i have added only supports uploading pre-compressed textures. as also previously mentioned, i have tested the code and texture on a different computer that uses nvidia's driver and everything works. as it stands now, i have the compressed texture showing up but it does not look right. the colors are all messed up. the proportions and layout of the texture are correct. i set the size of the texture from the compressedSize variable in the texture struct. i set the width and height from the formulas in the radeon driver. width = (ImageWidthUncompressed / 4) x 16. height = ImageHeightUncompressed / 4. the 16 in the width formula is used for DXT3 and DXT5, 8 is used for DXT1. this width and height are used as input to the tile upload code, as well as inputs to the texture registers (width height in power of 2). i have tried using all possible internal formats for s3tc, as enumerated in savage_bci.h, but none make the picture look any better. in fact, most make it look worse so i think i have these right. i have also tried using a diffeerent bytes per texel which affects how the tiles are uploaded. currently i am using 1 byte per texel. it seems that the right amount of data is getting uploaded. i have played with the formulas (i.e. width and height just divided by 4 instead of the current disproportional values) and the texture appears distorted in proportion and composition. does anyone have an idea? mark | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - REALLY CLOSE
Felix, i think the texture formats you are talking about are the ones enumerated in savage_bci.h . i tried all of them. NEWS BULLETIN: i set the textBytes to 4 and i now have the correct colors. i think this works because each texel block (4x4 texels) in a DXT3 or DTX5 is compressed to a four byte value. but now the image looks warped! mark - Original Message - From: Felix Kühling [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Mark Cass [EMAIL PROTECTED] Sent: Saturday, May 15, 2004 5:25 AM Subject: Re: savage texture compression - REALLY CLOSE Hi Mark, Your description of the problems sounds like the tiling code does the right thing. However, in the driver there were originally some constants for 4bit per pixel texture formats. I thought they were for compressed texture formats. For example one of the texture formats is named TFT_S3TC4Bit. There are now some guessed numbers in the tileInfo_*[0] for 4bit texture formats. They are completely untested as the driver didn't support any such texture formats so far. Have you tried playing with these? Felix On Fri, 14 May 2004 18:30:24 -0700 Mark Cass [EMAIL PROTECTED] wrote: guys, as i have mentioned before i am working on adding s3tc texture compression support to the savage driver. i have added code to the savage driver based upon the radeon driver (and patches). the code i have added only supports uploading pre-compressed textures. as also previously mentioned, i have tested the code and texture on a different computer that uses nvidia's driver and everything works. as it stands now, i have the compressed texture showing up but it does not look right. the colors are all messed up. the proportions and layout of the texture are correct. i set the size of the texture from the compressedSize variable in the texture struct. i set the width and height from the formulas in the radeon driver. width = (ImageWidthUncompressed / 4) x 16. height = ImageHeightUncompressed / 4. the 16 in the width formula is used for DXT3 and DXT5, 8 is used for DXT1. this width and height are used as input to the tile upload code, as well as inputs to the texture registers (width height in power of 2). i have tried using all possible internal formats for s3tc, as enumerated in savage_bci.h, but none make the picture look any better. in fact, most make it look worse so i think i have these right. i have also tried using a diffeerent bytes per texel which affects how the tiles are uploaded. currently i am using 1 byte per texel. it seems that the right amount of data is getting uploaded. i have played with the formulas (i.e. width and height just divided by 4 instead of the current disproportional values) and the texture appears distorted in proportion and composition. does anyone have an idea? mark | 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: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=ick -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Getting a DRM right from the start
Hi, I'm using a few spare hours to get started working on the Savage DRM driver. I'm going to have to rewrite it from scratch. The current sarea definition is essentially copied from the MGA driver and the only 3 driver-specific ioctls are not (and probably won't be) used by the current 2D/3D drivers. ;-) To get started I have to clean up the savage_sarea structure and define structures for ioctl arguments and such stuff. I looked around in some existing DRM header files, mostly MGA. At first I was a bit confused about how things fit together and recent comments about fixing 64-bit issues and reorganizing DRM header files added to that confusion. I'd like to get this DRM right from the start. So any advice would be welcome. Below is my current understanding about how things _should_ be. === Header files in the DRM === drm.h: driver-independent types and definitions for the 3D driver to communicate with the DRM. drmP.h: driver-independent internal types and definitions. savage_drm.h: any definitions needed by the 3D driver to communicate with the DRM (sarea, sarea defines, ioctl parameter structures). Someone recently proposed to use a sanitized copy of this file (and probably drm.h) in the 3D driver instead of the kernel header file. That would mean that these definitions have to be kept in sync in 3 places: kernel, sanitized user-space copy and Xserver (see below). Does that make sense? savage_drv.h: driver-internal data types like the dev_private structure and function prototypes, some macros for BCI access. savage.h: DRM template customization === Header files in the Xserver === savage_sarea.h: Basically a copy of the sarea defines and sarea structure in the kernel but with different naming conventions. I vaguely remember that this was because of XFree86's policy not to use external header files or something such. savage_common.h: Ioctl parameter structures with XFree86 naming conventions. Same rationale as for savage_sarea.h, I guess. The sarea defines are protected by a macro __SAVAGE_SAREA_DEFINES__. This looks like it should be possible to include savage_sarea.h and savage_drm.h in the same source file. I havn't found any example of that though. Is this an artifact from early DRI/DRM days? === 64bit issues === Basically any fields in data structures shared between kernel and user-space must have a fixed size in order to allow 32-bit user space to work with a 64-bit kernel. Is that correct? Then what are the right types (u32, __u32, uint32, ...?) that are available in both the kernel (possibly linux and BSD) and user-space? Or if we're not going to share header files between kernel tree and 3D drivers, then what types would be used in the kernel and which types in user-space? For keeping the DRM portable among OS's, should fixed-size number types be defined in drm.h/drmP.h? TIA for any feedback, Felix | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage texture compression - REALLY CLOSE
On Sat, 15 May 2004 13:30:16 -0700 Mark Cass [EMAIL PROTECTED] wrote: Felix, i think the texture formats you are talking about are the ones enumerated in savage_bci.h . i tried all of them. I was talking about the parameters that are used by the tiling functions for various texture formats. They are defined at the beginning of savagetex.c, called tileInfo_pro and tileInfo_s3d_s4. The first line applies to 4bit texture formats (supposedly the compressed ones). NEWS BULLETIN: i set the textBytes to 4 and i now have the correct colors. i think this works because each texel block (4x4 texels) in a DXT3 or DTX5 is compressed to a four byte value. but now the image looks warped! 4 bytes per 16 texels would make 2bit per texel. Weird, then why are these formats called xyz4bit? I'm not sure I understand what you mean with warped. Do you have a screenshot? mark Felix --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 3d driver webpage
I have put up a webpage describing my progress in hacking R300 3d engine at: http://volodya-project.sf.net/R300.php Comments and suggestions are appreciated :) (This includes new items for my TODO list). best Vladimir Dergachev --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
unresolved symbol pci_get_subsys and pci_dev_put
Jut get CVS updated and now can't insert savage.o Using /lib/modules/2.4.26/kernel/drivers/char/drm/savage.o /lib/modules/2.4.26/kernel/drivers/char/drm/savage.o: unresolved symbol pci_get_subsys /lib/modules/2.4.26/kernel/drivers/char/drm/savage.o: unresolved symbol pci_dev_put I only find pci_get_subsys, one time in drm/linux/drm_drv.h ! best regards, -- Sérgio M. B. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: unresolved symbol pci_get_subsys and pci_dev_put
Dave has made some recent changes to DRM that are 2.6 in CVS. He is planning to back port to 2.4 real soon now. --- Sérgio Monteiro Basto [EMAIL PROTECTED] wrote: Jut get CVS updated and now can't insert savage.o Using /lib/modules/2.4.26/kernel/drivers/char/drm/savage.o /lib/modules/2.4.26/kernel/drivers/char/drm/savage.o: unresolved symbol pci_get_subsys /lib/modules/2.4.26/kernel/drivers/char/drm/savage.o: unresolved symbol pci_dev_put I only find pci_get_subsys, one time in drm/linux/drm_drv.h ! best regards, -- Sérgio M. B. --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62alloc_ida84op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-develel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
