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://freedesktop.org/bugzilla/show_bug.cgi?id=1504
Bug 1504 depends on bug 1508, which changed state.
Bug 1508 Summary: Various problems with
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://freedesktop.org/bugzilla/show_bug.cgi?id=1509
Bug 1509 depends on bug 1508, which changed state.
Bug 1508 Summary: Various problems with
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://freedesktop.org/bugzilla/show_bug.cgi?id=1508
[EMAIL PROTECTED] changed:
What|Removed |Added
from r200_texstate.c:1340
maybe needs to be done pairwise due to 2 parallel (physical) tex units ?
looks like that's not the case, if 8500/9100 owners don't
complain remove this...
Anyone want to bet this has something to do with the shock rifle..
probably not but the comment stood out
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On Fri, 01 Oct 2004 21:11:54 +0100, Keith Whitwell
> > <[EMAIL PROTECTED]> wrote:
> >
> >>Maybe there's a problem with terminology, but when we write to agp
> memory in
> >>the drivers, we are definitely using the GART.
> >
>
Jon Smirl wrote:
On Fri, 01 Oct 2004 21:11:54 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
Maybe there's a problem with terminology, but when we write to agp memory in
the drivers, we are definitely using the GART.
The GART is remapping your addresses, but it's still a normal system RAM access
Hi,
I'm getting spurious Xserver crashes with a fatal error in
WaitForSomething since two days ago (got two of them to be exact). My
report can be found in fd.o bugzilla #1505. Select returns with
errno==EINVAL. I added some debug output to the problematic function but
it didn't reveal any illegal
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://freedesktop.org/bugzilla/show_bug.cgi?id=1509
Summary: GL_ADD is broken
Product: Mesa
Version: CVS
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://freedesktop.org/bugzilla/show_bug.cgi?id=1511
Summary: Incorrectly reporst 8 texture units
Product: Mesa
On Fri, 01 Oct 2004 21:11:54 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> Maybe there's a problem with terminology, but when we write to agp memory in
> the drivers, we are definitely using the GART.
The GART is remapping your addresses, but it's still a normal system RAM access.
> Keith
>
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://freedesktop.org/bugzilla/show_bug.cgi?id=1508
[EMAIL PROTECTED] changed:
What|Removed |Added
On Friday 01 October 2004 04:03, Keith Whitwell wrote:
> John Lightsey wrote:
> > A while back I mentioned on dri-devel that Savage cards will segfault
> > RTCW while loading the Checkpoint demo.
> > ( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
> > Mesa/src/mesa/tnl/t_tertex.c
Jon Smirl wrote:
On Fri, 01 Oct 2004 18:54:50 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
Second the DRM code always treats the framebuffer as if it is in
IOMEM. But what about IGP type devices wher
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
> > <[EMAIL PROTECTED]> wrote:
> >
> >>>Second the DRM code always treats the framebuffer as if it is in
> >>>IOMEM. But what about IGP type devices where the framebuffer is in
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://freedesktop.org/bugzilla/show_bug.cgi?id=1504
[EMAIL PROTECTED] changed:
What|Removed |Added
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://freedesktop.org/bugzilla/show_bug.cgi?id=1509
[EMAIL PROTECTED] changed:
What|Removed |Added
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
> <[EMAIL PROTECTED]> wrote:
> > > This implies that DRM should be passing back two distinct handle
> > > types, one for normal and one for IOMEM, so that the user space app
> > > will use the correct ac
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://freedesktop.org/bugzilla/show_bug.cgi?id=1503
[EMAIL PROTECTED] changed:
What|Removed |Added
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://freedesktop.org/bugzilla/show_bug.cgi?id=1508
Bug 1508 depends on bug 1503, which changed state.
Bug 1503 Summary: Scale factor for GL_C
On Fri, 01 Oct 2004 18:54:50 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
> > <[EMAIL PROTECTED]> wrote:
> >
> >>>Second the DRM code always treats the framebuffer as if it is in
> >>>IOMEM. But what about IGP type device
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://freedesktop.org/bugzilla/show_bug.cgi?id=1508
[EMAIL PROTECTED] changed:
What|Removed |Added
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://freedesktop.org/bugzilla/show_bug.cgi?id=1508
Summary: Various problems with GL_COMBINE
Product: Mesa
Ver
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://freedesktop.org/bugzilla/show_bug.cgi?id=1503
[EMAIL PROTECTED] changed:
What|Removed |Added
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://freedesktop.org/bugzilla/show_bug.cgi?id=1508
[EMAIL PROTECTED] changed:
What|Removed |Added
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://freedesktop.org/bugzilla/show_bug.cgi?id=1504
[EMAIL PROTECTED] changed:
What|Removed |Added
On Fri, 01 Oct 2004 10:49:14 -0700, Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > Maybe we should fork linux-core into linux-core-2.4 and linux-core-2.6
> > before it drifts too far from being able to run on 2.4. I suspect
> > linux-core would compile on 2.4 right now with minor ch
I note that we (HP)
have just nuked our future IA64 workstations; and as we
shipped the largest volume of such machines (by far), constraints there
will be use of graphics cards on servers, rather than any volume...
- Jim
> I've seen stuff on the web that suggests
Jon Smirl wrote:
On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
Second the DRM code always treats the framebuffer as if it is in
IOMEM. But what about IGP type devices where the framebuffer is in
main memory? These only exist on the x86 so treating their framebuffer
a
Jon Smirl wrote:
I haven't moved anything out of shared, it's all paralleled in
shared-core. 90% of the changes are from DRM() macro removal. I did
eliminate one header file for each device since I kept deleting things
until they were empty.
2.4 is a bigger question to me. For example 2.6 is adding
Jon Smirl wrote:
On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
This implies that DRM should be passing back two distinct handle
types, one for normal and one for IOMEM, so that the user space app
will use the correct access function. This is also a pretty good
argume
On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> > Second the DRM code always treats the framebuffer as if it is in
> > IOMEM. But what about IGP type devices where the framebuffer is in
> > main memory? These only exist on the x86 so treating their framebuffer
> > as
On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> > This implies that DRM should be passing back two distinct handle
> > types, one for normal and one for IOMEM, so that the user space app
> > will use the correct access function. This is also a pretty good
> > argumen
Jon Smirl wrote:
I just spent sometime looking at about a thousand errors from sparse
in the DRM code.
There are two main problems, first DRM makes use of opaque handles
which are passed to user space. These handles can be to normal or
iomem memory. Since the handles are typeless this generates a l
Vladimir's glxtest code may be helpful in figuring out the missing
bits if anyone is so inclined...
Are you implying that this program will/could work with the fglrx driver?
glxtest itself should work with *any* driver that does direct rendering.
However, a suitable modification of instrumentation
I just spent sometime looking at about a thousand errors from sparse
in the DRM code.
There are two main problems, first DRM makes use of opaque handles
which are passed to user space. These handles can be to normal or
iomem memory. Since the handles are typeless this generates a lot of
sparse err
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> On Fri, 1 Oct 2004 08:52:58 -0700 (PDT), Mike Mestnik
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 30 Sep 2004 11:27:28 -0700, Ian Romanick <[EMAIL PROTECTED]>
> wrote:
> > > > Mike Mes
On Fri, 1 Oct 2004 08:52:58 -0700 (PDT), Mike Mestnik
<[EMAIL PROTECTED]> wrote:
>
>
>
> --- Alex Deucher <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 30 Sep 2004 11:27:28 -0700, Ian Romanick <[EMAIL PROTECTED]> wrote:
> > > Mike Mestnik wrote:
> > >
> > > > Here is a straigth diff, I didn't do a u
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> On Thu, 30 Sep 2004 11:27:28 -0700, Ian Romanick <[EMAIL PROTECTED]> wrote:
> > Mike Mestnik wrote:
> >
> > > Here is a straigth diff, I didn't do a udiff since I think we all
> know the
> > > glxinfo output fairly well. I did make one change s/, $/
On September 21, 2004 12:18 pm, "Dag Bakke" <[EMAIL PROTECTED]> wrote:
> and finally:
>
> 4. Is the 9250 supported by the current dri code?
Yes, I didn't have to play with the PCI IDs either. I just told xorg to use
the radeon driver.
--
Mark Lane, CET -- mailto:[EMAIL PROTECTED]
Sales Manager
On Fri, 01 Oct 2004 13:03:59 +0200, Philipp Klaus Krause <[EMAIL PROTECTED]> wrote:
> We could add some of the GLES extensions to Mesa anyway.
> It would be useful for development of GLES applications.
There's a library on sourceforge that will turn normal OpenGL into
OpenGL-ES for development pur
Oh, I should point out that TG does do both GLES consultancy and will
continue to push Mesa-solo where it makes sense to do so...
At some point I'd like to try writing integrating a GLES target into the
Mesa codebase. I don't know whether it would be possible or sensible to
try and have the c
John Lightsey wrote:
A while back I mentioned on dri-devel that Savage cards will segfault RTCW
while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j < count; j++) {
GLv
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://freedesktop.org/bugzilla/show_bug.cgi?id=1504
Summary: DOT3 bumpmapping horribly broken
Product: Mesa
Ver
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://freedesktop.org/bugzilla/show_bug.cgi?id=1503
[EMAIL PROTECTED] changed:
What|Removed |Added
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://freedesktop.org/bugzilla/show_bug.cgi?id=1503
Summary: Scale factor for GL_COMBINE is incorrectly handled
Product: M
45 matches
Mail list logo
