[Bug 5104] Xorg 6.8.2 freeze computer when dri is enabled for a Radeon 7000
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=5104 --- Additional Comments From [EMAIL PROTECTED] 2006-01-09 19:15 --- For what it's worth - and this might be totally unrelated to the problem described here - I had a similar problem with my 9200 (non-SE) RV280 card on amd64 2.6.15 on an ASUS K8V-F MB (VIA chipset) with Debian xserver-xorg 6.9.0.dfsg.1-2. It appears that if the glx module is enabled, the default AGPMode will cause problems. Forcing the AGPMode helped, by setting this in the Section Device: Option AGPMode 8 I have also had a report where this helped on a 9600 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Memory management - an AGP manager
Roland Scheidegger wrote: Keith Whitwell wrote: Right now, I'm primarily concerned with unified memory chipsets, like i915 and via. This memory manager would be suitable for managing the AGP memory on non-unified chipsets, but a different implementation would be needed for the on-card video ram, based more on dma and copying than map/unmapping as will be seen below. I'm not sure I quite understand that, do you propose completely separate managers for handling agp and video ram? You're right, I had been thinking as if the two managers could be made disjoint. I guess there will need to be either a mechanism for multiple backends behind the common API, or else the future Video RAM manager I refer to will actually be an extension of the AGP manager I propose which includes handling of Video RAM as well. In any case, I feel that there are benefits in tackling the AGP only case first, basically getting something up and running in a simplified environment to validate aspects of the design before tackling the full problem. Keith --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5459] Quake 4 darkness
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=5459 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 01:13 --- Okay, the issue doesn't occur once I port the changes from r300.sf.net cvs over to mesa cvs head. What I believe is happening is that the nodes which control texture indirection are being setup incorrectly. alu_end and tex_end are actually relative to alu_offset and tex_offset, not to the start of the program. This is one of the things that fixes for some badness on my behalf is referring to in the commit message. I've ported the code from r300 cvs over to current Mesa cvs head. Would you prefer to look that over and commit it, or would you like me to fix this particular issue seperately? -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5459] Quake 4 darkness
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=5459 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 02:52 --- (In reply to comment #5) Okay, the issue doesn't occur once I port the changes from r300.sf.net cvs over to mesa cvs head. What I believe is happening is that the nodes which control texture indirection are being setup incorrectly. alu_end and tex_end are actually relative to alu_offset and tex_offset, not to the start of the program. This is one of the things that fixes for some badness on my behalf is referring to in the commit message. I've ported the code from r300 cvs over to current Mesa cvs head. Would you prefer to look that over and commit it, or would you like me to fix this particular issue seperately? One set of changes will be just fine. -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5104] Xorg 6.8.2 freeze computer when dri is enabled for a Radeon 7000
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=5104 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 02:58 --- I've tried manually setting AGPMode, turning off all BIOS AGP features, etc. to no avail. MSI Master2-FAR (VIA K8T800 chipset). I suspect it has something to do with the R100's not liking the dynamic clocks patch, but frankly I have no idea. -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5459] Quake 4 darkness
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=5459 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 03:25 --- Created an attachment (id=4302) -- (https://bugs.freedesktop.org/attachment.cgi?id=4302action=view) fix node setup Here it is, not tested against anything except a few mesa demos and your test program. -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
On Thu, 2006-01-05 at 06:11 -0500, Adam K Kirchhoff wrote: Anish Mistry wrote: On Wednesday 04 January 2006 10:05 pm, khaqq wrote: On Thu, 5 Jan 2006 04:51:31 + Aapo Tahkola [EMAIL PROTECTED] wrote: On Wed, 04 Jan 2006 21:07:41 -0400 Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? This is a known problem with r9500, r9700 and r9800 cards. You can initialize the card with official drivers. No other fix beyond that exist nor is being planned on. Unless I am missing something, I believe there are no official drivers for FreeBSD from ATI at this point. Someone is working with ATI on it and just posted something last week to the FreeBSD current mailling list. A search should turn up something. I don't know if that'll help at all in this case since it (currently) doesn't have a port of the kernel module and doesn't support any 3D functionality. I'm guessing that it probably won't initialize the card properly, though I could be wrong Hmmm, I might give that a shot next week, though, just to see. Adam Apparently I was wrong. Launching X with the port of the fglrx driver does seem to initialize the card properly, despite the fact that the fglrx port doesn't have a working kernel module. Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
On Sun, 08 Jan 2006 14:31:02 +0100 Rune Petersen [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Alright. Have you been able to reproduce this with any other app? Perhaps if it hits in menus it might be able to track it down but I wouldnt try it otherwise. Also, does it lock always at the same time or is it random? No only Quake 3. in-game lockups are rare, most happens when loading maps (might be locking up on the first frame) the worst map is Q3DM0, which might help track it down. Also r_texturebits 32 vs. r_texturebits 16 increases the chance of a lockup. Could you try Q3DM0 with this patch applied to r300_render.c ? It should ignore all rendering commands at around time leaving menu. Let me know if you cant reproduce the lock with it. BTW, killall -15 quake3.x86; xrandr -s 0 might be handy if it doesnt lock... it does still lockup, I can kill quake3, but am unable to recover the screen. the last screen is loading SOUNDS... So it doesnt hard lock system as it used to? If thats the case, then Im afraid states have something to do with the lock. From r300 drivers point of view, texture depth doesnt really make much difference. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Memory management - another proposal.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
To clarify, a naive (unoptimized) usage pattern would be:
LOCK_HARDWARE()
bboffset = ValidateBuffer( i915-backbuffer )
vboffset = ValidateBuffer( i915-vertex_buffer )
tex0offset = ValidateBuffer( i915-tex_buffer[0] )
if (!bboffset || !vboffset || !texoffset)
FALLBACK_PATH()
else {
emit_state_packets();
emit_3d_prim();
SetFence()
}
UNLOCK_HARDWARE()
There is a problem with this design. You really need to validate a set
of buffers rather than one buffer at a time. Imagine the case where
those 3 buffers will exactly fill all of memory. Placing the first
buffer incorrectly will make it impossible to place the other buffers
without invalidating the first.
Other than that, this is pretty similar to what anholt, keithp, and I
came up with a few weeks ago. I just haven't started banging away at it
yet. I found it very easy to be distracted from coding projects over
the holiday. :) I believe that we used the name CommiteBuffers
instead of ValidateBuffer, but the idea is the same.
I've also come around to just putting everything in the kernel. I've
been convinced (finally) that the perceived benefits of having the
actual allocator in user mode (avoiding some trips into the kernel,
having the allocation policy in user mode) don't outweigh the problems
that it creates.
In the event of defragmentation of the address space, buffers
validated previously within a Locked region may become invalid and
validation of buffers will have to restart. I'll gloss over that for
now.
I'm not 100% sure what you mean by this. Are you saying that you'd have
to loop on the ValidateBuffer calls until some steady state is achieved?
In the worst case, that loop would never terminate. :(
If you know at CommitBuffers which buffers are needed, you can try to
trivially commit the buffers (i.e., don't shuffle buffers or kick
anything out). If that fails, you shuffle buffers and kick buffers out
of memory until there is a free block large enough to hold all of the
required buffers. Then repeat the trivial commit (it *must* succeed at
this point).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDwpDjX1gOwKyEAw8RAn60AJ9B5gYdiMrvc4f3apRFQPCg//TmwwCfaEbX
J4uabn186nqgbuyr+7c8lq8=
=bnG2
-END PGP SIGNATURE-
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Memory management - an AGP manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Herrenschmidt wrote: - Caching issues. On a lot of chipsets, AGP memory must be mapped non-cacheable. This isn't trivial on all architectures and it's not always feasible to do with userland buffers. That means that either the cache must be flushed at the time of the mapping _and_ the buffer not touched at all by the CPU until it's unmapped, or the map call must change the userland mapping to the buffer to mark it uncached. The problems of course starts popping up if this buffer happens to be shared between multiple processes... also, that user memory will also be mapped in the kernel as part of the kernel's linear mapping, which is cacheable. Thus you'll end up with pages mapped both cacheable and non-cacheable in different contexts. This is a good way to cause checkstops with a number of CPUs (certainly with PowerPC and I think also with amd's). (At this point, for those who didn't figure out yet that AGP was just a piece of crap in the first place, welcome to the real world) There must be some way to deal with all this sanely on PPC. Apple has a number of OpenGL extensions for making user memory directly accessable to the graphics engine. Perhaps their specs can provide some clues as to how they do it? http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt http://oss.sgi.com/projects/ogl-sample/registry/APPLE/vertex_array_range.txt http://developer.apple.com/graphicsimaging/opengl/extensions/apple_texture_range.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDwphDX1gOwKyEAw8RAlbbAJ9B42ZX+19keJ1tUo5hJa+43YouFgCfUIsl DV99Rz8I5HS9BXWWxOCyDWw= =fweg -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Memory management - another proposal.
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
To clarify, a naive (unoptimized) usage pattern would be:
LOCK_HARDWARE()
bboffset = ValidateBuffer( i915-backbuffer )
vboffset = ValidateBuffer( i915-vertex_buffer )
tex0offset = ValidateBuffer( i915-tex_buffer[0] )
if (!bboffset || !vboffset || !texoffset)
FALLBACK_PATH()
else {
emit_state_packets();
emit_3d_prim();
SetFence()
}
UNLOCK_HARDWARE()
There is a problem with this design. You really need to validate a set
of buffers rather than one buffer at a time. Imagine the case where
those 3 buffers will exactly fill all of memory. Placing the first
buffer incorrectly will make it impossible to place the other buffers
without invalidating the first.
Yes, I gloss over this a little. The intention is that Validate buffers can
fail once and the process is required to start again - giving the manager a
chance to start from scratch -- it's a little kludgey. Alternately you could of
course wrap that kludginess up in a single function which the driver passes a
list of buffers.
Other than that, this is pretty similar to what anholt, keithp, and I
came up with a few weeks ago. I just haven't started banging away at it
yet. I found it very easy to be distracted from coding projects over
the holiday. :) I believe that we used the name CommiteBuffers
instead of ValidateBuffer, but the idea is the same.
Oh... Sorry I missed out that conversation... Should I have been listening
somewhere?
I've also come around to just putting everything in the kernel. I've
been convinced (finally) that the perceived benefits of having the
actual allocator in user mode (avoiding some trips into the kernel,
having the allocation policy in user mode) don't outweigh the problems
that it creates.
I do a little bit to avoid kernel trips with the conditions where an offset from
ValidateBuffer can be reused. In steady-state rendering, there should be no
need to call into the kernel at all.
In the event of defragmentation of the address space, buffers
validated previously within a Locked region may become invalid and
validation of buffers will have to restart. I'll gloss over that for
now.
I'm not 100% sure what you mean by this. Are you saying that you'd have
to loop on the ValidateBuffer calls until some steady state is achieved?
In the worst case, that loop would never terminate. :(
This is all about the single buffer parameter vs. a list. I think you've
convinced me that a list is a better api.
If you know at CommitBuffers which buffers are needed, you can try to
trivially commit the buffers (i.e., don't shuffle buffers or kick
anything out). If that fails, you shuffle buffers and kick buffers out
of memory until there is a free block large enough to hold all of the
required buffers. Then repeat the trivial commit (it *must* succeed at
this point).
That's exactly it.
Keith
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5459] Quake 4 darkness
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=5459 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 05:41 --- (In reply to comment #7) Created an attachment (id=4302) -- (https://bugs.freedesktop.org/attachment.cgi?id=4302action=view) [edit] fix node setup Here it is, not tested against anything except a few mesa demos and your test program. Commited. That didnt fix q4 though. Do you have the other patch around so I can check it in? -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
glAreTexturesResident()
Hi,
While I was studying OpenGL with Mesa, I got a problem concerning
glAreTexturesReside().
First, please skim the following small glut program, whose original
purpose is to illustrate how to do texture prioritization with
OpenGL API, though the prioritization is not the issue of this
note.
#include GL/glut.h
GLuint texture;
void init(void)
{
GLubyte pixel[] = { 0xff, 0xff, 0xff };
GLclampf priority = 1.0f;
glGenTextures(1, texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexImage2D(GL_TEXTURE_2D, 0, 3, 1, 1, 0,
GL_RGB, GL_UNSIGNED_BYTE, pixel);
glPrioritizeTextures(1, texture, priority);
glEnable(GL_TEXTURE_2D);
}
void display(void)
{
GLboolean residence = GL_FALSE;
glAreTexturesResident(1, texture, residence);
}
int main(int argc, char *argv[])
{
glutInit(argc, argv);
glutInitDisplayMode(GLUT_RGBA);
glutCreateWindow(argv[0]);
glutDisplayFunc(display);
init();
glutMainLoop();
return 0;
}
Do you see anything wrong with the code above? Actually,
it compiles. It works fine if direct rendering is enabled.
I found, however, it resulted in segfault when I did
$ LIBGL_ALWAYS_INDIRECT=1 ./prog
That's the problem I got.
Looking for the cause of the segfalut, I used gdb with
the core dumped. But it didn't give me any useful clue
for the cause because it only suggested that the value of
an internal variable of glut was invalid, which I thought
was irrelevant to the problem.
So, after tweaking the code above, I found:
(1) If the call of glAreTexturesResident() was removed,
segfault didn't take place.
(2) If either the scope or the storage type of 'residence',
which is a local variable of the function display(),
was changed to local static or global, segfalut didn't
take place. (In this case, the glAreTexturesResident
code was not removed.)
Since the fact (2) suggested that there was something wrong
with the stack or frame, I suspected it was due to a bug
of the compiler I used. But I soon came to realize that
it was fairly unlikely: the same problem arose even with
the binary compiled with gcc-2.95.3 or gcc-3.4.4, not only
with the latest gcc-4.0.2.
So I concluded, as the fact (1) suggested, that there was
something wrong with glAreTexturesResident(), to be more
specific, __indirect_glAreTexturesResident(), whose
implementation was given src/glx/x11/indirect.c.
At line 4306 of the file, the function
GLboolean
__indirect_glAreTexturesResident(GLsizei n,
const GLuint *textures,
GLboolean *residences);
is defined. Unless USE_XCB is defined, the function invokes
CARD32
__glXReadDisplay(Display *dpy,
size_t size,
void *dest,
GLboolean reply_is_always_true);
with the parameters size = 1, dest = residences, and
reply_is_always_true = GL_TRUE.
The implementation of __glXReadDisplay() is given at line 66
of the same file. The following is the excerpt of the
implementation:
xGLXSingleReply reply;
_XReply(dpy, reply, 0, False);
if (size != 0) {
if ((reply.length 0) || reply_is_always_true) {
const GLint bytes = (reply_is_always_array)
? (4 * reply.length) : (reply.size * size);
...
_XRead(dpy, dest, bytes);
...
}
...
}
Since size = 1, and reply_is_always_true = GL_TRUE in our
particular case, the value of the local variable 'bytes' is
equal to that of 4 * reply.length if reply.length 0. This
implies that we let _XRead() write the reply from the server
to the parameter 'dest' as if the storage size 'dest' points
to were at least 4 bytes, which is wrong in our particular
case where 'dest' is actually a pointer to a variable of type
GLboolean.
I think this caused the segfault I mentioned in the middle
of this note. It also seemingly explains the undefined
behavior-like phenomenon, i.e., the fact (2).
It looks to me that the implementation of __glXReadDisplay()
is valid only for the case where the parameter 'size' is set
to 4. IOW, the case for 'size' = 1, 2 is not appropriately
supported.
Did I miss something?
Thanks,
KK
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5459] Quake 4 darkness
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=5459 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 07:48 --- Created an attachment (id=4304) -- (https://bugs.freedesktop.org/attachment.cgi?id=4304action=view) Missing code from r300.sf.net cvs Okay. There's quite a few changes in there, I don't recall it breaking anything but I can't be sure. Doom3 seemed to look almost fine (once disabling S3TC) so hopefully Quake4 will also. I couldn't test quake4 as it was SEGV'ing somewhere after tnl/t_vb_arbprogram_sse.c::build_vertex_program(). -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5459] Quake 4 darkness
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=5459 --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 08:21 --- That patch makes some static functions non-static, without adding the r300 prefix to the function name. Doesn't seem like a good idea? -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Memory management - an AGP manager
There must be some way to deal with all this sanely on PPC. Apple has a number of OpenGL extensions for making user memory directly accessable to the graphics engine. Perhaps their specs can provide some clues as to how they do it? http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt http://oss.sgi.com/projects/ogl-sample/registry/APPLE/vertex_array_range.txt http://developer.apple.com/graphicsimaging/opengl/extensions/apple_texture_range.html They probably make the user memory non-cacheable... or maybe they just flush the cache region occupied by the texture when submited since I don't think one is allowed to modify it after it's been submited, unless I mistread something. MacOS X doesn't have a linear mapping of memory afaik and doesn't use large pages, so they can more easily play with individual page cacheability without creating paradox (though their kernel is slower than linux overall). Im certain that Apple AGP host bridge doesn't support cached memory and most revisions of it don't support stores to AGP from the GPU neither. Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] CVS build broken - debug_vp()
Hi, CVS build is broken, because debug_vp() was removed. Solutions: Replace the last call to debug, or recommit debug_vp(). Rune Petersen --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5459] Quake 4 darkness
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=5459 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-01-10 10:05 --- (In reply to comment #9) Created an attachment (id=4304) -- (https://bugs.freedesktop.org/attachment.cgi?id=4304action=view) [edit] Missing code from r300.sf.net cvs Okay. There's quite a few changes in there, I don't recall it breaking anything but I can't be sure. Thanks. Iv checked it in. Doom3 seemed to look almost fine (once disabling S3TC) so hopefully Quake4 will also. I couldn't test quake4 as it was SEGV'ing somewhere after tnl/t_vb_arbprogram_sse.c::build_vertex_program(). q4 worked for me when sse codegen was turned off. Ill see if I can get it to work with hw vertex shaders. -- 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
