Re: [Dri-devel] Max texture size
Ian Romanick wrote: On Wed, Mar 27, 2002 at 10:53:48PM +, Keith Whitwell wrote: Actually I think the test is correct, and that I was thinking of 16 bit textures plus a full set of mipmaps at the time. Thus the numbers should be doubled in the 32 bit case, rather than halved for 16 as Leif was suggesting. (This is based on the idea that a full set of mipmaps packs perfectly to take up two times the size of the base texture). That's also not true for all architectures... Ok, that explains a bit. However, in some circumstances we may loose a level. The mipmaps don't double the size, the only increase it by 1/3. Then there are architectures like MGA the can't use all 11 mipmaps. The g400 can according to the docs, I just couldn't get it working... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
To be a bit more specific the 2.4.x sound system now loads something like (on my system) soundcore.o ~ drm_core.o cs46xx.o ~ drm_radeon.o (plus codec modules) Mike Michael wrote: On Thu, Mar 28, 2002 at 10:13:04AM +, Keith Whitwell wrote: Linus is pretty clear that he'd only accept a single module per driver - ie a radeon.o, but not a drm_core.o + drm_radeon.o combo. He hasn't seen alsa or usb then...:) -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Mach64 texture fix
I found that calls to TexParameter were not setting the texture wrapping and texture filter in some cases (where the driver private texture object struct had not already been allocated). This is now fixed and solves the following bugs: Well done! It seems armagetron is really fixed. Sergey PS Just played my first Counter-Strike lunch-time match without rebooting to WinME! No problems noticed at all (800x600). BTW, under WinME/Win2000 people play in Software mode so it's only me who uses 3D acceleration:). There were some problems with sounds - but it's wrong mailing list...:) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
On Thu, Mar 28, 2002 at 09:31:40AM +, Alan Hourihane wrote: On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: Also, we should be able to hide the type in the Linux os support and not need to pass this ? I've just taken a closer look at the xf86drmRadeon.c code, and in drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. Going down this road though, we'll be pushing that back into the 2d/3d code which I don't think is the right way to go. I'm thinking more of Jeff's solution now, and what we could do. If we take a minimalist xf86drm.c which makes the libdrm.a loadable module. Then within xf86drm.c we identify which sub-drm module to load (i.e. the driver's libradeon_drm.a - or something like that) and load it. For the *BSD's this code is a symlink from the Linux directory. I'm losing track of what the goal was with the changes. If it was to remove hw-specifics from the libdrm.a module, then I think Jeff's idea of pushing them into a separate HW-specific module is worth looking at. By doing this, it might even be feasible to make libdrm.a part of the (built-in) OS-support layer. Stepping back a bit, the current model puts different types of dependencies in different places. The XFree86 video driver module contains HW dependencies, but should have no OS dependencies. The libdrm.a module contains both HW and OS dependencies. I guess the aim is to separate that into the HW-dependent and HW-independent pieces? One problem I had with simply changing the libdrm.a interfaces is that it doesn't succeed in making that separation. Something in libdrm.a still needs to know how to translate a HW-specific command into whatever is appropriate for the OS. I.e, there's nothing conceptually different between drmRadeonCPStop(args) and drmCOMMAND(RADEON_CP_STOP, args), unless the token RADEON_CP_STOP can be passed transparently to the HW+OS specific component that will actually do the requested operation. With Jeff's suggestion there would be several components: video driver module(HW specific, OS independent) core libdrm module (HW independent, OS specific, so part of core server?) HW libdrm module (HW specific, OS specific) The question this raises is what do we gain from this? What would actually be in the core libdrm module -- is there enough there to justify separating out the HW-specific parts? If the HW libdrm module could be made HW specific and OS independent, then that would be a big win, and it could even be moved into the video driver module in that case. This would simplify things to the point where the OS-specific parts are built-in to the X server and the HW specific parts are all in the video driver module. David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
On Thu, Mar 28, 2002 at 10:35:16AM -0700, Jens Owen wrote: Alan Hourihane wrote: On Fri, Mar 22, 2002 at 08:03:29 -0700, Jens Owen wrote: Alan Hourihane wrote: On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: I would like to move the device dependent functionality currently included in the drm library back into the device driver layer. My objective is to make sure new driver suites can be independently released without stepping on any components needed by other driver suites. Currently, libdrm contains a mixture of device independent code and multiple device dependent routines. I'm looking for a clean way to split this functionality and restore libdrm device independent, while still providing a mechanism for device specific IOCTL style support directly in device drivers. Could we simply add a drmIOCTL entry point to the DRM library? Then, the packing and unpacking could be done in the drivers. The Linux and BSD implementations would simply wrap the standard IOCTL and future OS ports of the DRI would have a layer, if needed, for emulating an IOCTL. Jens, This is definately a problem that needs sorting out. We certainly need to put the driver specific calls into the 2D ddx portion, and abstract some form of drmIOCTL for the os-support routines. Please go ahead, and I'll certainly help out with this. Alan, Thanks for the feedback. I plan to proceed on this next week. Maybe you can verify it's portability on the BSD branch after I'm done. Actually, just a heads up. The bsd-3-0-0-branch is dead. forget this one. I'm doing whatever changes the BSD stuff needs on the trunk. They're going to be only minor changes now we've got the kernel modules in sync. Alan, As I get closer to having a prototype going, we will probably want some place other than the trunk to try this out; and possibly make sure the prototype works for BSD, I you want to do that. I'd like to get the prototype working and verified portable before doing all the work of converting the huge number of device specific DRM extensions. I've been working from the tcl-0-0-branch code base, but we could make a new branch from the trunk if you'd prefer that. Let me know if you plan on building and verifying the prototype under BSD. If not, I'll probably just continue my work in the tcl-0-0-branch. In the limited time I have at the moment, Yes. I'll help. It'd be worth dragging Eric Anholt into this as he's been doing a lot with this too. Eric - are you reading this ? Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
Alan Hourihane wrote: On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: I'll use the Linux DRM semantics which are: ( (direction) 30 | (size) 16 | (type) 8 | (request) 0 ) where direction is: 0 for none, 1 for write, 2 for read and 3 for both size is: size of record to be transfered type is: 'd' for DRM drivers request is: our OS independent offset Alan, I've gotten away from this encode on the driver side. We'll have four drmCommand* entry points to identify direction. Size is an explicit parameter. Type is embedded in the DRM os specific layer and is always 'd'. Doesn't the request identify it's direction ? request is now an OS independent offset that goes from 0 to 0x3f, and just identifies the DRM command. Also, we should be able to hide the type in the Linux os support and not need to pass this ? Yes. I've just taken a closer look at the xf86drmRadeon.c code, and in drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. Going down this road though, we'll be pushing that back into the 2d/3d code which I don't think is the right way to go. Yes, there is a little more than packing and unpacking. For large routines, complicated routines, we could even share code between 2D and 3D drivers. I'd rather see a few additional binary modules in the existing 2D and 3D drivers than N*M new standalone modules, where N is the number of drivers and M is the number of supported OS's. I'm thinking more of Jeff's solution now, and what we could do. If we take a minimalist xf86drm.c which makes the libdrm.a loadable module. Then within xf86drm.c we identify which sub-drm module to load (i.e. the driver's libradeon_drm.a - or something like that) and load it. For the *BSD's this code is a symlink from the Linux directory. We can already load a kernel module based on name via drmOpenByName, we could just implement another drmSubOpenByName command to load the sub module based on it's name. If the submodule is OS dependent we get in to the N*M combinations, problem. If the submodule is OS independent, it might as well go into the driver. We've also got easy backwards compatibility this way too. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Restoring DRM Library Device Independence
On Thu, Mar 28, 2002 at 02:28:26PM -0700, Jens Owen wrote: David, Alan, Jeff and Kevin, I understand you would prefer a class of modules that are both HW specific and OS specific. Currently, the number of OS's supporting the DRM is 2; and the number of OS's the IHV's care about is 1 (linux x86 to be specific). So, there is no short term problem with persuing your model of having an extra module for each HW and OS combination. No, I'd prefer that the HW and OS specifics be separated as cleanly and completely as possible. I've just had some uncertainties about how the solutions proposed so far achieve that. It is the long term I'm concerned about. If XFree86 aspires to have good 3D support for more than just one or two OS's, then an extra module for each HW and OS combination becomes a problem. Agreed. The drmCommand approach allows OS specifics and HW specifics to be seperated and follows the excellent principle set by the 2D DDX driver. I have completely removed the Linux specifics from the drmCommand interface. Attached is my latest patch against the tcl-0-0-branch. Please let me know if you see any OS portability limitations in this current interface. If you see any portability limitations that can't be fixed, I'll fall back and implement the 300+ combined HW and OS specific sub module approach. This assumes that using OS-independent tokens (like those below), and any associated data structures, can be accepted by a HW-independent layer (drmCOMMAND) and executed correctly. I guess that if the HW-independent component is just a mechanism for passing them transparently through to the kernel component (or equivalent), then that is workable providing all different OS implementations of the kernel component (for given HW) can accept the same set of tokens and data structures. What hadn't been clear to me is whether that's possible/feasible. I guess the HW dependencies in the current DRM library would be pushed up into the video driver (and possibly down into the kernel module). +/* Driver specific DRM command indices + * NOTE: these are not OS specific, but they are driver specific + */ +#define DRM_RADEON_CP_INIT0x00 +#define DRM_RADEON_CP_START 0x01 +#define DRM_RADEON_CP_STOP0x02 +#define DRM_RADEON_CP_RESET 0x03 +#define DRM_RADEON_CP_IDLE0x04 +#define DRM_RADEON_RESET 0x05 +#define DRM_RADEON_FULLSCREEN 0x06 +#define DRM_RADEON_SWAP 0x07 +#define DRM_RADEON_CLEAR 0x08 +#define DRM_RADEON_VERTEX 0x09 +#define DRM_RADEON_INDICES0x0a +#define DRM_RADEON_STIPPLE0x0c +#define DRM_RADEON_INDIRECT 0x0d +#define DRM_RADEON_TEXTURE0x0e +#define DRM_RADEON_VERTEX20x0f David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Maya Testing on New Radeon Driver
On Thu, Mar 28, 2002 at 12:53:06PM -0800, Ian Romanick wrote: #0 0x4309fb0a in CreateContext (dpy=0x8075708, vis=0x0, shareList=0x0, allowDirect=1, contextID=0) at glxcmds.c:165 #1 0x4309fc5d in glXCreateContext (dpy=0x8075708, vis=0x0, shareList=0x0, allowDirect=1) at glxcmds.c:206 It dies because it dereferences vis, which is NULL. The man page for glXCreateContext doesn't say anything about the expected behavior if vis is NULL. Should it return NULL or ... ? I worked around this problem by making CreateContext retun NULL if vis = NULL. This allows Maya to load. The bad news is that it dies shortly thereafter with an assertion failure in Mesa. The only seems to happen when I re-size the window. Maya seems to expect 1280x1024, but I'm running @ 1152x864. If I hit the maximize button to shrink it to my screen, wham! maya.bin: t_imm_api.c:328: _tnl_end: Assertion ctx-Driver.NeedFlush 0x1' failed Program received signal SIGABRT, Aborted. 0x432b2d51 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x432b2d51 in __kill () from /lib/libc.so.6 #1 0x432b2acd in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x432b4138 in abort () at ../sysdeps/generic/abort.c:88 #3 0x432ac179 in __assert_fail ( assertion=0x47040ff8 ctx-Driver.NeedFlush 0x1, file=0x47040fa4 t_imm_api.c, line=328, function=0x47040fef _tnl_end) at assert.c:74 #4 0x46fb3f37 in _tnl_end (ctx=0x890e1d0) at t_imm_api.c:328 #5 0x46fb4031 in _tnl_End () at t_imm_api.c:387 -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: Artefacts on the right and bottom edge of the screen
Hi, when I move a gl window to the right and/or bottom edge of the screen, a one pixel wide line/row is not redrawn correctly. Sometimes parts of previous frames remain visible and even hide new stuff. It looks to me as if the z-buffer is not cleared in that line/row. I can reproduce the problem with the xscreensaver circuit demo, quake2 without fullscreen and quake1. Probably more non-fullscreen apps which draw till the edge of the window. My color depth is 16 bits. I tried the resolutions 1152x864 and 1024x768. While I was experimenting with different color depths I saw some more problems. With 24 bits I see everything like through a mesh, but slightly different meshes in different parts of the screen. It is black in the beginning but it can be overwritten by very close objects like my own gun (sometimes) or the polygons drawn to flash the screen. So it may be z-buffer related as well. With 15 bits colors look strange. I guess the driver generates 16 bit colors and puts them on a 15 bit screen. And in quake3 fullscreen the resolution is not changed. I just get a small quake3 window in the bottom left corner of a black screen. But that might be a problem in the Xvidmode extension, not the DRI. With 15 bits I have the same artefacts on the right/bottom edge. With 24 bits ... I can't tell ;-) Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
