On Wed, 19 Feb 2003, Brian Paul wrote:
> Felix Kühling wrote:
> > Hello list,
> >
> > D. Hageman and I have been bouncing a design document for the new
> > configuration infrastructure back and forth in private mail for the past
> > week. Now we think it's ready for public discussion.
> >
> > Yo
Felix Kühling wrote:
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth in private mail for the past
week. Now we think it's ready for public discussion.
You may notice that the structure is quite similar to Ians texmem
desig
On Wed, 19 Feb 2003, Ian Romanick wrote:
> Leif Delgass wrote:
> > Ian, this commit includes references to rmesa->hw.cube[], which isn't in
> > radeon_context.h yet. I don't see any reason not to commit the entire
> > cube map patch, but leave the extension disabled. I haven't had time to
> >
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported
I mean that they are not listed by GL_EXTENSIONS. This caused at
least on hic-up when trying
Brian Paul wrote:
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported I
mean that they are not listed by GL_EXTENSIONS. This caused at least
on hic-up when trying to test UT2k3 with 'LI
Leif Delgass wrote:
Ian, this commit includes references to rmesa->hw.cube[], which isn't in
radeon_context.h yet. I don't see any reason not to commit the entire
cube map patch, but leave the extension disabled. I haven't had time to
investigate the problems yet, but most of the code looks t
Ian, this commit includes references to rmesa->hw.cube[], which isn't in
radeon_context.h yet. I don't see any reason not to commit the entire
cube map patch, but leave the extension disabled. I haven't had time to
investigate the problems yet, but most of the code looks to be identical
to r2
Ian Romanick wrote:
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported I
mean that they are not listed by GL_EXTENSIONS. This caused at least on
hic-up when trying to test UT2k3 with 'LIBGL_ALWAYS_INDIRECT=
Another thing, if I install only the DRM module in the cvs tree the
textures don't seems to be corrupted and the problems in vendetta are
solved, but the system freeze up in 10-20 seconds. Only the reset button
can do something
Bye
---
This
An issue was recently found with some extensions that are part of the
OpenGL core that are not exported by the indirect path. By exported I
mean that they are not listed by GL_EXTENSIONS. This caused at least on
hic-up when trying to test UT2k3 with 'LIBGL_ALWAYS_INDIRECT=y'.
I realize that t
Ok, I have to correct myself , this drivers have many bugs, now all
the open GL utilities have textures corruptions . I think that this
drivers are very immature at this time, but seems to reach their goal.
Bye
---
This SF.net email is spon
--- Begin Message ---
On Die, 2003-02-18 at 22:37, Michael Mazack wrote:
> IIRC, your log file that you attached a few days ago
> said that the mga hal could not be found.
>
> Perhaps this has something to do with your problem?
I doubt it. All the OpenGL code is in mga_dri.so.
--
Earthling
Philip Brown wrote:
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the "lightweight"
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
"the lig
Philip Brown wrote:
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the "lightweight"
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
"the lig
On Die, 2003-02-18 at 22:37, Michael Mazack wrote:
> IIRC, your log file that you attached a few days ago
> said that the mga hal could not be found.
>
> Perhaps this has something to do with your problem?
I doubt it. All the OpenGL code is in mga_dri.so.
--
Earthling Michel Dänzer (MrCooper
On Tue, Feb 18, 2003 at 09:58:41PM -0500, Leif Delgass wrote:
> On Wed, 19 Feb 2003, [iso-8859-15] José Fonseca wrote:
> > It's now official: I'm coding on this. I'm adding the _ioctl suffix to
> > most IOCTLs (e.g., agp_alloc -> agp_alloc_ioctl) to leave to the
> > agp_alloc for internal DRM usage
I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
and the code, obviously... so I've seen references to the "lightweight"
lock. ButI have yet to figure out why there is one.
The url document mentions that one supposedly exists, and that
"the lightweight lock will no
dri-devel,
nwjbefeyfdl
[EMAIL PROTECTED]nwjbefeyfdldri-devel
+wzf¢+,¦ì¢·o$¥Év+HÀÞ½éh¥©Þv
騲×(Þ
éì÷×å{ç(uçÚ+Êj{¬x* yö¬µêÂü/¾¯htÌ-s ©òÞß@ÚÉ:âj\0ÂÉbrG×(
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth in private mail for the past
week. Now we think it's ready for public discussion.
You may notice that the structure is quite similar to Ians texmem
design. This is the first t
Sorry, sorry.. missed seeing the bounds check, even though its right there.
It's late where I am, and it's been a long day.
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor yo
Just a suggestion that comes to mind as I'm crawling through the
kernel-level code...
[the xfree 4.2.0 version]
but it looks to me like if userland passes in an incorrect context number
in a call to DRM_IOCTL_LOCK, it could cause a kernel panic, due to
no array bounds checking in
drm_drv.h, DRM
21 matches
Mail list logo
