Thanks for taking the time to respond to this. I am
starting to understand why so few people choose to
work on the OpenGL code. Much of what you need to
know is either undocumented or restricted by the
hardware vendors.
--- Denis Oliver Kropp [EMAIL PROTECTED] wrote:
When multitasking, how
On Thu, 2003-08-14 at 05:43, Jon Smirl wrote:
Hopefully these is the last versions. They implement:
Please CC me any further radeonfb patches, I have my own stuff
pending that I need to sync (and I sort of took over maintainership)
1) add every know PCI ID
2) access ROM directly instead of
--- Additional Comments From [EMAIL PROTECTED] 2003-14-08 06:00 ---
yes Hui with latest patch page flip works again.
And about texture problems , when i enable that GL_ARB_Multitexture extension
problem with Warcraft disappear. Actually what i mean when u start Warcraft on
first screen
On Mer, 2003-08-13 at 21:31, Nicholas Leippe wrote:
Hrm, thinking about the xv method mentioned earlier, could I run an
xserver on each card, and write a small app that combined xwd and
xsetroot (attached to both xservers) in a loop?
Could it be fast enough, not tear, etc?
People did Xshm
--- Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
This is a problem. We also parse it to find the DFP
EDID and/or flat panel informations, do that work
with the real ROM ? I don't know much about x86
BIOSes, but at least for the DFP EDID, I suppose
that one is read in RAM by the BIOS, not
I can check, but my Rage128s don't have this problem.
It's only my Radeon cards.
--- Ian Romanick [EMAIL PROTECTED] wrote:
I seem to recall some discussion about a similar
issue w/Rage128
hardware on the old xpert list. I don't remember
what the conclusion
was, but the answer might be the
--- Additional Comments From [EMAIL PROTECTED] 2003-14-08 10:54 ---
Hui, I like the current patch much better, it addresses most of the
compatibility issues indeed. The approach we've been discussing should also
allow old 3D drivers to work with the new DRM and 2D driver though. And I
On Thu, Aug 14, 2003 at 09:21:44AM -0500, Eli Carter wrote:
That ought to be balanced with don't screw up the revision history, people
use it. It's one thing to reformat code that is unreadable, for the most
part this code didn't come close to unreadable.
Devil's advocate:
Then perhaps the
Michel Dnzer wrote:
On Thu, 2003-08-07 at 21:57, Ian Romanick wrote:
Michel Dnzer wrote:
On Tue, 2003-08-05 at 18:52, Ian Romanick wrote:
Michel, does that INREG work for PCIGART as well?
No, good point, you need
INREG( RADEON_AIC_LO_ADDR ) + dri_priv-agpTexOffset
for that.
Okay, that would be
I'm running my own internal application (lots of texturing) and I'm
crashing out in the i810UploadTexImages, trying to upload a level 11
mipmap, but the i810tex.h has MAX_TEXLEVELS set to 10, so of course I'm
corrupting memory earlier when assigning the pointers in i810SetTexImages,
the i830
[This e-mail has been automatically generated.Please do not reply to this
email- if you want to comment on the bug, go to the URL shown below and enter
your comments there.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
http://bugs.xfree86.org/show_bug.cgi?id=566
--- Additional Comments From [EMAIL PROTECTED] 2003-06-08 10:14 ---
Please try a DRI CVS snapshot from http://dri.sourceforge.net/snapshots/ (you
need an r200 snapshot).
--
Configure bugmail:
I have verified that the missing ROM is definitely a
problem with RADEON_MPP_TB_CONFIG as referenced in the
posts. I'm still experimenting to find a reliable fix.
It seems that you can't read and set this register at
too high of speed.
Thanks for the pointer.
=
Jon Smirl
[EMAIL PROTECTED]
Quoting Jon Smirl ([EMAIL PROTECTED]):
Is there any kind of overview on how graphics contexts
are implemented? Here a few of the questions I'm
having...
When multitasking, how does the context get changed?
I don't know how that's handled by others,
but DirectFBGL applications have to Lock()
Hi,
browsing the DRI source, I stumbled upon this. I have absolutely no idea
what it does, but this just doesn't look right (drm_drv.h:317)
#ifdef __HAVE_COUNTER15
dev-types[14] = __HAVE_COUNTER14;
#endif
Looks like this should be 15, i.e.
#ifdef __HAVE_COUNTER15
Hello,
I'm trying to build from CVS but I'm seeing something unexpected. The build
is trying to link to X libraries outside of the DRI tree itself. In
host.def I altered the ProjectRoot variable as so:
/* Optionally turn this on to change the place where you install the build.
* Warning:
Can anyone do this test for me? just run the
/usr/X11R6/lib/xscreensaver/glplanet on an i830 or above chipset and tell
me if you can see through the earth, (i.e. it looks transparent)
Either let me know or add it to bug 555 ...
Dave.
--- Additional Comments From [EMAIL PROTECTED]
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-06-08 05:58 ---
Created an attachment (id=468)
-- (http://bugs.xfree86.org/attachment.cgi?id=468action=view)
Patch for the 2.6.0-test2 kernel which support ATI IGP 345M
Works fine on my
On Wed, 2003-08-06 at 12:58, Michel Dnzer wrote:
The patch was flawed (it would free map even if it was NULL), try this
one instead.
Still broken. :( The maplist entry needs to be unlinked before freeing
it.
If this still doesn't cut it, I hope you get the idea and fix it
properly. :)
--
On Wed, 2003-08-06 at 23:09, Nathan Gray wrote:
Felix Khling wrote:
On Tue, 05 Aug 2003 20:59:32 -0700
Nathan Gray [EMAIL PROTECTED] wrote:
Hello,
I'm trying to build from CVS but I'm seeing something unexpected. The
build
is trying to link to X libraries outside of the DRI
On Fri, 2003-08-08 at 22:40, Ian Romanick wrote:
Michel Dnzer wrote:
On Thu, 2003-08-07 at 21:57, Ian Romanick wrote:
Michel Dnzer wrote:
On Tue, 2003-08-05 at 18:52, Ian Romanick wrote:
Michel, does that INREG work for PCIGART as well?
No, good point, you need
INREG(
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-05-08 18:15 ---
Created an attachment (id=467)
-- (http://bugs.xfree86.org/attachment.cgi?id=467action=view)
radeon kernel dri module patch for 2.6.0test2
--
Configure bugmail:
Jacek Blizinski wrote:
Which package do I use for the new 855GM, or is it not yet supported? Thanks a
lot!
You *should* be able to use the i830 driver. AFAIK, the
i830M/i845G/i845GE/i855GM/i865G all use the same graphics core, so the
3D driver should just work.
On Tue, 2003-08-05 at 18:52, Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
Michel Dnzer wrote:
On Tue, 2003-07-29 at 22:41, Ian Romanick wrote:
1. I don't like the hard-coding of 2*1024*1024 as the size of the
indirect buffers. This was copied directly from the R200
On Wed, 2003-08-06 at 21:43, Denis Oliver Kropp wrote:
When DRI has the graphics card lock for more than 100 ms, DirectFB
uses software rendering even if hardware rendering was available.
I'm curious: How do you avoid conflicts between software rendering and
the hardware engine? Do you
On Thu, 2003-08-07 at 21:57, Ian Romanick wrote:
Michel Dnzer wrote:
On Tue, 2003-08-05 at 18:52, Ian Romanick wrote:
Michel, does that INREG work for PCIGART as well?
No, good point, you need
INREG( RADEON_AIC_LO_ADDR ) + dri_priv-agpTexOffset
for that.
Okay, that would
Ian Romanick wrote:
Ville Syrjälä wrote:
This patch implements these extensions:
GL_ARB_texture_env_combine
GL_EXT_texture_env_combine
GL_ARB_texture_env_crossbar
I was thinking about this earlier today, and I think I know how we can
improve performance...a lot. If my understanding of how
All of the Rage128 and Radeon IDs I am refering to in
my posts are already in http://pciids.sf.net. These
IDs are missing in various combinations from the linux
and xfree header files. I usually have to also update
the framebuffer drivers to handle the added IDs.
=
Jon Smirl
[EMAIL
On Wednesday 13 August 2003 01:10 pm, Ian Romanick wrote:
Nicholas Leippe wrote:
So, here's my odd question:
Is it possible to put the older (pci) card in the system w/the
radeon, have the radeon render to a texture, and have the older card
simply display the texture?
I don't think
On Wednesday 06 August 2003 18:58, Marcelo Tosatti wrote:
Hi Marcelo,
Does DRM 4.3 work with both XFree 4.2 and 4.3 ?
I dont so, right?
it will work for both.
ciao, Marc
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites
On Wed, 6 Aug 2003, Marc-Christian Petersen wrote:
On Wednesday 06 August 2003 16:51, Mikael Pettersson wrote:
Hi Mikael,
Is anyone planning to update the apparently obsolete(*)
DRM drivers currently in 2.4.22-pre/rc for 2.4.23?
I have a pending DRM 4.3 update for .23-pre1. Marcelo
[This e-mail has been automatically generated.Please do not reply to this
email- if you want to comment on the bug, go to the URL shown below and enter
your comments there.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
Michel Dnzer wrote:
On Mon, 2003-08-11 at 15:40, [EMAIL PROTECTED] wrote:
diff -urpN --exclude-from=/home/davej/.exclude bk-linus/drivers/char/drm/gamma_dma.c
linux-2.5/drivers/char/drm/gamma_dma.c
-- bk-linus/drivers/char/drm/gamma_dma.c2003-05-31 15:58:40.0 +0100
+++
Felix Kühling wrote:
On Tue, 05 Aug 2003 12:00:50 -0600
Keith Whitwell [EMAIL PROTECTED] wrote:
Ian Romanick wrote:
Ian Romanick wrote:
I'm also having second thoughts about allowing drivers to add function
calls to the GLX dispatch table. This is a global table that has no
way to identify the
Jon Smirl wrote:
When a context is created, r200CreateContext(),
r200InitTextureFuncs() is called which then calls
driInitTextureObjects(). This code places the default
textures onto the swap list.
Later the context is destroyed, r200DestroyContext().
rmesa-glCtx-Shared-RefCount is checked to be
okay ignore parts of that that cast stuff.. that was some tiredness
sneaking in.. hw_status_page is a void *... I know this now :-)
so just look at the module changes and tell me if they are okay for 2.6..
Dave.
On Fri, 8 Aug 2003, Dave Airlie wrote:
Okay my first patch is up at
Michel Dnzer wrote:
On Tue, 2003-08-05 at 18:52, Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
Michel Dnzer wrote:
On Tue, 2003-07-29 at 22:41, Ian Romanick wrote:
1. I don't like the hard-coding of 2*1024*1024 as the size of the
indirect buffers. This was copied directly
On Mon, Aug 11, 2003 at 12:58:44PM -0400, Jeff Garzik wrote:
Larry McVoy wrote:
A few comments on why I don't like this patch:
1) It's a formatting only patch. That screws over people who are using
BK for debugging, now when I double click on these changes I'll get
to your
On Thu, 2003-08-07 at 12:09, Mike Mestnik wrote:
This is what I get on an strace of the now hung X server.
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
ioctl(6, 0x6444, 0) = -1 EBUSY (Device or resource busy)
ioctl(6,
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |dri-
||[EMAIL PROTECTED]
--- Additional
I am having trouble getting alsa to output clean audio, every thing I
have tried so far has resulted in very broken sound.
I have attached the latest attempt.
What I am trying to do (in write_alsa_output) is wait till the buffer is
empty, fill it, and keep doing this till there is no more data.
On Mon, 11 Aug 2003, Philip Brown wrote:
if (!pointer) {
return (whatever);
}
because it's consistent, and guaranteed safe from stupid parsing errors
^
return is /still/ not a function - so don't put in visual
Jeff Garzik wrote:
Also, having two styles
of 'if' formatting in your example just screams inconsistent to me :)
Naw, it's only one style:
stmt ::= if (expression) stmt
stmt ::= { newline stmts } newline
stmt ::= expression ; newline
etc.
Perfectly consistent. (Always end a statement with a
Larry McVoy wrote:
A few comments on why I don't like this patch:
1) It's a formatting only patch. That screws over people who are using
BK for debugging, now when I double click on these changes I'll get
to your cleanup patch, not the patch that was the last substantive
On Sun, 10 Aug 2003 13:04:49 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Forget the other patch, this one actually works. I tested it with a
modified radeon driver. They way I tried to access per-screen glx
extension data before didn't work. It used some X extension
http://bugs.xfree86.org/show_bug.cgi?id=314
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #416 is|0 |1
obsolete|
On Tue, 05 Aug 2003 09:52:25 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
Michel Dänzer wrote:
On Tue, 2003-07-29 at 22:41, Ian Romanick wrote:
1. I don't like the hard-coding of 2*1024*1024 as the size of the
indirect buffers. This was
On Fri, 2003-08-08 at 04:27, Mike Mestnik wrote:
http://bugs.xfree86.org/show_bug.cgi?id=271 ?
That seams like the one, I'm on an 8500 though.
So do you get the same (or at least similar) output in the server log?
Have you tried the counter measures discussed in the bug?
When I play
[This e-mail has been automatically generated.Please do not reply to this
email- if you want to comment on the bug, go to the URL shown below and enter
your comments there.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
Okay my first patch is up at
http://www.skynet.ie/~airlied/patches/dri/drm_i810_diff1.diff
This takes any obvious changes from the 2.4.20 kernel and 2.4.20-19.8 I
have on my PC, my only issue is whether this breaks in a 2.6 kernel (I
don't have 2.6 time on my hands yet :-)... is all the module
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |dri-
||[EMAIL PROTECTED]
--- Additional
Which package do I use for the new 855GM, or is it not yet supported? Thanks a
lot!
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and
Ian Romanick wrote:
Nathan Gray wrote:
Ok, I see. Thanks for the info. I've added this to the compilation
questions section of the FAQ on dri.sourceforge.net. The *best* place to
put this information would be in the comment above the ProjectRoot
#define, IMHO.
But that's a core
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-07-08 00:47 ---
The problem was from me adding in ALI AGP support on accident as well as the
ATI. But now I have a new problem, every time I try to start the X server with
DRI enabled(I've
Hello,
this is a follow-up of the thread per-screen client-side glx
extensions. In addition to those changes the attached patch also
removes __glXRegisterGLXFunction and __glXAddExtension. Therefore
__driRegisterExtensions is no longer necessary and corresponding
infrastructure was removed from
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #495 is|0 |1
obsolete||
--- Additional Comments From
On Wed, 2003-08-06 at 22:45, Jon Smirl wrote:
--- Denis Oliver Kropp [EMAIL PROTECTED] wrote:
When multitasking, how does the context get
changed?
I don't know how that's handled by others,
but DirectFBGL applications have to Lock() and
Unlock() the context.
Only one context can
I just commited a fix for the projective texturing fallback to the mga
driver.
While I was trying to figure out what was going on I had a look at
the r128 driver. But looking there didn't help as it seems to require the
same fix. Should I do this fix for all affected drivers or does someone
else
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-05-08 18:09 ---
yes, please post the 2.6.0-test2 patch, I'd love to get DRI working, :)
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
--- You are receiving
On Fri, 8 Aug 2003, Michel Dänzer wrote:
BTW, doesn't the solution for the incompatibility discussed in
http://www.geocrawler.com/mail/thread.php3?subject=%5BDri-devel%5D+i810+DRM+compatibility+fixlist=680
work after all?
i can adapt that patch and put it in the dri tree, I wasn't aware of
On Mon, 11 Aug 2003, Brian Paul wrote:
or b) up MAX_TEXLEVELS - but I assume this is hardware limitation, I'll
read my i810 data sheet.. but Keith do you remember?
The ctx-Const.MaxTextureLevels field should be set to the appropriate
value during context initialization in the driver.
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|dri-|[EMAIL PROTECTED]
|[EMAIL PROTECTED] |
--- Additional Comments
Werner Almesberger wrote:
stmt ::= if (expression) stmt
stmt ::= { newline stmts } newline
stmt ::= expression ; newline
etc.
Perfectly consistent. (Always end a statement with a newline.)
So you agree with Javascript that the semicolons aren't necessary :)
-- Jamie
Jon Smirl wrote:
Thanks for taking the time to respond to this. I am
starting to understand why so few people choose to
work on the OpenGL code. Much of what you need to
know is either undocumented or restricted by the
hardware vendors.
You probably want to read the glx specification, which you
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-09-08 17:09 ---
Hui, with the new patch for 2.6.75 (agpgart and drm) do you still have to use
the DRI module built from the XFree86 Source? I tried using the module from the
kernel and
Dave Airlie wrote:
I'm running my own internal application (lots of texturing) and I'm
crashing out in the i810UploadTexImages, trying to upload a level 11
mipmap, but the i810tex.h has MAX_TEXLEVELS set to 10, so of course I'm
corrupting memory earlier when assigning the pointers in
http://bugs.xfree86.org/show_bug.cgi?id=555
--- Additional Comments From [EMAIL PROTECTED] 2003-05-08 14:19 ---
Hm, better you ask this on the DRI-DEVEL list.
I'd need to dig out my i855 and I won't be able to do this anytime soon.
--
Configure bugmail:
Ville Syrjälä wrote:
I just commited a fix for the projective texturing fallback to the mga
driver.
While I was trying to figure out what was going on I had a look at
the r128 driver. But looking there didn't help as it seems to require the
same fix. Should I do this fix for all affected drivers
Ville Syrjälä wrote:
From mgastate.c:
\note the fully opaque pattern (0x) has been disabled in order
to work around a conformance issue.
Can anyone tell me what the issue actually is?
Conform does things like turn on stipple but set an all-ones pattern to ensure
that triangle rasterization
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|dri-|[EMAIL PROTECTED]
|[EMAIL PROTECTED] |
--- Additional Comments
No , rsync do not help, here.
Thanks,
Dieter
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual
On Wed, Aug 13, 2003 at 05:54:21AM -0600, Keith Whitwell wrote:
Ville Syrjälä wrote:
I just commited a fix for the projective texturing fallback to the mga
driver.
While I was trying to figure out what was going on I had a look at
the r128 driver. But looking there didn't help as it
What do you think about the attached patch?
I removed this, it just looks wrong and it conflicts
with Rage128
- /* Radeon M4 */
-#define PCI_DEVICE_ID_ATI_RADEON_LE0x4d45
-#define PCI_DEVICE_ID_ATI_RADEON_LF0x4d46
Radeonfb wasn't using them anyway.
Updated pci_ids.h to reflect all of
There was a discussion about posting multiple radeon cards on the devel
and xfree86 MLs just before 4.3.0 was released (feb 2003). Marc and
Hui and several others were involved. If you can find the thread, it
might help you out.
http://marc.theaimsgroup.com/?t=10430550602r=1w=2
trivial...
fixes some typos in the radeon driverdiff -ru HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c HEAD/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c
--- HEAD_ORIG/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c Wed Apr 30 03:50:52 2003
+++
I was looking at the code that sends image data (i.e., textures,
DrawPixels, etc.) to the server. I noticed something that looks like a
bug in SendLargeImage (lib/GL/glx/renderpix.c, line 57). In the 'else'
case, it just calls __glXSendLargeCommand to send properly formated data
to the
Felix Kühling wrote:
Forget the other patch, this one actually works. I tested it with a
modified radeon driver. They way I tried to access per-screen glx
extension data before didn't work. It used some X extension list to find
the screen data structure for a given display and screen number. But
Larry McVoy wrote:
On Mon, Aug 11, 2003 at 01:53:17PM -0400, Jeff Garzik wrote:
Larry McVoy wrote:
are function calls at a 10-nanosecond glance. Also, having two styles
of 'if' formatting in your example just screams inconsistent to me :)
It is inconsistent, on purpose. It's essentially like
Ville Syrjälä wrote:
On Wed, Aug 13, 2003 at 05:54:21AM -0600, Keith Whitwell wrote:
Ville Syrjälä wrote:
I just commited a fix for the projective texturing fallback to the mga
driver.
While I was trying to figure out what was going on I had a look at
the r128 driver. But looking there didn't
On Thu, Aug 14, 2003 at 06:23:12PM +0100, Keith Whitwell wrote:
Ville Syrjälä wrote:
The only issue I found with glean right now is that hw.blend_func isn't
properly initialized and if an app calls glBlendFunc( GL_ONE, GL_ZERO );
the actual function will be GL_ZERO,GL_ZERO. This caused the
diff -urpN --exclude-from=/home/davej/.exclude bk-linus/drivers/char/drm/gamma_dma.c
linux-2.5/drivers/char/drm/gamma_dma.c
--- bk-linus/drivers/char/drm/gamma_dma.c 2003-05-31 15:58:40.0 +0100
+++ linux-2.5/drivers/char/drm/gamma_dma.c 2003-05-29 14:07:46.0 +0100
@@
Nathan Gray wrote:
Ian Romanick wrote:
Nathan Gray wrote:
This is an example from an opengl tutorial that I'm trying out. If I run
it with LIBGL_ALWAYS_INDIRECT it works fine, but with direct rendering I
just
get a blank window. I'm using the radeon driver from recent CVS (checked
out yesterday
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |dri-
||[EMAIL PROTECTED]
--- Additional
I'd like to commit
http://penguinppc.org/~daenzer/DRI/radeon-resume-dri.diff to DRI CVS.
For a better idea of the cleanups I made in the DDX driver,
http://penguinppc.org/~daenzer/DRI/radeon-resume-cleanup.diff is a diff
against the XFree86 trunk. As you can see, there were already
http://bugs.xfree86.org/show_bug.cgi?id=131
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--
Configure
On Sun, Aug 10, 2003 at 01:52:47PM +, MichaelM wrote:
Here's the output:
radeon.o: unresolved symbol mmu_cr4_features
fixed in 2.4.22-rc1
-solca
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports,
[This e-mail has been automatically generated.Please do not reply to this
email- if you want to comment on the bug, go to the URL shown below and enter
your comments there.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
http://bugs.xfree86.org/show_bug.cgi?id=314
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #415 is|0 |1
obsolete|
On Mon, 11 Aug 2003 12:14:31 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
So I moved the glx extension data to the end of __DRIscreenRec and added
a pointer to __DRIscreenPrivateRec that points back to the
__DRIscreenRec. This pointer is then passed to
The patch was tested at that time and appeared to solve all the problems.
Unfortunately at that time the dri tree and XFree tree were pretty diverged and nobody
seemed interested enough to make sure the patch got in post-merge.
If you can get that patch applied to current sources that would be
--- Additional Comments From [EMAIL PROTECTED] 2003-11-08 15:21 ---
I don't see the problem with SW TCL either. Note that there's no codegen here...
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
I just commited NV_texture_rectangle support for mga.
I've tested with texrect + modified texwrap and everything seems to be in
order.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
---
This SF.Net email sponsored by: Free
Is there any kind of overview on how graphics contexts
are implemented? Here a few of the questions I'm
having...
When multitasking, how does the context get changed?
When multitasking, how long does it take to change
context?
Does graphics hardware have a single set of context
registers, or are
On Sat, Aug 09, 2003 at 12:54:46AM +0200, Ove Kaaven wrote:
| I'm interested in a practical solution. Do anyone plan to implement a
| library that will perform all the measurements you suggest (with the
| keep-the-cpu-busy addition needed for being useful in practice) and
| convert them to
This seems to work. Reading the register back slows
things down enough to make sure the ROM has time to
appear.
/* Fix from ATI for problem with Radeon hardware not
leaving ROM enabled */
unsigned int temp;
temp = INREG(RADEON_MPP_TB_CONFIG);
temp = 0x00ffu;
temp |= 0x04 24;
On Thu, 2003-08-07 at 13:29, Mathias Frhlich wrote:
I tried to get flightgear running on my radeon mobility M7. The standard XFree
drivers lock up. The current dri binary modules corrupt big parts of the
screen at startup. The lockup is gone!
The neat new observation is that if the
On Wed, 2003-08-06 at 17:16, Marc-Christian Petersen wrote:
On Wednesday 06 August 2003 16:51, Mikael Pettersson wrote:
Is anyone planning to update the apparently obsolete(*)
DRM drivers currently in 2.4.22-pre/rc for 2.4.23?
I have a pending DRM 4.3 update for .23-pre1. Marcelo did not
On Wed, Aug 13, 2003 at 12:22:06PM +0200, Michel D?nzer wrote:
- while ( GAMMA_READ(GAMMA_INFIFOSPACE) 2);
+ while ( GAMMA_READ(GAMMA_INFIFOSPACE) 2)
+ cpu_relax();
Are you actually using the gamma driver? :) Something like this might be
useful in other drivers as
Felix Kühling wrote:
So I moved the glx extension data to the end of __DRIscreenRec and added
a pointer to __DRIscreenPrivateRec that points back to the
__DRIscreenRec. This pointer is then passed to
__glXScrEnable/DisableExtension by the driver's createScreen function.
There may be binary
Quoting Jon Smirl ([EMAIL PROTECTED]):
--- Denis Oliver Kropp [EMAIL PROTECTED] wrote:
I don't know how that's handled by others,
but DirectFBGL applications have to Lock() and
Unlock() the context.
Only one context can be locked at the same time (in
each DirectFB session).
The Lock()
1 - 100 of 175 matches
Mail list logo
