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:
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=1504
Summary: DOT3 bumpmapping horribly broken
Product: Mesa
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++) {
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
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
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 --
--- 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/, $//g and s/,
/\n
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 udiff since I think we
--- 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 Mestnik wrote:
Here
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
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
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
argument for
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 IOMEM
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
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
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
as
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
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 changes.
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=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=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
Summary: Various problems with GL_COMBINE
Product: Mesa
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 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 where the
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
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
--- 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 access function.
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
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
--- 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
main memory?
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 where
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 around
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 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=1511
Summary: Incorrectly reporst 8 texture units
Product: Mesa
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
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
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.
--- 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.
The GART is
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
41 matches
Mail list logo
