Re: Direct rendering problem with quake2 on Radeon 8500
I think you can spend a lot of time on this problem, but maybe we should check some simpler things first: * which 3D driver are you using? From Xorg CVS or Mesa CVS? The latter one is the most up-to-date. With LIBGL_DEBUG=verbose you can check which driver binary is being used, just in case ... * Are you using any radeon driver options in xorg.conf? Don't use AGP fast writes. Maybe try different AGP speeds. Or maybe a different color depth helps. * Are you using any 3D driver options (driconf)? You may be able to work around some lockups by disabling TCL, HyperZ and/or using different frame throttling methods. * Are you only getting lockups with quake2 or also with other 3D apps? * Which Radeon version do you have exactly? More comments about the hard way below ... Am Donnerstag, den 19.05.2005, 15:27 +0600 schrieb Dimitry Naldayev: > Felix KÃhling <[EMAIL PROTECTED]> writes: > [snip] > >> > >> top - 11:02:53 up 19:53, 8 users, load average: 1.22, 0.57, 0.25 > >> Tasks: 59 total, 3 running, 54 sleeping, 0 stopped, 2 zombie > >> Cpu(s): 0.3% us, 99.7% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% > >> si > >> Mem:255232k total, 185004k used,70228k free,29812k buffers > >> Swap:0k total,0k used,0k free, 117208k cached > >> > >> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > >> > >> 1444 root 25 0 148m 5832 3332 R 99.3 2.3 1:59.36 X > >> > >> 1423 dima 15 0 2628 1084 908 S 0.7 0.4 0:01.30 esd > >> > >> 1487 dima 16 0 1864 964 764 R 0.3 0.4 0:00.14 top > >> > >> > >> As I can see --- all cpu power eaten by X server, but I cant kill it :( > >> even with help -9 or -11 signal 8o probably because the proces is in system > >> (kernel) mode... [snip] > > Try to find a version in CVS that works and then narrow it down to one > > specific commit that introduced the problem. This will be time consuming > > and not very exciting though. > > > now I rewert to clean (ie stable) xorg-6.8.1 build from source. Are you also using the Mesa 3D driver from xorg-6.8.1? The problem is most likely in the 3D driver. Try reverting Mesa CVS to an older version (cvs update -dP -D ) and recompiling the 3D driver from there. Make sure that the new (old) driver actually gets used. > (but I do not change drm module... it look like xorg source do not contain > drm sources) this not help much :( quake crached after a minute or > two. only garbage on the screen and locked mouse... but Xserver itself not > locked I can shutdown Xserver by keyboard... coredump for quake2 not > generated regardless I set ulimit -c unlimited > > but there is a message in the log of running quake2: > Error: R200 timed out... exiting [ from your other mail] > but... why I can't kill X server? 9 signal is very powerfull, but not > work Your top-output above shows that it's spinning in kernel mode. That's why you can't kill it. > > What I can do farther? any ideas? > > can this problem be related to drm module? Probably not. The DRM is just stupid to wait forever for the graphics engine to become available. But the actual trigger for the lockup is most likely in the 3D driver. > what other drm modules I can try ? You can do the same with DRM CVS as with the Mesa CVS above. > >> [snip] > > Probably quake2 or the 3D driver segfaults before the mouse grab and > > graphics mode can be restored, possibly in r200DestroyContext. If it's > > crashing in the graphics driver this should be fairly easy to track > > down. Enable core dumps (ulimit -c unlimited) and analyze the core dump > > with gdb to see where it crashed (gdb -c core `which quake2`). > > I set ulimit -c unlimited... but were is core dump? I cant find it :( > nor for quake2 nor for quake3 (quake3 finished with signal 11) > The core dump should be in the current working directory. Sometimes it's called core.. Which shell are you using. Ulimit is a built in command in bash. I don't know if it works the same in other shells. OTOH quake2 may not be crashing because of a segfault. Sometimes I saw quake2 die because of some invalid commands it sent to the Xserver. In that case you should see an error message in the terminal where you started quake2. -- | 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 Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Refector of drm_addbufs_* in linux-core/drm_bufs.c
Here's a refactor I did of the various drm_addbufs_* functions in
drm_bufs.c. Basically, I pulled all the common, boilerplate ioctl code
out of the individual functions into drm_addbufs. A side benefit (and
the actual reason I did the exercise) is that the drm_addbufs_* routines
can now be called in-kernel.
If this looks good, I'll go ahead and commit it. I'll also apeal the
the BSD gods to do a *BSD version. ;)
Index: linux-core/drm_bufs.c
===
RCS file: /cvs/dri/drm/linux-core/drm_bufs.c,v
retrieving revision 1.55
diff -u -d -r1.55 drm_bufs.c
--- linux-core/drm_bufs.c 26 Apr 2005 05:19:11 - 1.55
+++ linux-core/drm_bufs.c 19 May 2005 23:43:27 -
@@ -433,25 +433,19 @@
#if __OS_HAS_AGP
/**
- * Add AGP buffers for DMA transfers (ioctl).
+ * Add AGP buffers for DMA transfers
*
- * \param inode device inode.
- * \param filp file pointer.
- * \param cmd command.
- * \param arg pointer to a drm_buf_desc_t request.
+ * \param dev drm_device_t to which the buffers are to be added.
+ * \param request pointer to a drm_buf_desc_t describing the request.
* \return zero on success or a negative number on failure.
*
* After some sanity checks creates a drm_buf structure for each buffer and
* reallocates the buffer list of the same size order to accommodate the new
* buffers.
*/
-int drm_addbufs_agp(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+int drm_addbufs_agp(drm_device_t * dev, drm_buf_desc_t * request)
{
- drm_file_t *priv = filp->private_data;
- drm_device_t *dev = priv->head->dev;
drm_device_dma_t *dma = dev->dma;
- drm_buf_desc_t request;
drm_buf_entry_t *entry;
drm_buf_t *buf;
unsigned long offset;
@@ -465,25 +459,22 @@
int byte_count;
int i;
drm_buf_t **temp_buflist;
- drm_buf_desc_t __user *argp = (void __user *)arg;
+
if (!dma)
return -EINVAL;
- if (copy_from_user(&request, argp, sizeof(request)))
- return -EFAULT;
-
- count = request.count;
- order = drm_order(request.size);
+ count = request->count;
+ order = drm_order(request->size);
size = 1 << order;
- alignment = (request.flags & _DRM_PAGE_ALIGN)
+ alignment = (request->flags & _DRM_PAGE_ALIGN)
? PAGE_ALIGN(size) : size;
page_order = order - PAGE_SHIFT > 0 ? order - PAGE_SHIFT : 0;
total = PAGE_SIZE << page_order;
byte_count = 0;
- agp_offset = dev->agp->base + request.agp_start;
+ agp_offset = dev->agp->base + request->agp_start;
DRM_DEBUG("count: %d\n", count);
DRM_DEBUG("order: %d\n", order);
@@ -596,11 +587,8 @@
up(&dev->struct_sem);
- request.count = entry->buf_count;
- request.size = size;
-
- if (copy_to_user(argp, &request, sizeof(request)))
- return -EFAULT;
+ request->count = entry->buf_count;
+ request->size = size;
dma->flags = _DRM_DMA_USE_AGP;
@@ -609,13 +597,9 @@
}
#endif /* __OS_HAS_AGP */
-int drm_addbufs_pci(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+int drm_addbufs_pci(drm_device_t * dev, drm_buf_desc_t * request)
{
- drm_file_t *priv = filp->private_data;
- drm_device_t *dev = priv->head->dev;
drm_device_dma_t *dma = dev->dma;
- drm_buf_desc_t request;
int count;
int order;
int size;
@@ -631,7 +615,6 @@
int page_count;
unsigned long *temp_pagelist;
drm_buf_t **temp_buflist;
- drm_buf_desc_t __user *argp = (void __user *)arg;
if (!drm_core_check_feature(dev, DRIVER_PCI_DMA))
return -EINVAL;
@@ -639,22 +622,19 @@
if (!dma)
return -EINVAL;
- if (copy_from_user(&request, argp, sizeof(request)))
- return -EFAULT;
-
- count = request.count;
- order = drm_order(request.size);
+ count = request->count;
+ order = drm_order(request->size);
size = 1 << order;
DRM_DEBUG("count=%d, size=%d (%d), order=%d, queue_count=%d\n",
- request.count, request.size, size, order, dev->queue_count);
+ request->count, request->size, size, order, dev->queue_count);
if (order < DRM_MIN_ORDER || order > DRM_MAX_ORDER)
return -EINVAL;
if (dev->queue_count)
return -EBUSY; /* Not while in use */
- alignment = (request.flags & _DRM_PAGE_ALIGN)
+ alignment = (request->flags & _DRM_PAGE_ALIGN)
? PAGE_ALIGN(size) : size;
page_order = order - PAGE_SHIFT > 0 ? order - PAGE_SHIFT : 0;
total = PAGE_SIZE << page_order;
@@ -826,25 +806,17 @@
up(&dev->struct_sem);
- request.count = ent
Re: CVS head: glxgears on r200 with tcl broken
On Thu, May 19, 2005 at 10:57:52PM +0100, Dave Airlie wrote: > > Phil wrote: > > fwiw, I've found the dri snapshot at nixnuts.net to be absolutely > > stable with my 9200SE (rv280 chipset). I don't think I've had any > > crashes at all. Mostly it gets used for a spot of Q3A or UT -- UT2003 > > is unbearably slow (for reasons outlined on this list sometime IIRC) > > and UT2004 has severe rendering errors, so it isn't all perfect. > > my 9200 with X.org/Mesa CVS from not so long ago, is stablish, i.e. I can > play quake3 ut2003 for a good while, my problems only seem to start when I > do something like glxgears/a couple of rss screensavers in windows and > gtk-demo... single fullscreen apps to me seem sound... Hmm, well I haven't pushed the 'multiple GL apps running at once' side of things I must admit. Oh, and NWN doesn't get on with environment maps either. Otherwise it seems to run quite well... Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3217] Computer hangs during X.org shutdown. I get bad page state at __free_pages_ok if I /etc/init.d/xdm stop. i915 glx xorg 6.8.99.3
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=3217 --- Additional Comments From [EMAIL PROTECTED] 2005-05-19 15:22 --- (In reply to comment #3) > I use sarge with a 2.6.12-rc4 Kernel to get my i915GMm-HFS AOpen Motherboard > successfully working for dri/drm/agpgart (onboard graphiccard): > > Linux agpgart interface v0.101 (c) Dave Jones > agpgart: Detected an Intel 915GM Chipset. > agpgart: Detected 764K stolen memory. > agpgart: AGP aperture is 256M @ 0xc000 > [drm] Initialized drm 1.0.0 20040925 > ACPI: PCI Interrupt :00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 > [drm] Initialized i915 1.1.0 20040405 on minor 0: Intel Corporation Mobile > 915GM/GMS/910GML Express Graphics Controller > > The standard XFree86 4.3.0.dfsg.1-1 is configured by /etc/X11/XF86Config-4 That is a very old release of X, you might do better with xorg-6.8.2. > ... > Section "Device" > Identifier "myMoth" > Driver "i810" > Option "DRI" > EndSection > ... > > /var/log/XFree86.0.log shows: > ... > (II) I810(0): [drm] installed DRM signal handler > (II) I810(0): [DRI] installation complete > (II) I810(0): direct rendering: Enabled > ... > also some warnings > (WW) I810(0): Bad V_BIOS checksum > (II) I810(0): Primary V_BIOS segment is: 0xc000 > > But now when I do a 'glxinfo' I get "direct rendering: No" > ??? This really confused me. Try: export LIBGL_DEBUG=1 > > And how do I get 3d-Hardware-Support to play QuakeIII with full-speed? > Mesa is installed: > $ dpkg -l | grep mesa > ii xlibmesa-gl4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] > ii xlibmesa-gl-de 4.3.0.dfsg.1-1 Mesa 3D graphics library development files > ii xlibmesa-glu 4.3.0.dfsg.1-1 Mesa OpenGL utility library [XFree86] > ii xlibmesa-glu-d 4.3.0.dfsg.1-1 Mesa OpenGL utility library development file > > > It would be great if someone out there could help me. > > PS: $( dmesg ) shows a > "mtrr: base(0xc002) is not aligned on a size(0x18) boundary" > is that due to my gfx-card? Yes, it will be for the write-combining for the video memory, it shouldn't be the problem. -- 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. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
> > remember)). 3D works for hours (original UT, Quake3) without > > lockups, whereas newer snapshots for xorg (gentoo / linux 2.6.8.11 / > > xorg 6.8.2) crash in less than a minute (and sometimes in seconds) > > on the same PC. Q3A seems to take longer to crash than UT, but > > that's a subjective feeling I have, no real data. Tested with a > > Radeon 9100/128MB (i815ep, Celeron 1300, 512MB SDRAM). > > fwiw, I've found the dri snapshot at nixnuts.net to be absolutely > stable with my 9200SE (rv280 chipset). I don't think I've had any > crashes at all. Mostly it gets used for a spot of Q3A or UT -- UT2003 > is unbearably slow (for reasons outlined on this list sometime IIRC) > and UT2004 has severe rendering errors, so it isn't all perfect. my 9200 with X.org/Mesa CVS from not so long ago, is stablish, i.e. I can play quake3 ut2003 for a good while, my problems only seem to start when I do something like glxgears/a couple of rss screensavers in windows and gtk-demo... single fullscreen apps to me seem sound... I've got Debian installed on my PC I must reboot into it and try my tests... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3337] New: ati radeon 7000 pci dri not working cruppted display and system lockup.
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=3337 Summary: ati radeon 7000 pci dri not working cruppted display and system lockup. Product: DRI Version: XOrg 6.7.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] ok i installed mandriva 2005 le on my pc and everything whent whell even the test display. but after the install was finished when linux tryes to load xorg i get a cruppted and frozen display. this is a total system lockup i have to hard shutdown just to get out of it. wile there is the workaround of disabling dri to get things working whats the real point in doing this couse using a 3d card without 3d acell well you get the idea. this issue was fixed in later vers of xfree aboughta year ago but it looks like its still in xorg. i hope you can fix this bug soon. shure this card isnt high end but it does a good enough job. -- 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. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1678] Direct Rendering problems on IGP 320M
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=1678 --- Additional Comments From [EMAIL PROTECTED] 2005-05-19 10:53 --- Hi, Im also affected here, and things are getting worse as newer versions come out. I have used Fedora, and in FC2 Everything worked ok. In FC3, I had to turn acpi=off, and enter the option "NoAccel" to get KDE enabled. But then I was not able to play any movies, or even start Totem or xine, without killing the x-server. Now in FC4Test 3 the system completely freezed, and I had to boot into single mode to edit the same things as in FC3. I Also tryed Mandrake 10.2, and it booted OK into KDE. I then tryed Mandriva 2005 limited edition, and at starting X the system freezed. This is also on a Amlio A7600. -- 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. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
> I use a similar approach. v_swiz contains all the native r300 swizzle
> values,
> aswell as a couple of cases where we have to handle them specially. The
> non-native cases have v_swiz->native set to GL_FALSE.
I saw that in code but you still got a loop and test case, your
approach is well thinked. But i think it may be hard to understand
say if you look at it in 2 or 3 month.
Thus the only + arguments for a simple 2tab translation i
propose is that it the easiest thing to understand, moreover
you can easily optimize some swizzling case and don't bother
too much on other... But beside the understanding
of your mixed approach haven't a strong opinion on which solution is the
best...
> The code is only translated once. In the case of the texenv stuff, whenever
> it needs to be regenerated Mesa will call r300ProgramStringNotify to tell
> us that the program has changed.
This why i think tab lookup speed isn't really revealent in
selecting this. I will try to adapt my swizzle function
to your code (shouldn't be difficult) thus you can see it.
Bascily arg checking in emit arith look like this :
id = reg & MASK_XYZCHANNEL
reg_fpi0_mask = tab1[id];
if (reg_fpi0_mask ^ ffe0 ) {
swizzle -> copy tab2[id>>5] -> r300_instruct
t = get_temp
for i>5].length
r300_instr[p-i] |= t
}
Just a memcpy of instruction and a small loop
to set the correct temp reg allocated.
> I once had this in the code, but ended up stripping it down to iron out some
> bugs. Now that I know that it mostly works correctly, I should be able
> to add
> this back in easily enough. Rather than using a stack, I'm using a
> bitfield to
> track register allocations. Freeing a register is as easy as setting
> the bit to 0.
What is in favor of a stack is that you easily find free temp
(just test if stack is empty), while with bitfield you have to
loop trought each temp see if bitfield set.
>Care must be taken not to cause texture indirections by reusing an
> already
> used temp as the destination for a TEX instruction (that's what
> rp->used_this_node
> is/was for)
Yes, i saw this possible issue but didn't think too much on
solution to handle it, i will give a deeper look to your code
this evening.
> No, you haven't missed anything. This was another case where I quickly
> hacked
> something up. Constant swizzles should/could be handled exactly the same as
> temp swizzles. In the swizzling code you just have to be careful that
> reg->type is
> set correctly depending on whether or not it's a native swizzle.
I was thinking of tracking constant and see if they are always used
swizzle. If so easier to emit the const swizzled like you do.
As i said this is maybe a to advanced and complex optimization which
may involve complex tracking of operand in the program.
Jerome Glisse
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Thu, 19 May 2005, Jerome Glisse wrote: On 5/19/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote: On Thu, 19 May 2005, Jerome Glisse wrote: Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? An intermediate approach would be to have an "if" function that is easier to read (and debug) but instead of using return values directly populate the table with the return values during startup and then use the table. Did i said that i already done the table (as a human, at least everythings tends to make me think that i am a human :-)) Thus making a function to redo the table may be bit useless :) The function approach might be useful if there are fewer test cases than entries in the table. In this case we win on code maintainability.. best Vladimir Dergachev Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote:
I use a similar approach. v_swiz contains all the native r300 swizzle
values,
aswell as a couple of cases where we have to handle them specially. The
non-native cases have v_swiz->native set to GL_FALSE.
I saw that in code but you still got a loop and test case, your
approach is well thinked. But i think it may be hard to understand
say if you look at it in 2 or 3 month.
Thus the only + arguments for a simple 2tab translation i
propose is that it the easiest thing to understand, moreover
you can easily optimize some swizzling case and don't bother
too much on other... But beside the understanding
of your mixed approach haven't a strong opinion on which solution is the
best...
The code is only translated once. In the case of the texenv stuff, whenever
it needs to be regenerated Mesa will call r300ProgramStringNotify to tell
us that the program has changed.
This why i think tab lookup speed isn't really revealent in
selecting this. I will try to adapt my swizzle function
to your code (shouldn't be difficult) thus you can see it.
Bascily arg checking in emit arith look like this :
id = reg & MASK_XYZCHANNEL
reg_fpi0_mask = tab1[id];
if (reg_fpi0_mask ^ ffe0 ) {
swizzle -> copy tab2[id>>5] -> r300_instruct
t = get_temp
for i>5].length
r300_instr[p-i] |= t
}
Just a memcpy of instruction and a small loop
to set the correct temp reg allocated.
Well, I'm in mixed minds about this myself now. But if you have a way
to gain extra
speed out of this without consuming a heap of RAM, I'm all for it :)
Extra speed could be useful, as some programs may have a lot of swizzles
per-frame (UT2004
has a few when MaxTextureUnits is set to 8 in ut2004.ini) and every
extra bit helps.
Care must be taken not to cause texture indirections by reusing an
already
used temp as the destination for a TEX instruction (that's what
rp->used_this_node
is/was for)
Yes, i saw this possible issue but didn't think too much on
solution to handle it, i will give a deeper look to your code
this evening.
I've attached another patch (applies on top of the last one) which
/should/ take
care of this, and handle the case where a program does a TEX directly to an
output. It also free's up temps in the cases where we need one for a
swizzle, or
an LRP.
What I'd like to be able to do is re-use temps used by the Mesa program,
and also
to free-up the hardware temp that a Mesa INPUT uses once they're no
longer needed.
We'd need to find out when the temp/input was last used so we didn't
destroy it
pre-maturely.
Should be easy enough to do, as my code already pre-parses the Mesa
program. I
originally considered this a thing I needed to fix. But it could be
useful for some things.
No, you haven't missed anything. This was another case where I quickly
hacked
something up. Constant swizzles should/could be handled exactly the same as
temp swizzles. In the swizzling code you just have to be careful that
reg->type is
set correctly depending on whether or not it's a native swizzle.
I was thinking of tracking constant and see if they are always used
swizzle. If so easier to emit the const swizzled like you do.
As i said this is maybe a to advanced and complex optimization which
may involve complex tracking of operand in the program.
You could possibly do this for some cases right now. In t_src you'd
need to skip
the emit_const4fv for constant sources if they're swizzles, and call
swizzle_const
instead. This would eliminate some of them.
The patch I attached doesn't call swizzle_const at all, instead, it uses
the same
method as temps do. I didn't see anything too nasty in ut2004 from
doing this.
I didn't test the patch in great detail, so there's probably something I
missed :/
Ben Skeggs.
Jerome Glisse
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--- diff/r300/r300_fragprog.c 2005-05-19 04:23:09.0 +1000
+++ r300_wip/r300/r300_fragprog.c 2005-05-20 03:21:23.0 +1000
@@ -172,10 +172,21 @@
rp->hwreg_flag |= (1 << r);
rp->hwreg_used |= (1 << r);
-
+
return r;
}
+static void free_hw_temp(struct r300_fragment_program *rp, int idx)
+{
+ rp->hwreg_flag &= ~(1temp_flag &= ~(1used_in_node));
+ if (!hw_r || (--hw_r == r.index))
+ return r;
+
+ free_hw_temp(rp, rp->temps[r.index]);
+ r.index = hw_r;
+
+ rp->hwreg_flag |= (1 << hw_r);
+ rp->hwreg_used |= (1 << hw_r);
+ return r;
+}
+
static pfs_reg_t negate(pfs_reg_t r)
{
r.negate = 1;
Re: [R300] new snapshot ?
On 5/19/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > On Thu, 19 May 2005, Jerome Glisse wrote: > > > > Thus what we may do is use this table or use your swizzle > > function. Table lookup are faster but we doesn't have to translate > > code often, no ? > > An intermediate approach would be to have an "if" function that is easier > to read (and debug) but instead of using return values directly populate > the table with the return values during startup and then use the table. Did i said that i already done the table (as a human, at least everythings tends to make me think that i am a human :-)) Thus making a function to redo the table may be bit useless :) Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3217] Computer hangs during X.org shutdown. I get bad page state at __free_pages_ok if I /etc/init.d/xdm stop. i915 glx xorg 6.8.99.3
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=3217 --- Additional Comments From [EMAIL PROTECTED] 2005-05-19 09:25 --- I use sarge with a 2.6.12-rc4 Kernel to get my i915GMm-HFS AOpen Motherboard successfully working for dri/drm/agpgart (onboard graphiccard): Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 915GM Chipset. agpgart: Detected 764K stolen memory. agpgart: AGP aperture is 256M @ 0xc000 [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 [drm] Initialized i915 1.1.0 20040405 on minor 0: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller The standard XFree86 4.3.0.dfsg.1-1 is configured by /etc/X11/XF86Config-4 ... Section "Device" Identifier "myMoth" Driver "i810" Option "DRI" EndSection ... /var/log/XFree86.0.log shows: ... (II) I810(0): [drm] installed DRM signal handler (II) I810(0): [DRI] installation complete (II) I810(0): direct rendering: Enabled ... also some warnings (WW) I810(0): Bad V_BIOS checksum (II) I810(0): Primary V_BIOS segment is: 0xc000 But now when I do a 'glxinfo' I get "direct rendering: No" ??? This really confused me. And how do I get 3d-Hardware-Support to play QuakeIII with full-speed? Mesa is installed: $ dpkg -l | grep mesa ii xlibmesa-gl4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] ii xlibmesa-gl-de 4.3.0.dfsg.1-1 Mesa 3D graphics library development files ii xlibmesa-glu 4.3.0.dfsg.1-1 Mesa OpenGL utility library [XFree86] ii xlibmesa-glu-d 4.3.0.dfsg.1-1 Mesa OpenGL utility library development file It would be great if someone out there could help me. PS: $( dmesg ) shows a "mtrr: base(0xc002) is not aligned on a size(0x18) boundary" is that due to my gfx-card? -- 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. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2596] Disabling DRI. [drm] failed to load kernel module "i915" (EE) I810(0): [dri] DRIScreenInit failed.
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=2596 --- Additional Comments From [EMAIL PROTECTED] 2005-05-19 09:14 --- Hi, with Kernel 2.6.12-rc4 I get a (II) I810(0): [DRI] installation complete with a 2.6.10 not. But I use a debian sarge with a old XFree86 4.3... -- 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. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
On Thu, May 19, 2005 at 03:21:38PM +0200, khaqq wrote: > On Thu, 19 May 2005 12:13:17 +0100 (IST) > Dave Airlie <[EMAIL PROTECTED]> wrote: > > I've become skeptical that the r200 was ever truly stable... it may be > > less stable now .. I'm getting crsahes on my 9200 with multi-app also.. > > and I've gotten a lot of reports of them... > > I've installed a debian-testing (sarge) the other day and what they > have seems stable, yet awfully old (xfree 4.3.0 + 2.4.x (don't > remember)). 3D works for hours (original UT, Quake3) without > lockups, whereas newer snapshots for xorg (gentoo / linux 2.6.8.11 / > xorg 6.8.2) crash in less than a minute (and sometimes in seconds) > on the same PC. Q3A seems to take longer to crash than UT, but > that's a subjective feeling I have, no real data. Tested with a > Radeon 9100/128MB (i815ep, Celeron 1300, 512MB SDRAM). fwiw, I've found the dri snapshot at nixnuts.net to be absolutely stable with my 9200SE (rv280 chipset). I don't think I've had any crashes at all. Mostly it gets used for a spot of Q3A or UT -- UT2003 is unbearably slow (for reasons outlined on this list sometime IIRC) and UT2004 has severe rendering errors, so it isn't all perfect. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Boris Peterbarg <[EMAIL PROTECTED]> wrote:> > Well, I tried now - I have an old computer...well, the box anyway. Had > to switch all the cables between the two computers all the time. > First, the program that I ran consumed 100%. After killing it, X > consumed 100% and took about 15 minutes to be killed. The last image was > still stuck on the display, though. Thus i think that we face the same problem as r200 :( seems a hard bug to find Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
On Thu, 19 May 2005 12:13:17 +0100 (IST) Dave Airlie <[EMAIL PROTECTED]> wrote: > > > > DRI is working on the R200 otherwise, I'm getting about 4200fps in glxgears, > > not bad for an Athlon 1.4GHz and an Radeon 8500. I get about 540fps on the > > MGA > > G400MAX(overclocked) PIII/933MHz. > > > > Would further details be usefull? > > I've become skeptical that the r200 was ever truly stable... it may be > less stable now .. I'm getting crsahes on my 9200 with multi-app also.. > and I've gotten a lot of reports of them... > > I could go back and check the older r200s at some stage... but with > everything else on God only knows... I'm still seeing M7 crashes as well > but they are getting further apart... > > Dave. I've installed a debian-testing (sarge) the other day and what they have seems stable, yet awfully old (xfree 4.3.0 + 2.4.x (don't remember)). 3D works for hours (original UT, Quake3) without lockups, whereas newer snapshots for xorg (gentoo / linux 2.6.8.11 / xorg 6.8.2) crash in less than a minute (and sometimes in seconds) on the same PC. Q3A seems to take longer to crash than UT, but that's a subjective feeling I have, no real data. Tested with a Radeon 9100/128MB (i815ep, Celeron 1300, 512MB SDRAM). khaqq PS : Radeon 7500/64MB works on debian sarge too (rendering errors in UT, but no crashes). That's probably not useful though. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Thursday 19 May 2005 09:20, Keith Whitwell wrote: > > Vladimir Dergachev wrote: > > > > > > Hi Aapo, Ben, Jerome, Nicolai: > > > > > >I recently checked fresh code from CVS and was pleasantly surprised > > > to see that all Quake3 levels that were broken are now perfect - in fact > > > I cannot find anything that is amiss ! > > > > > >Do you think it would be a good idea to tag the current code and make > > > a snapshot ? > > Sure, anytime :) > > > So have you guys given any consideration to moving the r300 driver into > > mesa proper? CVS access shouldn't be a problem, fwiw... > > There are two main points that have stopped me from pushing for the > inclusion of the driver into Mesa proper: > > 1. Kernel-level security holes > We should take care of full command-stream verification before moving the > driver into Mesa CVS. It's easy to say "We can do that later", but if we > say that it's likely that it won't be done in a long time. > > 2. DRM binary compatibility > We still don't know the meaning of many of the registers. Some registers are > labelled "dangerous" which means we might have to do some more checks in > the kernel to make sure user processes can't do harmful stuff. This means > that we might have to *remove* some of the cmdbuf commands that exist today > in the future. > > If the others believe moving r300 to Mesa is a good idea, then I'll do some > auditing to the DRM code. Once I (or somebody else) has done this, I'm okay > with moving the driver as long as we don't enforce DRM binary compatibility > yet. > > cu, > Nicolai > true, the drm may need to live on it's own branch for a bit. But I think the 3d driver could be added to mesa. it can live in cvs until we feel it is ready to be part of a stable release. Being part of mesa cvs means we'll always be in sync with the latest mesa changes and get nightly snapshots which will add additional testers for better or worse. Alex --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
> I've also been working on some fragment program stuff. I have attached what > I've done so far, which works quite well with Keith's texenv program > generation > that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I > think everything's > there that the texenv stuff needs. > > I was planning on commiting this soon, but you may have a better > approach than I > took so I'll wait a bit. I have tried a similar approach at first but as swizzle appear it looks awful, i haven't take a deeper look at the way you handle it but you have a bunch of if test like i got in my first version. You certainly have done cleaner version than my first attempt thought. Anyway now what i have is the stupid way of having a table for all swizzle case, just for the x,y,z component as w is in sep an easier reg. Thus i got two tab one for xyz to FPI0_SRC conv which have a special value for not native format, this special value in an index in the second tab where i got all the code for all differents cases (64 cases less 7 of native format). This consumes few bytes about 1ko... Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? Anyway other part of the code is basicly the same, yours is in a more advanced state than mine thus we should use yours... Anyone have strong feeling on this swizzle thing ? Or even an magic idea with a magic bitwise formula :) One other interesting feature is reuse of temp register at some point i was thinking of adding a free_temp function and having a stack of free register. Then get_temp first take from the stack if not empty, or use a new temp if empty. This get/free approach is usefull with swizzling where you know that you will use a temps register only for 1 instruction. But there may be case where you reuse the same swizzled src. I am wondering if you emit_const_swizzle may not consume all const if say you have an const which is used in all of the 64 possibles swizzle... I may have miss something on that thought. But if we know that we will only use the const in a swizzled format then your solution is the best. I got other idea on optimizing this swizzling in program translation (basicly tracking operand). But this are maybe useless optimization for time being... Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Thu, 19 May 2005, Jerome Glisse wrote: Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? An intermediate approach would be to have an "if" function that is easier to read (and debug) but instead of using return values directly populate the table with the return values during startup and then use the table. This way we retain the readability and have the speedup from lookups. best Vladimir Dergachev --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs. I was planning on commiting this soon, but you may have a better approach than I took so I'll wait a bit. I have tried a similar approach at first but as swizzle appear it looks awful, i haven't take a deeper look at the way you handle it but you have a bunch of if test like i got in my first version. You certainly have done cleaner version than my first attempt thought. Anyway now what i have is the stupid way of having a table for all swizzle case, just for the x,y,z component as w is in sep an easier reg. Thus i got two tab one for xyz to FPI0_SRC conv which have a special value for not native format, this special value in an index in the second tab where i got all the code for all differents cases (64 cases less 7 of native format). This consumes few bytes about 1ko... I use a similar approach. v_swiz contains all the native r300 swizzle values, aswell as a couple of cases where we have to handle them specially. The non-native cases have v_swiz->native set to GL_FALSE. What I do is firstly loop through checking for matches of XYZ. If we match all three components, the code will return a pfs_reg_t with v_swz/s_swz set to a native type. Otherwise, we continue looping through the different outmasks doing multiple emits to another temp until we have the desired value. Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? The code is only translated once. In the case of the texenv stuff, whenever it needs to be regenerated Mesa will call r300ProgramStringNotify to tell us that the program has changed. Anyway other part of the code is basicly the same, yours is in a more advanced state than mine thus we should use yours... Anyone have strong feeling on this swizzle thing ? Or even an magic idea with a magic bitwise formula :) One other interesting feature is reuse of temp register at some point i was thinking of adding a free_temp function and having a stack of free register. Then get_temp first take from the stack if not empty, or use a new temp if empty. This get/free approach is usefull with swizzling where you know that you will use a temps register only for 1 instruction. But there may be case where you reuse the same swizzled src. I once had this in the code, but ended up stripping it down to iron out some bugs. Now that I know that it mostly works correctly, I should be able to add this back in easily enough. Rather than using a stack, I'm using a bitfield to track register allocations. Freeing a register is as easy as setting the bit to 0. Care must be taken not to cause texture indirections by reusing an already used temp as the destination for a TEX instruction (that's what rp->used_this_node is/was for) I am wondering if you emit_const_swizzle may not consume all const if say you have an const which is used in all of the 64 possibles swizzle... I may have miss something on that thought. But if we know that we will only use the const in a swizzled format then your solution is the best. No, you haven't missed anything. This was another case where I quickly hacked something up. Constant swizzles should/could be handled exactly the same as temp swizzles. In the swizzling code you just have to be careful that reg->type is set correctly depending on whether or not it's a native swizzle. I got other idea on optimizing this swizzling in program translation (basicly tracking operand). But this are maybe useless optimization for time being... I've thought of similar things, but haven't attempted anything yet. I also need to take another look at the generated code, to make sure that combining the xyz and w instuction streams is working as I intended. When I first integrated my test code into r300_dri it was, but I've changed much since then. Cheers, Ben Skeggs. Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourcef
Re: CVS head: glxgears on r200 with tcl broken
On 5/19/05, Steven Newbury <[EMAIL PROTECTED]> wrote: > --- Michel Dänzer <[EMAIL PROTECTED]> wrote: > > On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote: > > > > 4) UseFBDev results in the following error and failed initialisation: > > > (EE) RADEON(0): FBIOPUT_VSCREENINFO: Invalid argument > > > > Either you aren't running radeonfb, or it probably doesn't like the > > mode. In the latter case, maybe there's something interesting in the > > kernel output. > > > I am running radeonfb. It's in 640x480 (default mode). I have just noticed > that that there is one more error in the X log: > (EE) RADEON(0): MergedFB does not work with Option UseFBDev, MergedFB mode is > disabled > > I'm not using MergedFB. > > Steve > The server defaults to clone mode which is handled by mergedfb. Alex --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Thursday 19 May 2005 09:20, Keith Whitwell wrote: > Vladimir Dergachev wrote: > > > > Hi Aapo, Ben, Jerome, Nicolai: > > > >I recently checked fresh code from CVS and was pleasantly surprised > > to see that all Quake3 levels that were broken are now perfect - in fact > > I cannot find anything that is amiss ! > > > >Do you think it would be a good idea to tag the current code and make > > a snapshot ? Sure, anytime :) > So have you guys given any consideration to moving the r300 driver into > mesa proper? CVS access shouldn't be a problem, fwiw... There are two main points that have stopped me from pushing for the inclusion of the driver into Mesa proper: 1. Kernel-level security holes We should take care of full command-stream verification before moving the driver into Mesa CVS. It's easy to say "We can do that later", but if we say that it's likely that it won't be done in a long time. 2. DRM binary compatibility We still don't know the meaning of many of the registers. Some registers are labelled "dangerous" which means we might have to do some more checks in the kernel to make sure user processes can't do harmful stuff. This means that we might have to *remove* some of the cmdbuf commands that exist today in the future. If the others believe moving r300 to Mesa is a good idea, then I'll do some auditing to the DRM code. Once I (or somebody else) has done this, I'm okay with moving the driver as long as we don't enforce DRM binary compatibility yet. cu, Nicolai pgpm9DoWLbaY9.pgp Description: PGP signature
Re: CVS head: glxgears on r200 with tcl broken
--- Steven Newbury <[EMAIL PROTECTED]> wrote: > --- Adam Jackson <[EMAIL PROTECTED]> wrote: > > > On Wednesday 18 May 2005 23:53, Michel Dänzer wrote: > > > On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote: > > > > 1) When I move a window over a 3D rendering window the contents jumps > to > > > > the top left hand part of the display. If I move the output (say the > > > > glxgears) window to the top left I see the output centred at the screen > > > > edge, otherwise the window is blank. When the window moved around the > > > > output correctly appears in the window. > > > Slight update here; it's aligned with the left hand edge (X=0) but does seem to appear at the correct Y coordinate. > > > I haven't seen this, but it sounds like it might be related to today's > > > ABI-backwards-compatibility-breaking change to the X.org libdri module. > > > If you have that, make sure everything was rebuilt correctly according > > > to it. > > > > I would be surprised. DRI won't even initialize if you have a version > > mismatch between libdri and the DDX, and the structure that was changed > isn't > > > > visible from the client. > > > To be clear, I've modified the Fedora xorg .spec file to build the X server > from the xorg CVS (without DRI drivers) then it builds the DRI drivers (using > the current CVS Mesa and DRM) and installs them into place. I've got built > versions this way going back to 11 May. I update the release each time and > install all the packages. I've gone back and tried each build between now > and > then and all have this problem. The earlier ones had the TCL bug as well. I > have only just started trying to get things working on this machine. I > install > the same packages on another machine using the MGA driver and everything is > fine (except for lock-ups switching X->vt which is reported in FDO Bugzilla > and > vt curruption if matroxfb isn't loaded). > > DRI is working on the R200 otherwise, I'm getting about 4200fps in glxgears, > not bad for an Athlon 1.4GHz and an Radeon 8500. I get about 540fps on the > MGA > G400MAX(overclocked) PIII/933MHz. > > Would further details be usefull? > > Steve Steve ___ Yahoo! Mobile - get free mobile goodies during MobileMania! http://uk.mobile.yahoo.com/mania/ --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: On 5/19/05, Keith Whitwell <[EMAIL PROTECTED]> wrote: Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? Sounds like a good idea. Why not :) So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... I think to few of us have an access to mesa cvs (at leat i didn't have one), anyway i could ask one. But there is still missing parts. I would like to know if anyone know what is still not working and thus do a to do list of that... What i see missing is : (i may not see everythings :-) -deeper testing of tcl program generated with mesa -tex env -fragment program Also, I think there's still some weirdness with a couple of texture formats, namely GL_ALPHA and GL_LUMINANCE_ALPHA. This is clearly seen in Mesa/progs/demos/texenv.c. Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Does ... work ? -z offset -stencil Right now i am on pixel shader after doing some test i don't think we can use a similar stuff like i915 emit arithm, i915 hardware are far more easier to program than r300. I am coding another approach an hope to have it done by the end of this week. I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs. I was planning on commiting this soon, but you may have a better approach than I took so I'll wait a bit. Ben Skeggs. Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Gemeinsame Unterverzeichnisse: r300.old/CVS und r300/CVS. diff -Nu r300.old/Makefile r300/Makefile --- r300.old/Makefile 2005-04-24 19:08:31.0 +1000 +++ r300/Makefile 2005-05-19 03:24:11.0 +1000 @@ -37,6 +37,7 @@ r300_texstate.c \ r300_texprog.c \ r300_vertexprog.c \ +r300_fragprog.c \ r300_shader.c \ r300_maos.c # \ diff -Nu r300.old/r300_context.c r300/r300_context.c --- r300.old/r300_context.c 2005-05-19 23:50:38.0 +1000 +++ r300/r300_context.c 2005-05-19 23:47:41.0 +1000 @@ -80,7 +80,9 @@ "GL_ARB_texture_mirrored_repeat", "GL_ARB_vertex_buffer_object", "GL_ARB_vertex_program", - //"GL_ARB_fragment_program", +#if USE_ARB_F_P == 1 + "GL_ARB_fragment_program", +#endif "GL_EXT_blend_equation_separate", "GL_EXT_blend_func_separate", "GL_EXT_blend_minmax", @@ -325,7 +327,19 @@ ctx->Const.MaxVertexProgramLocalParams=256; // r420 ctx->Const.MaxVertexProgramEnvParams=256; // r420 ctx->Const.MaxVertexProgramAddressRegs=1; - + +#if USE_ARB_F_P + ctx->Const.MaxFragmentProgramTemps = PFS_NUM_TEMP_REGS; + ctx->Const.MaxFragmentProgramAttribs = 11; /* copy i915... */ + ctx->Const.MaxFragmentProgramLocalParams = PFS_NUM_CONST_REGS; + ctx->Const.MaxFragmentProgramEnvParams = PFS_NUM_CONST_REGS; + ctx->Const.MaxFragmentProgramAluInstructions = PFS_MAX_ALU_INST; + ctx->Const.MaxFragmentProgramTexInstructions = PFS_MAX_TEX_INST; + ctx->Const.MaxFragmentProgramInstructions = PFS_MAX_ALU_INST+PFS_MAX_TEX_INST; + ctx->Const.MaxFragmentProgramAddressRegs = 0; /* and these are?? */ + ctx->_MaintainTexEnvProgram = GL_TRUE; +#endif + driInitExtensions(ctx, card_extensions, GL_TRUE); radeonInitSpanFuncs(ctx); diff -Nu r300.old/r300_context.h r300/r300_context.h --- r300.old/r300_context.h 2005-05-19 23:50:38.0 +1000 +++ r300/r300_context.h 2005-05-19 23:47:41.0 +1000 @@ -47,6 +47,8 @@ #include "colormac.h" #include "radeon_context.h" +#define USE_ARB_F_P 1 + struct r300_context; typedef struct r300_context r300ContextRec; typedef struct r300_context *r300ContextPtr; @@ -83,7 +85,11 @@ and pixel_shader stru
Re: [R300] new snapshot ?
Jerome Glisse wrote: >Right now i am on pixel shader after doing some test i don't think we can >use a similar stuff like i915 emit arithm, i915 hardware are far more easier >to program than r300. I am coding another approach an hope to have it >done by the end of this week. > >Moreover i see that 9800 are reported to crash with the driver ? Is this >still true ? > > I will confirm this tomorrow, right now, I am busy with other stuff. Cheers, Jonathan signature.asc Description: OpenPGP digital signature
[Bug 3267] Rendering errors - Radeon 7500
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=3267 --- Additional Comments From [EMAIL PROTECTED] 2005-05-19 05:35 --- > try disabling tcl (use driconf or tcl_mode=0). this also didn't help -- 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. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: > -stencil Stencil should work. GL_ATI_separate_stencil is not implemented (hardware support it). I think, fog is not implemented too. >Moreover i see that 9800 are reported to crash with the driver ? Is this >still true ? I have 9500 Pro. Some opengl application locks after while. Enemy Teritori lock immediatly after match begin if extensions are enabled If extensions are dissabled in options menu it works good, but slow. Peter Zubaj ___ Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete. http://www.wanda.sk/ --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
> > DRI is working on the R200 otherwise, I'm getting about 4200fps in glxgears, > not bad for an Athlon 1.4GHz and an Radeon 8500. I get about 540fps on the > MGA > G400MAX(overclocked) PIII/933MHz. > > Would further details be usefull? I've become skeptical that the r200 was ever truly stable... it may be less stable now .. I'm getting crsahes on my 9200 with multi-app also.. and I've gotten a lot of reports of them... I could go back and check the older r200s at some stage... but with everything else on God only knows... I'm still seeing M7 crashes as well but they are getting further apart... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Boris Peterbarg <[EMAIL PROTECTED]> wrote: > Yes, this is still very true. I've just rebuilt xorg, mesa and r300 from > cvs. I tested with glxgears and a couple of games. I've got a 9800 pro. > glxgears running alone doesn't crash for a long time, but using anything > else in parallel (for example firefox) gives me a crash in seconds. > Playing neverball or tuxracer doesn't seem to crash at all. > armagetron on the other hand has a high possibility to crash, and > ut2004demo crashes in no more than 10 seconds. > In crash I mean that X, the mouse and the keyboard freeze. Did you try to log in via ssh ? If you can, look if the X process consume 100% of CPU, if so this may be related to the bug of r200, as we got many common code. > Maybe it has something to do with frame rates? I got a 9800 (don't remember if it's a pro or not) i will try to see if i can find anything. Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS head: glxgears on r200 with tcl broken
--- Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote: > > 4) UseFBDev results in the following error and failed initialisation: > > (EE) RADEON(0): FBIOPUT_VSCREENINFO: Invalid argument > > Either you aren't running radeonfb, or it probably doesn't like the > mode. In the latter case, maybe there's something interesting in the > kernel output. > I am running radeonfb. It's in 640x480 (default mode). I have just noticed that that there is one more error in the X log: (EE) RADEON(0): MergedFB does not work with Option UseFBDev, MergedFB mode is disabled I'm not using MergedFB. Steve ___ Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com This is a pre-release version of the The X.Org Foundation X11. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the The X.Org Foundation "monolithic tree" CVS repository hosted at http://www.freedesktop.org/Software/xorg/ X Window System Version 6.8.99.7 (Unsupported Custom Build by root: 6.8.99.7-3.sn) Release Date: 15 May 2005 + cvs X Protocol Version 11, Revision 0, Release 6.8.99.7 Build Operating System: Linux 2.6.12-rc4-sn4 i686 [ELF] Current Operating System: Linux infinity 2.6.12-rc4-sn4 #9 Wed May 18 00:44:47 BST 2005 i686 Build Date: 18 May 2005 Build Host: infinity.local.southview.snewbury.org.uk Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.12-rc4-sn4 ([EMAIL PROTECTED]) (gcc version 4.0.0 20050512 (Red Hat 4.0.0-5)) #9 Wed May 18 00:44:47 BST 2005 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 18 20:35:17 2005 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "VideoCard0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (**) Extension "Composite" is disabled (II) No APM support in BIOS or kernel (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.7 X.Org XInput driver : 0.4 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.so (II) Module bitmap: vendor="X.Org Foundation" compiled for 6.8.99.7, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 6.8.99.7, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.7 (++) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1039,0746 card 1849,0746 rev 10 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1039,0002 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 1039,0963 card , rev 25 class 06,01,00 hdr 80 (II) PCI: 00:02:1: chip 1039,0016 card , rev 00 class 0c,05,00 hdr 00 (II) PCI: 00:02:5: chip 1039,5513 card 1849,5513 rev 00 class 01,01,80 hdr 00 (II) PCI: 00:02:7: chip 1039,7012 card 1849,7012 rev a0 class 04,01,00 hdr 00 (II) PCI: 00:03:0: chip 1039,7001 card 1849,7001 rev 0f class 0c,03,10 hdr 80 (II) PCI: 00:03:1: chip 1039,7001 card 1849,7001 rev 0f class 0c,03,10 hdr 00 (II) PCI: 00:03:2: chip 1039,7002 card 1849,7001 rev 00 class 0c,03,20 hdr 00 (II) PCI: 00:04:0: chip 1039,0900 card 1849,8201 rev 90 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 1002,514c card 1002,013a rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,2), BCTRL: 0x000a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xb000 - 0xbfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xcfd0 - 0xcfef (0x20) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xbfa0 - 0xcfbf (0x1020) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge
Re: CVS head: glxgears on r200 with tcl broken
--- Adam Jackson <[EMAIL PROTECTED]> wrote: > On Wednesday 18 May 2005 23:53, Michel Dänzer wrote: > > On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote: > > > 1) When I move a window over a 3D rendering window the contents jumps to > > > the top left hand part of the display. If I move the output (say the > > > glxgears) window to the top left I see the output centred at the screen > > > edge, otherwise the window is blank. When the window moved around the > > > output correctly appears in the window. > > > > I haven't seen this, but it sounds like it might be related to today's > > ABI-backwards-compatibility-breaking change to the X.org libdri module. > > If you have that, make sure everything was rebuilt correctly according > > to it. > > I would be surprised. DRI won't even initialize if you have a version > mismatch between libdri and the DDX, and the structure that was changed isn't > > visible from the client. > To be clear, I've modified the Fedora xorg .spec file to build the X server from the xorg CVS (without DRI drivers) then it builds the DRI drivers (using the current CVS Mesa and DRM) and installs them into place. I've got built versions this way going back to 11 May. I update the release each time and install all the packages. I've gone back and tried each build between now and then and all have this problem. The earlier ones had the TCL bug as well. I have only just started trying to get things working on this machine. I install the same packages on another machine using the MGA driver and everything is fine (except for lock-ups switching X->vt which is reported in FDO Bugzilla and vt curruption if matroxfb isn't loaded). DRI is working on the R200 otherwise, I'm getting about 4200fps in glxgears, not bad for an Athlon 1.4GHz and an Radeon 8500. I get about 540fps on the MGA G400MAX(overclocked) PIII/933MHz. Would further details be usefull? Steve ___ Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? > Jerome Glisse > Yes, this is still very true. I've just rebuilt xorg, mesa and r300 from cvs. I tested with glxgears and a couple of games. I've got a 9800 pro. glxgears running alone doesn't crash for a long time, but using anything else in parallel (for example firefox) gives me a crash in seconds. Playing neverball or tuxracer doesn't seem to crash at all. armagetron on the other hand has a high possibility to crash, and ut2004demo crashes in no more than 10 seconds. In crash I mean that X, the mouse and the keyboard freeze. Maybe it has something to do with frame rates? Boris Peterbarg --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Direct rendering problem with quake2 on Radeon 8500
Felix Kühling <[EMAIL PROTECTED]> writes: >> but I have next problem: X server locked after a few minutes playing in >> quake2 ;( My computer do not react on mouse or keyboard activity... but >> this is not bus lock --- mplayer is contining playing music and I can login >> on the computer through SSH. >> >> it is the head of top output: >> >> top - 11:02:53 up 19:53, 8 users, load average: 1.22, 0.57, 0.25 >> Tasks: 59 total, 3 running, 54 sleeping, 0 stopped, 2 zombie >> Cpu(s): 0.3% us, 99.7% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si >> Mem:255232k total, 185004k used,70228k free,29812k buffers >> Swap:0k total,0k used,0k free, 117208k cached >> >> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND >> >> 1444 root 25 0 148m 5832 3332 R 99.3 2.3 1:59.36 X >> >> 1423 dima 15 0 2628 1084 908 S 0.7 0.4 0:01.30 esd >> >> 1487 dima 16 0 1864 964 764 R 0.3 0.4 0:00.14 top >> >> >> As I can see --- all cpu power eaten by X server, but I cant kill it :( >> even with help -9 or -11 signal 8o probably because the proces is in system >> (kernel) mode... > > Sounds like a graphics engine lockup. Some process keeps holding the > lock waiting for the engine to become available, which it never does > because it's locked up. In the mean while X tries to grab the lock and > fails. So it keeps retrying, eating 100% CPU. Just a theory though. > There have been reports about instabilities with r200-based cards. It > was introduced by some driver change last year. But AFAIK noone got > around to tracking it down. :-/ > >> >> what I can do? and how I can debug the problem? > > Try to find a version in CVS that works and then narrow it down to one > specific commit that introduced the problem. This will be time consuming > and not very exciting though. > now I rewert to clean (ie stable) xorg-6.8.1 build from source. (but I do not change drm module... it look like xorg source do not contain drm sources) this not help much :( quake crached after a minute or two. only garbage on the screen and locked mouse... but Xserver itself not locked I can shutdown Xserver by keyboard... coredump for quake2 not generated regardless I set ulimit -c unlimited but there is a message in the log of running quake2: Error: R200 timed out... exiting What I can do farther? any ideas? can this problem be related to drm module? what other drm modules I can try ? >> >> PS: I have more problems: If I exit from quake before X locked --- the >> mouse locked (or grabbed ??) I cant use it :( the mouse cursor placed in >> the left top corner of display. and size of display do not returned to >> normal rezolution... but keyboard work and I can cleanly shutdown X >> server... Why this can be? > > Probably quake2 or the 3D driver segfaults before the mouse grab and > graphics mode can be restored, possibly in r200DestroyContext. If it's > crashing in the graphics driver this should be fairly easy to track > down. Enable core dumps (ulimit -c unlimited) and analyze the core dump > with gdb to see where it crashed (gdb -c core `which quake2`). (Caution, > quake2 may be a shell script. You must point gdb the actual executable > instead.) In gdb use the "bt" command to see a call stack trace. "up" > and "down" jump between stack frames. Use "print" to inspect variables. > > (This is just general advise. I don't have any r200 hardware myself > ATM.) -- Dimitry --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Keith Whitwell <[EMAIL PROTECTED]> wrote: > Vladimir Dergachev wrote: > > > > Hi Aapo, Ben, Jerome, Nicolai: > > > >I recently checked fresh code from CVS and was pleasantly surprised > > to see that all Quake3 levels that were broken are now perfect - in fact > > I cannot find anything that is amiss ! > > > >Do you think it would be a good idea to tag the current code and make > > a snapshot ? Why not :) > So have you guys given any consideration to moving the r300 driver into > mesa proper? CVS access shouldn't be a problem, fwiw... I think to few of us have an access to mesa cvs (at leat i didn't have one), anyway i could ask one. But there is still missing parts. I would like to know if anyone know what is still not working and thus do a to do list of that... What i see missing is : (i may not see everythings :-) -deeper testing of tcl program generated with mesa -tex env -fragment program Does ... work ? -z offset -stencil Right now i am on pixel shader after doing some test i don't think we can use a similar stuff like i915 emit arithm, i915 hardware are far more easier to program than r300. I am coding another approach an hope to have it done by the end of this week. Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? Jerome Glisse --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... Keith --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
