Re: [Dri-devel] [Fwd: [Qube-announce] Q for Linux 1.1 alphareleased and LEGO Digital Designer shipped]
On Wed, 2003-07-30 at 19:33, Andreas Stenglein wrote: Am 2003.07.25 18:44:20 +0200 schrieb(en) Doug Rabson: Oh, I meant to say also that if anyone is interested in tracking down and fixing the r200 rendering problems, I can supply full buildable source code to the low-level OpenGL parts of the engine. nice, Im wondering nobody replied. Actually, I think Keith may have fixed the rendering problems in his recent changes to the driver. I haven't had a chance to update and check. maybe your website needs aehmm.. an update Or is it a feature that nobody sees any screenshots before downloading some Megabytes? (1st you have to find this page: http://qdn.qubesoft.com/qdninfo/index.html and then you have to click on engine or tools...) strange page. Yeah, sorry about that. Thats what you get when you let a bunch of programmers write websites, I guess. You can get plenty of screenshots etc. from the main company website at http://www.qubesoft.com/q/appspowered.php --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Fwd: [Qube-announce] Q for Linux 1.1 alphareleased and LEGO Digital Designer shipped]
Oh, I meant to say also that if anyone is interested in tracking down and fixing the r200 rendering problems, I can supply full buildable source code to the low-level OpenGL parts of the engine. On Fri, 2003-07-25 at 14:14, Doug Rabson wrote: For anyone who might be interested, this is the free 3D games engine I mentioned in passing the other week. It hasn't been tested much with DRI drivers on Linux since I mostly use nVidia cards at work. I know that it has rendering problems similar to Neverwinter Nights on the r200. It was built for RedHat 9 but should also install without too many problems on Mandrake 9.1. Have fun with it :-) -Forwarded Message- From: Build Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Qube-announce] Q for Linux 1.1 alpha released and LEGO Digital Designer shipped Date: 25 Jul 2003 13:49:03 +0100 Q for Linux, version 1.1 alpha has been released. http://qdn.qubesoft.com/public/downloads.html This includes everything that's in the Windows release (except media exporters), such as: +) QEngine, the runtime component, +) QSDK, the development component, +) QStudio, our integrated game design, edit and build tool. +) QDemo1, our simple game demo with full source code and media. +) QDemo2, our fully interactive game demo with full source code, media and production guide. +) Extensive samples with full source code. Q for Linux is _free_ to build and ship software, subject to our licensing conditions which are detailed here at http://qdn.qubesoft.com/public/licensing.html. Customers wanting commercial level support for this platform should contact us at [EMAIL PROTECTED] This supplements our platform support of Windows and Xbox, with PS2 support expected Q3 of 2003. == Another product powered by Q has been shipped, LEGO Digital Designer. http://www.qubesoft.com/q/appspowered.php -- Rickey Costas Build Manager Qube Software Ltd. http://www.qubesoft.com ___ Qube-Announce mailing list [EMAIL PROTECTED] http://ml.qubesoft.com/mailman/listinfo/qube-announce --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9200 tester available
On Wed, 2003-07-09 at 16:10, Michel Dänzer wrote: On Wed, 2003-07-09 at 14:11, Martin Spott wrote: Rupert Levene [EMAIL PROTECTED] wrote: On Thu, Jul 03, 2003 at 01:07:28AM +0200, Michel Dnzer wrote: PS: http://levene.dyndns.org/invisible-text/normal.png does show a driver problem - the lighting is wrong with HW TCL - but you didn't report that... ;) Well I'd assumed that _this_ was a software problem since it's a new in the latest version =) Is this a known driver problem? Yes. HW TCL seems to be severely broken in general in the Radeon drivers, which can be worked around by setting the R200_NO_TCL (or RADEON_TCL_FORCE_DISABLE) environment variable. If the scene looks to be too dark, then you can assume it's a driver problem. Why don't you just take a look at the screenshot? The red tiles aren't supposed to be red. This particular problem seems to be caused (or at least amplified) by many light sources. I see this kind of thing with my own 3D software (see http://qdn.qubesoft.com) running on the r200 dri driver. I have a feeling that its something to do with modifying light parameters. In my 3D scenes, we render large numbers of objects, potentially each with different lighting configurations, depending on which light objects are in range of a given object. We call glLightX to modify the parameters of the GL lights many times in a single frame. This appears to be the main problem with the r200 rendering errors. FWIW, my software works very nicely with nvidia hardware/drivers. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9200 tester available
On Sat, 2003-07-12 at 13:42, Dieter Nützel wrote: Am Samstag, 12. Juli 2003 12:29 schrieb Doug Rabson: On Wed, 2003-07-09 at 16:10, Michel Dänzer wrote: On Wed, 2003-07-09 at 14:11, Martin Spott wrote: Rupert Levene [EMAIL PROTECTED] wrote: On Thu, Jul 03, 2003 at 01:07:28AM +0200, Michel Dnzer wrote: PS: http://levene.dyndns.org/invisible-text/normal.png does show a driver problem - the lighting is wrong with HW TCL - but you didn't report that... ;) Well I'd assumed that _this_ was a software problem since it's a new in the latest version =) Is this a known driver problem? Yes. HW TCL seems to be severely broken in general in the Radeon drivers, which can be worked around by setting the R200_NO_TCL (or RADEON_TCL_FORCE_DISABLE) environment variable. If the scene looks to be too dark, then you can assume it's a driver problem. Why don't you just take a look at the screenshot? The red tiles aren't supposed to be red. This particular problem seems to be caused (or at least amplified) by many light sources. I see this kind of thing with my own 3D software (see http://qdn.qubesoft.com) running on the r200 dri driver. I have a feeling that its something to do with modifying light parameters. In my 3D scenes, we render large numbers of objects, potentially each with different lighting configurations, depending on which light objects are in range of a given object. We call glLightX to modify the parameters of the GL lights many times in a single frame. This appears to be the main problem with the r200 rendering errors. FWIW, my software works very nicely with nvidia hardware/drivers. You are free to test with the ATI binary drivers, too. Can you please try it? The ATI OpenGL drivers on windows are pretty broken and I think we also tried their linux drivers with similar results. As far as I can remember, depth buffering was quite broken for some obscure reason. I didn't look into it in any detail because it works fine under DX8 on ATI hardware. BTW Q looks very cool. Are there any plans for Unix versions of Q2Demo? I'm currently in the process of testing an alpha-quality version of Q for linux. I've been using RedHat 9 with nvidia hardware as a reference platform but it ought to work on any rpm-based distribution with gcc-3.2.x and recent versions of libjpeg, libpng, libfreetype2, libxml2 and libqt-3.1. Hopefully I should have something ready for downloading next week sometime. --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Reverse engineering Windows Radeon IGP320/340 driver?
On Tuesday 10 June 2003 6:57 pm, Linus Torvalds wrote: On Tue, 10 Jun 2003, Dave Jones wrote: (In fact the agpgart code really doesn't handle this concept at all due to the extensive usage of aperture type macros/typedefs). Why _is_ that AGP code using those silly thing in the first place? I actually looked at writing an AGP subdriver without using any of the common AGP infrastructure (just writing the insert_entries() and remove_entries() functions directly, without caring about those broken AGP generic helper functions) and it looked _simpler_ than much of the crap that is there now. This is more-or-less how the FreeBSD agp driver works for what its worth. The chipset minidrivers are responsible for initialising the aperture and inserting/removing entries. Common code in the main driver handles the ioctl and kernel programming interfaces. It's sad when the helper functions end up being more bother than help. You are welcome to use the FreeBSD driver as a starting point - just leave my copyright in there :-) -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Reverse engineering Windows Radeon IGP320/340 driver?
On Wednesday 11 June 2003 10:19 am, Dave Jones wrote: On Wed, Jun 11, 2003 at 10:09:10AM +0100, Doug Rabson wrote: This is more-or-less how the FreeBSD agp driver works for what its worth. The chipset minidrivers are responsible for initialising the aperture and inserting/removing entries. Common code in the main driver handles the ioctl and kernel programming interfaces. To be honest, I looked at the FreeBSD agpgart driver a while after I had split out the Linux one into seperate subdrivers, and thought Shit, they got it right first time, why didn't we? It's a *lot* cleaner than the Linux one used to be, and in some parts, still is. Don't beat yourself up - the FreeBSD driver is that way because I studied the Linux driver first. It isn't really 'first time'.. It's sad when the helper functions end up being more bother than help. You are welcome to use the FreeBSD driver as a starting point - just leave my copyright in there :-) In an ideal world, we would have had a common codebase with wrappers for Linux/BSD functionality. The DRI folks seem to have got that bit right at least. Had this happened, FreeBSD would now have AGP3 support too 8-) If I had any systems which used AGP3, I might have done the work already. I write this stuff for fun so stuff doesn't always happen until I actually want it. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] BSD DRM updates
On Thu, May 03, 2001 at 08:53:32PM -0700, Eric Anholt wrote: I've got diffs to get BSD DRM almost compiling for tdfx and mga up on my site. Check bsd-2-0-0-branch diffs (and the drm_agpsupport.h file, I didn't feel like merging linux and bsd agp into a single file right now). They are untested, but getting it to compile is a big step. Code tweaks I see still needing to be done are changing return -ERR type things to DRM_OS_RETURN( ERR ) and dealing with inlines. I'll try out the drivers now that I've got the first set of diffs up. It's in the 4.3-STABLE section with today's date. http://www.teleport.com/~anholt/devel/dri Thanks Eric. I've snapped these up and applied them. I've made another set of changes to track FreeBSD-current. I think some of the first set got lost somehow, probably because I didn't realise that the files in .../bsd/drm/kernel were symlinked from .../linux/drm/kernel. Do you have any objections to me committing them? I don't want to step on your toes. Do you think the drm files should move out of the .../os-support/linux/drm tree? Perhaps .../os-support/drm is a better place? It would be a bit more difficult to do this on the branch I guess. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-2-0-0-branch)
This is great Alan. When this gets closer to working, I would like to try it out. I have a few ideas on how to simplify the authentication code in the drivers. The linux driver relies on being able to track each individual open call to the driver which isn't the way BSD drivers work so I try to look up the auth information using the current PID. I recently realised an alternative way of writing drivers in BSD which would make it possible to track each open call which would make life easier for DRM. - Original Message - From: Alan Hourihane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 27, 2001 11:16 AM Subject: [Dri-patches] CVS Update: xc (branch: bsd-2-0-0-branch) CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ Changes by: alanh@usw-pr-cvs1. 01/04/27 03:16:26 Log message: more OS dependency separation Modified files: xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/: Tag: bsd-2-0-0-branch drm_os_freebsd.h xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/: Tag: bsd-2-0-0-branch drmP.h drm_ioctl.h drm_os_linux.h Revision ChangesPath 1.1.2.7 +77 -3 xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/Attic/drm_os_fre ebsd.h 1.36.2.7 +13 -64 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h 1.4.2.1 +38 -48 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_ioctl.h 1.1.2.6 +78 -1 xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/drm_os_l inux.h ___ Dri-patches mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-patches ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-2-0-0-branch)
On Fri, Apr 27, 2001 at 11:43:45AM +0100, Doug Rabson wrote: This is great Alan. When this gets closer to working, I would like to try it out. I have a few ideas on how to simplify the authentication code in the drivers. The linux driver relies on being able to track each individual open call to the driver which isn't the way BSD drivers work so I try to look up the auth information using the current PID. I recently realised an alternative way of writing drivers in BSD which would make it possible to track each open call which would make life easier for DRM. Definately could use your help when the compilation issues are out of the way. One thing though. We use the copy_from_user and copy_to_user in linux, and I've noticed you didn't do that in the original BSD drivers. You just passed a pointer. Was there a reason for this ? From what I can see - we should be using copyin/copyout ? Is this right (BSD kernel knowledge is very new!). I guess we are talking about ioctls. In BSD (and I think in most ATT derived unix kernels), the kernel handles the copyin/copyout of ioctl arguments. It requires that the data direction and size fields of the ioctl number are correct and it uses that information to copy to/from a kernel buffer. The driver's ioctl routing is actually passed a pointer to a kernel buffer, not the user's pointer. Of course, if the structure passed to ioctl contains pointers to other user data structures, the driver must perform its own copyin. It would be pretty easy to do the copy_from_user/copy_to_user for the linux drivers in common code and I think it would simplify the drivers. ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
