Philip Brown wrote:
> I note that the apparent sole purpose for drm_write_string() is to
> record context switches in a buffer, which can be read by processes
> doing userland read() calls on the drm dev.
> Is this for debug purposes only?
Probably. I didn't know it was there...
Keith
-
Philip Brown wrote:
> If I'm reading the drm source right, there seems to be either
> 32,000 or 64,000 contexts provided for, with the ctxbitmap routines.
>
> Isnt that overkill for typical use? Wont the average user tend to have
> MAYBE 5 or 10 active contexts at a time, and no more than that?
> hmm, that's odd. I still get floating point exceptions for almost every
> GL-app. with TCL disabled.
>
> Demos that _do_ work with TCL disabled include:
> clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos
>
> Maybe this can give you a clue, why some are working and some aren't?
>
>
Russ Dill wrote:
> On Tue, 2002-10-15 at 10:01, Stefan Lange wrote:
>
>
>>Q3A: stable (at least for the time I tested), but not very fast. In fact
>>it shows the same symptoms I got with earlier versions of DRI-trunk
>>(before around 2002-10-11): poor overall speed, and a framerate that
>>max
A. H. Gee wrote:
Hi everyone,
Hopefully a useful data point: the radeon nightly snapshots now work
for me as long as I use Jose's libxaa.a. Without the new libxaa.a, I
get the much reported blank screen. Looks like we need to bundle
libxaa.a with the nightly backups.
The radeon driver works fine
Michel Dänzer wrote:
On Fre, 2002-10-11 at 18:52, Felix Kühling wrote:
On 11 Oct 2002 18:15:08 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
I was looking into the lighting issues Felix reported with the
xscreensaver pulsar hack (when running it with the -light option).
[...]
One obser
Felix Kühling wrote:
> On 11 Oct 2002 18:15:08 +0200
> Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
>
>>I was looking into the lighting issues Felix reported with the
>>xscreensaver pulsar hack (when running it with the -light option). One
>>side of the planes looks good, the other one is black, s
> I've tested the radeon, r200 and tdfx drivers and they seem OK.
>
> I can't test the i810, i830, r128, mga, etc drivers (either because I don't
> have the right hardware or mine's broke). Some of the other drivers (like
> sis, ffb, etc) aren't enabled in the build process and haven't been por
Adam Duck wrote:
>>"Joe" == Joe Mackay <[EMAIL PROTECTED]> writes:
>>
>
> Joe> On Thu, 10 Oct 2002, Frank Van Damme wrote:
>
> >> www.student.kuleuven.ac.be/~m9917684/r200-20020920-linux.i386.tar.bz2 should
> >> work.
>
> Joe> Brilliant... thanks, you're a star!
>
>
Tom Hosiawa wrote:
> What exactly is drm_radeon_depth_clear_t storing; is it registers on the card having
>something to do with the way depth buffers get used???
If you look at where it's used, you get a clue that these are register values:
OUT_RING_REG( RADEON_RB3D_ZSTENCILCNTL
José Fonseca wrote:
> Keith,
>
> I'm curious to know how you reminded after so long (7 months)! Did you
> actually writed it now or was it stuck in a mail queue all this time?
>
> By now I got to more or less to those answers, but thanks anyway. As
> saying goes: it's better late than never!
>
José Fonseca wrote:
> The current mach64 (mesa 4.x) driver doesn't seem to be doing z depth
> test. After assuring that the mach64's z control register was being set
> properly I realized that the vertex buffers had the z in a [0,1] scale
> while the primitive drawing functions expected them in
Brian Paul wrote:
>
> in drm_os_linux.h in the DRM_WAIT_ON macro there's:
>
> schedule_timeout(max(HZ/100,1)); \
>
> Where is max() supposed to be defined? It's undefined when I compile here.
> Replacing it with:
>
> schedule_timeout((HZ/100 > 1) ? HZ/100 : 1);\
>
So
Ian Romanick wrote:
> On Wed, Oct 09, 2002 at 07:57:18AM -0600, Brian Paul wrote:
>
>
>>I've whipped up an HTML table which summarizes the features of the DRI drivers.
>>Maybe one of the web masters can incorporate it into the website.
>>
>
> Couple quick corrections. I don't think R200 suppor
Keith Whitwell wrote:
> Brian Paul wrote:
>
>> Dieter Nützel wrote:
>>
>>> cvs update
>>> M xc/config/cf/host.def
>>> M xc/config/cf/xf86site.def
>>> M xc/config/cf/xfree86.cf
>>> P xc/lib/GL/mesa/src/drv/r200/r200_ioctl
Brian Paul wrote:
> Dieter Nützel wrote:
>
>> cvs update
>> M xc/config/cf/host.def
>> M xc/config/cf/xf86site.def
>> M xc/config/cf/xfree86.cf
>> P xc/lib/GL/mesa/src/drv/r200/r200_ioctl.c
>> cvs server: [16:53:25] waiting for anoncvs_dri's lock in
>> /cvsroot/dri/xc/xc/lib/GLw
>> cvs server: [
Felix Kühling wrote:
> Hi Keith,
>
> I attached a new r100 waiting patch against the latest trunk. I assume
> that you have the most up-to-date r200 waiting code in your tree. I
> added EAGAIN to conditions handled gracefully. But I couldn't find any
> situation in which the DRM_RADEON_IRQ_WAIT i
Felix Kühling wrote:
> Hi Keith,
>
> I attached a new r100 waiting patch against the latest trunk. I assume
> that you have the most up-to-date r200 waiting code in your tree. I
> added EAGAIN to conditions handled gracefully. But I couldn't find any
> situation in which the DRM_RADEON_IRQ_WAIT i
Brian Paul wrote:
> Keith Whitwell wrote:
>
>> Ti Leggett wrote:
>>
>>> There seems to be a 512x512 OpenGL texture size limit for ATI 7500
>>> Mobility. There's a game I'm helping test and it uses textures over
>>> 1024x1024 and they work
Ti Leggett wrote:
> There seems to be a 512x512 OpenGL texture size limit for ATI 7500
> Mobility. There's a game I'm helping test and it uses textures over
> 1024x1024 and they work on a regular ATI 7500 but don't on a 7500
> Mobility. 512x512 textures do work though. Any ideas why this is? It's
Ian Romanick wrote:
> On Fri, Sep 27, 2002 at 07:53:22PM +0100, Keith Whitwell wrote:
>
>
>>One option is to have the kernel actually do the fixup of the buffers when
>>they are submitted by the client, so the driver never knows really where it's
>>textures are
>
> Could it be that the AGP bus is the limiting factor and pushing TCL
> vertices requires more bandwidth than just pushing rasterization info?
Maybe, but the difference Felix reports (1%) might as well be noise.
> Sorry, I know we shouldn't even get into it regarding gears...it's not a
> b
Ian Romanick wrote:
> On Thu, Sep 26, 2002 at 07:20:58AM +0100, Keith Whitwell wrote:
>
>>Ian Romanick wrote:
>>
>>>- Do we really need the &3 in radeon_vtxfmt_c.c:
>>>
>>> static void radeon_MultiTexCoord1fARB( GLenum target, GLfloat s )
&g
Felix Kühling wrote:
> On 03 Oct 2002 11:01:57 +0200
> Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
>
>>On Don, 2002-10-03 at 01:52, thork wrote:
>>
>>
>>>about the aperture thing, he told me those 8Mb where from system memory
>>>not from the video card memory, I found this thing in the log:
>>>(
Linus Torvalds wrote:
> On Tue, 1 Oct 2002, Keith Whitwell wrote:
>
>>Sounds like you aren't getting irq's, for some reason, and it is falling back
>>to busy waiting.
>>
>>The question is why aren't you getting irq's?
>>
>
> Keith,
Andy Dustman wrote:
> I managed to get the r200 driver working again by doing a complete CVS
> install. Some notes:
>
> * The card does now seem to generate interrupts at about the same
> frequency as the current mode's vertical refresh.
>
> * Surprisingly (for me, at least), glxgears is now run
Michel Dänzer wrote:
> On Mit, 2002-10-02 at 14:41, Keith Whitwell wrote:
>
>>Michel Daenzer wrote:
>>
>>
>>> * environment variables are checked every time instead of just once on
>>>context setup
>>>
>>What's the logic b
Michel Daenzer wrote:
> * environment variables are checked every time instead of just once on
> context setup
What's the logic behind this?
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkg
Karl Rasche wrote:
>>My first question, I haven't looked at the code properly yet, is about ioctl
>>numbers. Where are they coming from? How do we avoid overlapping with the
>>driver-specific ioctl numbers?
>>
>
>>From what I gather from drm.h, the driver specific ioctls are supposed to
> be
> I definitely running this on my dual Athlon with latest ACPI for 2.4.19 and
> irq's routing enabled, I think.
>
> With "procinfo -f" I see ~980 irq/sec during "gears".
>
> Same with r200 code from yesterday. But it was much faster.
I think I may have fixed your problem (thanks to Felix), ca
Felix Kühling wrote:
> Keith,
>
> you got the condition for waiting for an interrupt wrong.
>
> r200_ioctl.c, line 330
> ...
> /* if there was a previous frame, wait for its IRQ */
> - if (iw->irq_seq != -1 && sarea->last_frame < r200GetLastFrame( rmesa ) ) {
> + if (iw->irq_
Karl Rasche wrote:
> Keith,
>
> In free_block(), radeon_mem.c, we have:
>
> if (p->next->pid == 0) {
> struct mem_block *q = p->next;
>
> p->size += q->size;
> p->next = q->next;
> p->next->prev = p;
>
> DRM_FREE(p);
> }
>
> Should this instead be:
>
> if (p->next->pid
Karl Rasche wrote:
>
> Attached is a patch to attempt to duplicate the r200 agp allocator,
> independant of any one particular drivers' code.
>
> Also, is a quick implementation for the mga driver.
>
> Hopefully I went about this in a somewhat correct mannor. If not, please
> let me know...
>
Dieter Nützel wrote:
> Keith,
>
> after your latest r200 IRQ merge "setenv R200_NO_USLEEPS 1" is badly needed,
> again?
>
> gears is lower than ever
>
> Mesa/demos> ./gears
> r200CreateScreen
> 550 frames in 5.019 seconds = 109.584 FPS
> 566 frames in 5.016 seconds = 112.839 FPS
> 574 frames
Felix Kühling wrote:
> Hi r200'ers,
>
> here is the improved frame throttling for r200. It compiles on my
> system. Time for testing ...
>
I still get a lot of busy waiting with this patch. I assume the behaviour is
the same on the radeon. Run it against 'multiarb' from the mesa demos. Ever
Felix Kühling wrote:
> On Sun, 29 Sep 2002 22:37:36 +0100
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
>
>>Felix Kühling wrote:
>>
>>>On Sun, 29 Sep 2002 23:25:03 +0200
>>>Dieter Nützel <[EMAIL PROTECTED]> wrote:
>>>
>>>
&
Brian Paul wrote:
> Felix Kühling wrote:
>
>> Hello,
>>
>> Modifying the frame throttling code in r200_ioctl.c I removed
>> R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
>> still used in r200Clear:
>>
>> if ( rmesa->sarea->last_clear - clear <= R200_MAX_OUTSTANDING+1
Felix Kühling wrote:
> Hello,
>
> Modifying the frame throttling code in r200_ioctl.c I removed
> R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
> still used in r200Clear:
>
> if ( rmesa->sarea->last_clear - clear <= R200_MAX_OUTSTANDING+1 ) {
>break;
>
MAIL PROTECTED]> wrote:
>>>
>>>>On Sun, 29 Sep 2002 13:22:44 -0700
>>>>
>>>>Keith Whitwell <[EMAIL PROTECTED]> wrote:
>>>>
>>>>>CVSROOT: /cvsroot/dri
>>>>>Module name: xc
>>>>>Rep
Felix Kühling wrote:
> On Sat, 28 Sep 2002 16:31:56 +0100
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
>>Using a static variable doesn't cut it -- that should go into the
>>radeonContext struct in radeon_context.h.
>>
>>Beyond
Felix Kühling wrote:
> On Sat, 28 Sep 2002 14:56:38 +0100
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
>
>>Felix Kühling wrote:
>>
>>>Hi,
>>>
>>>I was able to reduce CPU usage of applications which use glFinish by
>>>emitting
Should we stop producing snapshots temporarily until the
xaa/compiler/who-knows-what problems are resolved?
There seem to be a lot of complaints about the ones up there now...
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to
Anders Rune Jensen wrote:
> Hello
>
> I've been using the r200 driver from your snapshot directory for about
> two weeks but I have had some problems. Right now I'm running the
> r200-0-2 branch (cvs) from the 20 sep. Xvideo in mplayer is just
> black, Xvidix is pink :)) (that's probably because
Felix Kühling wrote:
> Hi,
>
> I was able to reduce CPU usage of applications which use glFinish by
> emitting and waiting for an IRQ in radeonFinish before
> radeonWaitForIdle. I'm not sure whether radeonWaitForIdle is still
> needed after waiting for the IRQ, but keeping it does at least not hu
Michel Dänzer wrote:
> On Fre, 2002-09-27 at 18:51, Keith Whitwell wrote:
>
>>>>It's a big hack to be doing this.
>>>>
>
> BTW it also seems to work for him without writing to GEN_INT_CNTL all
> the time, i.e. only acknowledging the bits in GEN_IN
>
> Right. Here's my updated suggestion. Leave the '&3' in the patch, but
> expand the 'vertex' array in radeon_vb from 15 elements to 17. That will
> prevent code like
>
> glMultiTexCoord2fv( GL_TEXTURE3, foo );
Yes, that works for this path. The other you have to look at is where t
>>
>>It's a big hack to be doing this. I'd really like to know why this happens,
>>
>
> So would I. I suspect it's a workaround for some problem, it worked fine
> here without. (as I said on IRC yesterday: but then I have sane hardware
> :)
>
>
>>but in the mean time I'm ok to see it go in.
Michel Dänzer wrote:
> On Fre, 2002-09-27 at 16:47, Keith Whitwell wrote:
>
>>Michel Dänzer wrote:
>>
>>>On Don, 2002-09-26 at 18:17, Keith Whitwell wrote:
>>>
>>>
>>>>Michel Dänzer wrote:
>>>>
>>>>
>>
Stephane Chauveau wrote:
> Hi,
>
> The r200 dri drivers are working fine on my system but I noticed
> something strange in my logs:
>
> (**) RADEON(0): Using AGP 4x mode
> (II) RADEON(0): AGP Fast Write disabled by default
>
> My bios says that AGP Fast Write is enabled.
>
> Is there an issue
Michel Dänzer wrote:
> On Don, 2002-09-26 at 18:17, Keith Whitwell wrote:
>
>>Michel Dänzer wrote:
>>
>>>Something else I've been thinking about is that relying on the
>>>swi_emitted and swi_received counters being in sync is pretty fragile.
>&g
Michel Dänzer wrote:
> On Don, 2002-09-26 at 22:23, Ian Romanick wrote:
>
>>Attached is a patch to fix the
>>
>>drmRadeonCmdBuffer: -22
>>
>>problem in the SW TCL path (used on Radeon VE & M6 cards) in the Radeon
>>driver. It turns out that not every place in the code was using the right
>>pack
Michel Dänzer wrote:
> On Don, 2002-09-26 at 10:24, Eric Anholt wrote:
>
>>On Thu, 2002-09-26 at 00:58, Eric Anholt wrote:
>>
>>>CVSROOT: /cvsroot/dri
>>>Module name: xc
>>>Repository: xc/xc/lib/GL/mesa/src/drv/r200/
>>>Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14
>>>
>>>Log messag
Ian Romanick wrote:
> On Thu, Sep 26, 2002 at 03:00:02AM +0200, Michel Dänzer wrote:
>
>
>>I've been wondering for some time why at least the Quake 2 engine is
>>very slow with multitexturing enabled, i.e. with
>>
>>set gl_ext_multitexture "1"
>>
>>in ~/.quake2/baseq2/config.cfg, it crawls on st
Eric Anholt wrote:
> On Thu, 2002-09-26 at 00:58, Eric Anholt wrote:
>
>>CVSROOT: /cvsroot/dri
>>Module name: xc
>>Repository: xc/xc/lib/GL/mesa/src/drv/r200/
>>Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14
>>
>>Log message:
>> R200 sync-to-vblank support (set LIBGL_THROTTLE_RE
Ian Romanick wrote:
> Here is a patch that will enable the 3rd texture unit in the Radeon
> R100/RV200 driver. I have tested it using multiarb on a Radeon "classic"
> DDR and a Radeon M6 (AGP developer board). There are a few issues that I
> came across that should be resolved before applying.
>
Michel Dänzer wrote:
> On Mit, 2002-09-25 at 04:17, Michel Dänzer wrote:
>
>>On Mit, 2002-09-25 at 03:52, Eric Anholt wrote:
>>
>>>On Tue, 2002-09-24 at 17:08, Michel Dänzer wrote:
>>>
BTW I'm just experiencing IRQ timeouts as well. In fact, no interrupts
occur at all, and the RADEON_GEN_
Michel Daenzer wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
> Changes by: mdaenzer@usw-pr-cvs1. 02/09/25 10:17:37
>
> Log message:
> IRQ related fixes
>
> Modified files:
> xc/xc/programs/Xserver/hw/xfree86/driv
Vikberg, Gunnar wrote:
> I am new to this list, but I would like to help with the development of the R200 and
> the new R300 series of GPU/VPU from ATI. I am already a registered developer with
> ATI, and my question is where I can get the source code for the R200 drivers (and
> R300 if available)
Karl Rasche wrote:
>>Do you mean a generic extension (ie separate out the allocator bits of
>>GL_NV_vertex_array_range), or a generic implementation?
>>
>
> A generic implementation.
Yes, I think this is worthwhile. There's very little that isn't generic in
radeon_mem.c as it stands.
Keith
Karl Rasche wrote:
>>The r200 driver has the allocator parts of GL_NV_vertex_array_range, and can
>>
>
> Keith,
>
> I'd be interested in trying to get this working with the mga driver. Would
> it be worth to try and move things to a generic allocator?
Do you mean a generic extension (ie sepa
Ian Romanick wrote:
> I noticed that some code from Mesa was recently folded into DRI to support
> APPLE_client_storage. What does it take to enable that in a driver? Is it
> like SGIS_generate_mipmaps in that the driver just needs to enable it?
>
> On a related note, some time ago (on an IRC m
Alan Hourihane wrote:
> Keith,
>
> This should do it.
>
> {
> PixmapPtr pspix;
> pspix = (*pScreen->GetScreenPixmap) (pScreen);
> (*pScreen->ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
> info->FB + XXXOFFSETX );
Michel Dänzer wrote:
> On Die, 2002-09-24 at 16:59, Keith Whitwell wrote:
>
>>>You can't change the offset in the chip or offscreen access goes after
>>>whatever buffer is front. You'd have to use coordinate deltas, but only
>>>if the coordinates are w
>
> I missed that thread, actually... are you talking about the
> r200WaitForFrameCompletion one, or somewhere else?
Yes.
>
>>>So, I'm looking to understand why the standard glxgears now renders slower
>>>than software fallbacks used to, and why now when I use R200_NO_RAST I only
>>>see 50FP
> You can't change the offset in the chip or offscreen access goes after
> whatever buffer is front. You'd have to use coordinate deltas, but only
> if the coordinates are within the virtual resolution, and even then I'm
> not sure that would always work. Try and see I guess. :)
If so, it's a fu
Jan Schmidt wrote:
> Keith,
>
> I'm looking to understand the behaviour I'm seeing since I installed
> the main branch today.
>
> With the default settings, and glxgears, I see:
> r200CreateScreen
> 1077 frames in 5.0 seconds = 215.400 FPS
>
> (Previously, I'd see around 300FPS for software ren
Michel Dänzer wrote:
> On Die, 2002-09-24 at 13:11, Keith Whitwell wrote:
>
>>I've been thinking again about pageflipping & realized I can solve the
>>remaining few problems if I can tweak the behaviour of the 2d driver slightly.
>>
>>At the moment, th
Alan, Others,
I've been thinking again about pageflipping & realized I can solve the
remaining few problems if I can tweak the behaviour of the 2d driver slightly.
At the moment, the 2d driver always draws to buffer zero (the old front
buffer), and then at some point in the future, the dirty
n001 wrote:
> Small bug report of the latest r200-02-2 branch
> (cvs checkout just before the merge in trunk)
>
> With a lot of loki demos, i have this error:
>
> r200WaitForFrameCompletion: drmRadeonIrqWait: -16
>
> I have a radeon 8500 "powered by ati"
>
Hmm. After this happens, and you ru
>
>>One worry I have with the radeon_irq.c code at the moment is the proliferation
>>of ifdef's for linux vs. freebsd code. I'd like to see this get cleaned up --
>>if nothing else it's ugly...
>>
>
> It's not quite as bad with this patch, still we might want to define
> DRM_WAKEUP or simila
I've submitted a support request to sourceforge wrt the lock:
cvs server: [05:06:29] waiting for anoncvs_dri's lock in
/cvsroot/dri/xc/xc/extras/X-TrueType/GB2312
that seems to have been left behind in our cvs tree. Hopefully it can be
cleared up quickly.
Keith
---
I'm going to be merging this code today.
Mostly it is additional functionality, so hopefully the potential for new bugs
is limited.
One thing it does address is the R200_NO_USLEEPS issue -- there is now a
primitive irq-based mechanism to do the throttling instead of the earlier busy
wait (wit
Michel Dänzer wrote:
> On Fre, 2002-09-20 at 19:46, Keith Whitwell wrote:
>
>>Garry Reisky wrote:
>>
>>>I know Keith said he didn't want much feedback on this branch becaues it
>>>could be breaking severly. I just wanted to say great job on the latest
&
Eric Anholt wrote:
> On Sat, 2002-09-21 at 07:21, Michel Dänzer wrote:
>
>>On Fre, 2002-09-20 at 17:30, Andreas Stenglein wrote:
>>
>>>I tried to port Andreas Ehliar's mga-stereo-patch
>>>(http://www.lysator.liu.se/~ehliar/3d/)
>>>to current DRI-CVS.
>>>
>>>I think its almost done, but now the b
Michel Dänzer wrote:
> On Son, 2002-09-22 at 19:18, Keith Whitwell wrote:
>
>>Michel Dänzer wrote:
>>
>>>I currently get an oops on client shutdown when radeon_mem_release() is
>>>called on the agp_heap, which isn't initialized. Probably is i
Michael Mazack wrote:
> Hello, I'm new to the list. I don't know whether this
> information is helpful or not, but I think there is a
> problem with r200SetTexImages. I am using the latest
> r200-0-2-branch from cvs. When I try to play Heavy
> Gear 2 I get a countless amount of these error
> messa
Michel Dänzer wrote:
> On Fre, 2002-09-20 at 19:46, Keith Whitwell wrote:
>
>>Garry Reisky wrote:
>>
>>>I know Keith said he didn't want much feedback on this branch becaues it
>>>could be breaking severly. I just wanted to say great job on the latest
&
Michel Dänzer wrote:
> On Sam, 2002-09-21 at 21:40, Keith Whitwell wrote:
>
>>>I'm afraid it's not that simple because the radeon driver no longer
>>>keeps the offscreen memory it needs for 3D allocated all the time. It
>>>may fail to allocate it
> I'm afraid it's not that simple because the radeon driver no longer
> keeps the offscreen memory it needs for 3D allocated all the time. It
> may fail to allocate it when a 3D client starts if offscreen XVideo
> images are in use. Is there a way to get at all of them so their
> offscreen region
Pasi Kärkkäinen wrote:
> Hello!
>
> http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt
> http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_program.txt
>
> Now when ARB has approved extensions for both pixel- and vertex-shaders,
> are there any problems supporting t
Garry Reisky wrote:
> I know Keith said he didn't want much feedback on this branch becaues it
> could be breaking severly. I just wanted to say great job on the latest
> checkins.
The breakages should be reducing now (hopefully). I didn't do some of the
more radical stuff I thought I might hav
> PS: Shouldn't it be wake_up_interruptible_all() instead of
> wake_up_interruptible() in DRM(dma_immediate_bh)() as well?
Maybe, please explain the difference...
> PPS: The branch doesn't build completely for me:
>
> radeon_dri.c: In function `RADEONDRIAgpHeapInit':
> radeon_dri.c:848: `drmRa
Michel Dänzer wrote:
> http://penguinppc.org/~daenzer/DRI/radeon-vblank.diff
>
> This patch against r200-0-2-branch adds an ioctl to wait for vertical
> blank interrupts and has been working pretty well for me. I'd appreciate
> some feedback about a couple points:
I've committed my missing stuff
Jacek Rosik wrote:
> Michel Dänzer wrote:
>
>> On Wed, 2002-06-26 at 02:35, Jacek Rosik wrote:
>>
>>> BTW: Why in function radeon_emit_clip_rect
>>> (xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c)
>>> line:
>>> /* OUT_RING( ((box->y2 - 1) << 16) | (box->x2 - 1) );*/
Henry Worth wrote:
>
> Michel,
>
> How do these changes for r128 COMMIT_RING look? With these I can run
> concurrent xine and glx programs in pci and agp mode with XV dma
> disabled.
>
> With XV dma enabled, in both pci and agp mode, I can run xine for some
> time without any hangs. But startup
Leif Delgass wrote:
> On Wed, 17 Jul 2002, Keith Whitwell wrote:
>
>
>>Leif Delgass wrote:
>>
>>>On Wed, 17 Jul 2002, Leif Delgass wrote:
>>>
>>>
>>>
>>>>On 17 Jul 2002, Michel Dänzer wrote:
>>>>
>>>>
&
Leif Delgass wrote:
> On Wed, 17 Jul 2002, Leif Delgass wrote:
>
>
>>On 17 Jul 2002, Michel Dänzer wrote:
>>
>>
>>>On Wed, 2002-07-17 at 20:05, Keith Whitwell wrote:
>>>
>>>>I've fixed this for drivers that use t_dd_triemit.h
I've fixed this for drivers that use t_dd_triemit.h -- currently only radeon
and r200. Basically any driver with a 'fast_clipped_poly' function needs to
check that the vertices are emitted preserving the PV order. I think most/all
are wrong currently.
Keith
--
OK, I've got enough info to get an idea of what hardware variation exists out
there. Thanks to everyone who responded.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Michel Dänzer wrote:
> On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
>
>>On Tue, 16 Jul 2002, Keith Whitwell wrote:
>>
>>
>>>>Well, it's not high on my list. I don't think flat-shading is used that
>>>>often, and the changes d
Slava Polyakov wrote:
> On July 16, 2002 06:19 pm, you wrote:
>
>>Slava Polyakov wrote:
>>
>>>On July 16, 2002 04:15 pm, you wrote:
>>>
Every so often (for example after 1hr of gameplay) a glx program like
RTCW or WINE running SOF2 freezes... now, Only the program however, X is
fine.
Slava Polyakov wrote:
> On July 16, 2002 04:15 pm, you wrote:
>
>>Every so often (for example after 1hr of gameplay) a glx program like RTCW
>>or WINE running SOF2 freezes... now, Only the program however, X is fine.
>>However it freezes my mouse and kdb... if I telnet in and kill the
>>offending
Can someone out there check this quickly?
In radeon.h in the 2d driver, the size of the radeon mmio area is defined as
0x8 - however, on my r200 at least, /proc/pci shows the area as being
1/8th that size:
Bus 1, device 0, function 0:
... (omitted) ...
Non-prefetchable 32 bit
> Well, it's not high on my list. I don't think flat-shading is used that
> often, and the changes don't have any effect on smooth shading. Actually,
> it _eliminates_ some saves/restores necessary for unfilled polygons with
> hardware flat-shading.
>
> Actually, I think the problem is larg
Marc Poulhiès wrote:
> I have been playing tribes2 without a problem exept that the sound gets
> more and more noise with higher resolution... 800x600 is fine, 1024x768
> sounds creepy and 1280x1024 is just horrible. I have this probleme
> specialy in tribes2 menu. I read in the README.r200 in the
I've merged the trunk into the r200 branch. It seems to work fine, but I've
changed test machines so I can't compare performance -- so yell if there's a
big change.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heav
Mike Mestnik wrote:
> I patched my devfs patch so it can be used with the r200 branch. This was needed
>b/c my original
> patch depended upon the shared structure introduced for BSD. BTW dose the R200 work
>on BSD?
>
I've got the bsd changes merged in my local cvs. I need to build a test bo
José Fonseca wrote:
> On Thu, Jul 04, 2002 at 06:49:32PM +0100, José Fonseca wrote:
>
>>On Thu, Jul 04, 2002 at 12:58:13PM -0500, David Willmore wrote:
>>
>>>I had a lockup on an older version of the mach64 DRI driver, so
>>>I thought I'd retest with a newer one. gltestperf locks up (no
>>>respo
>>Next, tuxracer ran, but the menus were basically unusable. Sounds like
>>he hit a whack of software fallbacks - frame rate on menus must have
>>been less than 1fps. He didn't have the patience to get into the game.
>>
>
> this happens to me as well, but only if i restart the system after
> ins
Michel Dänzer wrote:
> On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote:
>
>>>Looks good, but I think I've got an even better patch:
>>>
>>>http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff
>>>
>>>I've moved the initializatio
1101 - 1200 of 1643 matches
Mail list logo
