[R300] blended_fountain snapshot
Hi all, The winter holidays are over and I would get busy with regular (but still much fun:) ) things. Thus a bit more detail on the current status of R300 project: First of all there is new snapshot - blended_fountain. I have just tagged it (it was retagged a couple of times couldn't resist making some improvements) so if you are using anonymous CVS access wait a day for SourceForge to catchup. Or, better yet, e-mail me your SourceForge handle so I can add you to the developer list ! blended_fountain: * textures now work more reliably * alpha, color blending and alpha blending work * lessons 06, 07 and 19 from nehe.gamedev.net work correctly (or I can't tell the difference from software rendering except it goes much faster) * code has been restructured and unified which should make it a lot easier to add features and work with vertex and pixel shaders Issues: * we don't know how to set format field for textures. Thus there is a hacking lookup function that matches the format field produces by modified r200 code to what actually works. There is also a code that quickly changes format - so you can notice which value works and tabulate it. An (intended) side effect is a caleidoscopic change for textures with unknown formats. New formats can be added in r300_state.c::translate_texture_formats * Looks like not all polygon primitives are implemented yet - I see this with some of KDE screensavers. New primitives can be added in r300_render.c::r300_get_primitive_type * I occasionally see messages about "not enough vertices", in particular this can be seen with glxgears. They arise when the driver is asked to paint a primitive with fewer vertices than usual - for example I don't know how to paint a QUAD with 2 vertices. (To be precise the end=start+2 in this case.. which to me means we have only 2 vertices) TODO: * other drawing modes (like Gourad shading) need to be added by writing appropriate vertex shaders. the code is already split for that - just add a switch and a bunch of ready shaders * similarly pixel shaders need to be written to take advantage of more than one texture * alternatively, write a compiler for both vertex and pixel shaders. You would probably want to add an extension for ATI cards - or use the existing NV one. I also hear there is an OpenGL standard for shaders - not sure whether it made it into Mesa yet. * The card now draws but putting vertices in the command buffer. This is suboptimal - so a port of vertex buffer code from r200 is in order. Should be straighforward enough there is an example of using vertex buffer in r300_render.c * isolate AOS and texture setup code inside DRM so that DRM driver keeps track of such state. This is important as it is probably the only security issue with the current driver - everything else can be worked around by adding more check in drm driver code. best Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2225] New: Strange Distortion on an r200 card
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2225 Summary: Strange Distortion on an r200 card Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Hello. I have a strange problem that involves distortion of the picture that is displayed. I can reliably reproduce the bug everytime in mplayer by setting the render to gl or gl2 and placing the video into full screen. I can also reproduce the distortion by running a game (ragnarok online) in winex. I have recorded a video of the distortion with my digital camera so you can see what it looks like. The link is here: http://pkgingo.no-ip.com/files/linux/MOV00967.MPG The distortion shape is different depending on whats happening. gl produces a different shape distortion than gl2. WineX produces a different shape than any of the other two as well. I have a radeon 9200 All in Wonder card. I am running Fedora Core 3. If there is any other information you need, please ask and I will answer to the best of my ability. Thank you. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Four level page tables
I tried building DRM for the first time in a month on current
linus-bk. I may have forgotten how the kernel works but this is what
I think is going on...
This function in drm_memory.h has type checking errors:
/home/dri/drm-check/linux-core/drm_memory.h: In function `drm_follow_page':
/home/dri/drm-check/linux-core/drm_memory.h:140: warning: passing arg
1 of `pmd_offset' from incompatible pointer type
static inline unsigned long drm_follow_page(void *vaddr)
{
pgd_t *pgd = pgd_offset_k((unsigned long)vaddr);
pmd_t *pmd = pmd_offset(pgd, (unsigned long)vaddr);
pte_t *ptep = pte_offset_kernel(pmd, (unsigned long)vaddr);
return pte_pfn(*ptep) << PAGE_SHIFT;
}
This is going to need to be adjusted for four level page tables. But I
don't think a function like this should be in DRM, isn't there some
kernel call for doing this?
I also noticed this...
static inline void drm_ioremapfree(void *pt, unsigned long size,
drm_device_t * dev)
{
#if defined(VMAP_4_ARGS)
/*
* This is a bit ugly. It would be much cleaner if the DRM API would
use separate
* routines for handling mappings in the AGP space. Hopefully this
can be done in
* a future revision of the interface...
*/
DRM is never going to pass Linus' sparse checker until AGP ioremap is split out.
Jon Smirl
[EMAIL PROTECTED]
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Maw, 2005-01-04 at 09:18, Alan Hourihane wrote: > The DDX and DRM driver are still in the DRI CVS on the trident-0-0-2 branch. 0-0-2 seems to be empty, but 0-0-1 has code ?> --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: problems compiling xorg cvs Re: drm CVS state...
On Tue, 2005-01-04 at 22:28 +, Sergio Monteiro Basto wrote: > On Tue, 2005-01-04 at 22:07 +, Dave Airlie wrote: > > > > > > After think a little and put dri working with kernel 2.4. > > > The only solution, that I see, to not private users of savage with > > > kernel 2.4, have dri. Is do 2 directory on Xorg tree, one with the code > > > before 2005-01-01 and other for kernel 2.6 > > > > Not really a good idea, the old code was not releaseable or secure, 2.4 is > > a fixes only tree, why do people want new drivers for it? if you are > > running production machines on it you won't want a dodgy DRM driver on > > it... > > > > you can always use CVS to checkout the old code... > > > > Dave. > > Ok I accept that, about releaseable and dodgy DRM drive, I agree. > > but just a tough, about security, nowadays it common say, errors are > security problems, I don't see how could drm be insecure. > DRM can be insecure because some hardware supports things like blitting any chunk of system memory from anywhere to anywhere. So you can't just let apps do anything, you have to verify the command stream somehow. Lee --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: problems compiling xorg cvs Re: drm CVS state...
> > Ok I accept that, about releaseable and dodgy DRM drive, I agree. > > but just a tough, about security, nowadays it common say, errors are > security problems, I don't see how could drm be insecure. Well if you have a multi-user machine, and they have access to the insecure drm, they can write some code to get the graphics card to DMA some root only RAM somewhere else, so things like passwd file contents etc can be gotten at ... it requires some knowledge of the graphics card but it is not beyond a decent hacker... (average script kiddie might have some issues...) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: problems compiling xorg cvs Re: drm CVS state...
On Tue, 2005-01-04 at 22:07 +, Dave Airlie wrote: > > > > After think a little and put dri working with kernel 2.4. > > The only solution, that I see, to not private users of savage with > > kernel 2.4, have dri. Is do 2 directory on Xorg tree, one with the code > > before 2005-01-01 and other for kernel 2.6 > > Not really a good idea, the old code was not releaseable or secure, 2.4 is > a fixes only tree, why do people want new drivers for it? if you are > running production machines on it you won't want a dodgy DRM driver on > it... > > you can always use CVS to checkout the old code... > > Dave. Ok I accept that, about releaseable and dodgy DRM drive, I agree. but just a tough, about security, nowadays it common say, errors are security problems, I don't see how could drm be insecure. -- Sérgio M.B. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 943] Patch to add support for 32bit DRI clients on 64bit machines
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 14:10 --- I also meant to say that if for some reason this is impossible, then these reasons should be raised with the kernel/X people and we find the solution that breaks the least number of working systems My belief at the moment (with no 64-bit machines to validate anything on) is that anything we do will probably break pure 64-bit clients, breaking pure 32-bit clients is of course completely unacceptable but maybe someone can find a way... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 943] Patch to add support for 32bit DRI clients on 64bit machines
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 14:08 --- The big issue is backwards compatiblity, this patch needs to be developed as two separate patches, one for the kernel, then tested with current X releases and submitted via the DRM tree, then one for Mesa and X that can also work with the old drm on normal systems (this isn't so important, you can get users to upgrade their kernel if they are upgrading X just use the DRM versioning, but upgrading your kernel should never break your X/DRI)... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: problems compiling xorg cvs Re: drm CVS state...
> > After think a little and put dri working with kernel 2.4. > The only solution, that I see, to not private users of savage with > kernel 2.4, have dri. Is do 2 directory on Xorg tree, one with the code > before 2005-01-01 and other for kernel 2.6 Not really a good idea, the old code was not releaseable or secure, 2.4 is a fixes only tree, why do people want new drivers for it? if you are running production machines on it you won't want a dodgy DRM driver on it... you can always use CVS to checkout the old code... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: problems compiling xorg cvs Re: drm CVS state...
redirecting to devel ML On Mon, 2005-01-03 at 23:38 +, Sergio Monteiro Basto wrote: > If you're still using Linux 2.4 you need to upgrade that first. After think a little and put dri working with kernel 2.4. The only solution, that I see, to not private users of savage with kernel 2.4, have dri. Is do 2 directory on Xorg tree, one with the code before 2005-01-01 and other for kernel 2.6 thanks, -- Sérgio M.B. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: new hyperz patch
Am Mittwoch, 8. Dezember 2004 00:27 schrieb Roland Scheidegger: > Dieter Nützel wrote: > >>> True for DoomIII, but who can switch the lights ON, finally...? > >>> ;-) > >> > >> That is some weird texcoord problem. (I actually have a one-line > >> workaround for that, which breaks submitting texgen and non-texgen > >> coordinates at the same time more or less completely). > > > > Let me test. > > Attached. I've also included the 2nd one-liner in this patch, don't know > if it changes anything with doom3 (but using swtcl fallback for > gl_sphere_map is very problematic at least in nwn). That works. I only see a litte 'shimmering' in front of me. (over the hands) > >>> 'Zooming' a 3D VTK prog from the upper left corner into a bigger > >>> window in the desktop middle show missing z/buffer > >>> clearing/redraw. > >>> > >>> Was OK before. > >> > >> Hmm, do you have a screenshot of that (or preferably more than one, > >> I'm interested what happens when you move the window from top-left > >> to top-right, bottom-left and bottom-right)? > > > > No zoom, then nothing. > > So if you only move the window, everything is ok? That's weird. Yes. > > After zoom only the lower, left part of the window would be redrawn > > right. In all places. > > > > See our domain ;-) > > > > http://www.nuetzel-hh.de/public > > Looks like if you zoom the window, someone forgets to tell the driver > the new window size. Are you sure this is caused by hyperz, i.e. if you > use hyperz=false it still is wrong? > I'm wondering if it could be ddx-related (you're still using XFree86 > 4.3.99 something, right?) Maybe. I need latest DRI CVS from freedesktop.org. CVS server? I've tried with old VTK version. Still the same. => DRI/XFree > > With viewperf-smp I get mostly empty/black windows with ugsXXX. > > btw are you using pageflip? Sure;-) > I couldn't get correct screenshots with > viewperf with it enabled, though I haven't tried for a while. True. KDE overlay solved without pageflip. But viewperf-smp ugs do not work in anyway. (all empty/black windows). Greetings, Dieter Happy New Year! --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Tuesday 04 January 2005 04:19, Alan Hourihane wrote: > On Mon, Jan 03, 2005 at 06:10:37PM -0500, Adam Jackson wrote: > > On Monday 03 January 2005 18:02, Alex Deucher wrote: > > > Actually it did work at one time, basic stuff like glxgears, at least > > > according to AlanH. > > > > I only said "does not". Present tense ;) > > It should still work on the trident-0-0-2 branch. Shouldn't it ? trident-0-0-2-branch does not have any DRI driver source: /dri/archive$ find trident-0-0-1 -name trident_context.c trident-0-0-1/xc/lib/GL/mesa/src/drv/trident/trident_context.c /dri/archive$ find trident-0-0-2 -name trident_context.c /dri/archive$ I used the trident-0-0-1 tip when I imported the driver into Mesa. trident-0-0-2-branch does seem to have the DDX and DRM bits though. - ajax pgpTXhvagXqf3.pgp Description: PGP signature
[Bug 943] Patch to add support for 32bit DRI clients on 64bit machines
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 09:21 --- I expect that the code no longer applies to the current CVS version. I guess I need to port it again. Furthermore I was going to look into making the backward compatibility handling cleaner. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 943] Patch to add support for 32bit DRI clients on 64bit machines
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=943 --- Additional Comments From [EMAIL PROTECTED] 2005-01-04 07:36 --- Comments? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Tue, 4 Jan 2005, Thomas Hellström wrote: > The VIA CN400 contains the Unichrome Pro "Group A" which, 3D-wise, > should be compatible with the Unichrome, so once the DDX sets up the > chip correctly, 3D should work right out of the box (at least as good as > for the Unichrome). > > The DDX doesn't support the Unichrome Pro fully yet because of lack of > HW samples. Specifically lacking is dotclock setup, 2D accel in some > cases, Xv and XvMC. Since all developers at unichrome.sf.net are unpaid > freetimers, that support is probably not going to happen until VIA or > another commercial user donates a board or two. Ok, thanks for the info. I'm currently underfunded (unemployed) myself otherwise I would gladly donate a board... Best regards Peter K -- We Can Put an End to Word Attachments: http://www.fsf.org/philosophy/no-word-attachments.html --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm issues blocking accelerated indirect GL
Roland Mainz wrote: Adam Jackson wrote: I have a seventh option for you. Feel free to flame me if it sounds stupid ... - Option 7: Run the GLX server as a separate process forked by the Xserver. This way you get rid of the problem with the same library linked into the same process multiple times. Pros: No existing ABIs need to be changed. It would also improve the responsiveness of the Xserver when expensive indirect rendering operations are performed (for instance software fallbacks). This is indeed a major problem. Indirect glxgears is extremely laggy at processing user input (and worse in 6.8 than it used to be...) The current "glxgears" implementation is braindead as it spamms the Xserver with tons of rendering requests to rotate the gear teeth without waiting for any reponses. Somewhere in my queue is a patch which solves that using the original XSync() way (but offers a switch to turn that on/off on demand). Unfortunately it's not the whole story as the GL implementation in the Xserver could prevent the problem via putting itself at the end of the schduler queue after each frame swap. Some GL server implementations do that and get a _far_ better responsiveness with the current 6.8.x glxgears implementation than what the Xorg server currently allows. The direct dri drivers face the same problem and solve it by throttling on swapbuffers to enforce a maximum number of outstanding swapbuffer requests at any point. If the dri.so driver was loaded into the server, it would continue to behave in this way and avoid the problem without any additional work. Keith --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 06:10:37PM -0500, Adam Jackson wrote: > On Monday 03 January 2005 18:02, Alex Deucher wrote: > > On Mon, 3 Jan 2005 17:09:31 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: > > > On Monday 03 January 2005 09:46, Sjoerd Langkemper wrote: > > > > Hello, > > > > > > > > I would like 3D acceleration for my on-board Trident Cyberblade (VIA > > > > PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What > > > > do I have to program in order to get this done? > > > > > > Though there is a trident driver in CVS now, it does not work. The DDX > > > is not DRI-aware and there is no DRM driver. > > > > Actually it did work at one time, basic stuff like glxgears, at least > > according to AlanH. > > I only said "does not". Present tense ;) It should still work on the trident-0-0-2 branch. Shouldn't it ? > > you'd probably need the trident branch from dri > > cvs to get it working, plus I'm not sure which chipsets were > > supported. > > Cyberblade XP only, I believe. Indeed. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 06:02:27PM -0500, Alex Deucher wrote: > On Mon, 3 Jan 2005 17:09:31 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: > > On Monday 03 January 2005 09:46, Sjoerd Langkemper wrote: > > > Hello, > > > > > > I would like 3D acceleration for my on-board Trident Cyberblade (VIA > > > PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What > > > do I have to program in order to get this done? > > > > Though there is a trident driver in CVS now, it does not work. The DDX is > > not > > DRI-aware and there is no DRM driver. > > Actually it did work at one time, basic stuff like glxgears, at least > according to AlanH. you'd probably need the trident branch from dri > cvs to get it working, plus I'm not sure which chipsets were > supported. Exactly. CyberBladeXP is the only one supported. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 05:09:31PM -0500, Adam Jackson wrote: > On Monday 03 January 2005 09:46, Sjoerd Langkemper wrote: > > Hello, > > > > I would like 3D acceleration for my on-board Trident Cyberblade (VIA > > PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What > > do I have to program in order to get this done? > > Though there is a trident driver in CVS now, it does not work. The DDX is > not > DRI-aware and there is no DRM driver. The DDX and DRM driver are still in the DRI CVS on the trident-0-0-2 branch. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
On Mon, Jan 03, 2005 at 09:49:30PM +, Alan Cox wrote: > On Llu, 2005-01-03 at 14:46, Sjoerd Langkemper wrote: > > Hello, > > > > I would like 3D acceleration for my on-board Trident Cyberblade (VIA > > PLE133), in order to run 3D apps (e.g. games and glxgears) faster. What > > do I have to program in order to get this done? > > You would need to write > - Locking hooks for the X server driver for the trident > - A kernel module to supervise the access to the video chip and remove > unsafe commands > - A 3D graphics driver library for MESA > > A few tiny starting points exist in the form of some bad documentation > for the cyberblade and some very early code for an old MESA that was > written by Alan Hourihane and then abandoned before it even drew > triangles. Correction here. It does draw triangles. But that's about it. The documentation is seriously lacking and so bringing up the engine on how to draw triangles is the hardest part. Now that it draws triangles I was going to revisit the Command Queueing engine. I've just never had enough time to devote back to it. NOTE: That the code in Mesa CVS, is for the CyberBladeXP. So it won't work on other CyberBlades. Alan. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting started
Hi Peter Karlsson wrote: On Mon, 3 Jan 2005, Alan Cox wrote: It depends what your interests are. If you want to master 3D graphics driver writing and have six months to spare you can have great fun. If you just want a VIA EPIA with working 3D support then the newer chipset (VIA CLE266) DRI is very close to working and you might want to just upgrade hardware and join that effort ? Just out of curiousity: Is there any support for the VIA CN400 (ongoing/planned)? The VIA CN400 contains the Unichrome Pro "Group A" which, 3D-wise, should be compatible with the Unichrome, so once the DDX sets up the chip correctly, 3D should work right out of the box (at least as good as for the Unichrome). The DDX doesn't support the Unichrome Pro fully yet because of lack of HW samples. Specifically lacking is dotclock setup, 2D accel in some cases, Xv and XvMC. Since all developers at unichrome.sf.net are unpaid freetimers, that support is probably not going to happen until VIA or another commercial user donates a board or two. /Thomas Best regards Peter K
