If I get a chance this evening or over the weekend, I think we need to
split 2.4 and 2.6, they can pretty much share everything that isn't
drm_stub.h and drm_drv.h from what I can see... I think linknig over files
into a 2.4 build might help a lot... Jon most of the 2.6 specific stuff is
in these
Dave Airlie wrote:
If I get a chance this evening or over the weekend, I think we need to
split 2.4 and 2.6, they can pretty much share everything that isn't
drm_stub.h and drm_drv.h from what I can see... I think linknig over files
into a 2.4 build might help a lot... Jon most of the 2.6 specific
Hi,
Note, that what I'm writing is based on radeon driver. I haven't
investigated other drivers much.
W licie z czw, 23-09-2004, godz. 01:13, Amir Bukhari pisze:
Is the frontbuffer shared between all contexts, or for each Context there
will be a different frontbuffer?
Yes, frontbuffer is
Hmmm. This is interesting. If you back up to two days ago, does it
still happen? And after a clean rebuild of today?
I think I tracked it down, after 5 hours or so with Eric on IRC, of course
ten mins after Eric goes to bed I find it ... it seems to fix ipers and my
own application ..
At the time the code was written (fall 1999?) the only way Gareth found
that he could reliably determine that SSE was fully supported (by CPU
and kernel) was to try executing an SSE instruction and catching the
exception if it failed.
If there's a better way of doing that nowadays, we could
drm_sysfs.h and radeon_i2c.c are also 2.6 specific.
drm_stub.h works on 2.4 except for the register_chrdev/cdev stuff. I
would keep stub as is for 2.4 and just revert that part. The proposed
2.6 VGA sharing code will make 90% of drm_drv/drm_stub useless on 2.6
when it shows up.
Alternatively I
Philipp Klaus Krause wrote:
Does that mean that software Mesa doesn't use SSE?
The problem occurs only with the r200 driver, not with software
rendering.
Okay, then the SSE test can't be the problem. The exact same code gets
executed in both the R200 driver and software Mesa. Actually, do you
On Mer, 2004-09-22 at 22:14, Eric Anholt wrote:
2.2 kernels and kernels not properly configured for Pentium3 CPUs. So,
what's the right way on a 2.4 or a 2.6 kernel to determine if an app can
use SSE? What about BSD?
On FreeBSD we just use a convenient little sysctl to pull out
Ian Romanick schrieb:
Philipp Klaus Krause wrote:
Does that mean that software Mesa doesn't use SSE?
The problem occurs only with the r200 driver, not with software
rendering.
Okay, then the SSE test can't be the problem. The exact same code gets
executed in both the R200 driver and software
Alan Cox wrote:
On Mer, 2004-09-22 at 22:14, Eric Anholt wrote:
2.2 kernels and kernels not properly configured for Pentium3 CPUs. So,
what's the right way on a 2.4 or a 2.6 kernel to determine if an app can
use SSE? What about BSD?
On FreeBSD we just use a convenient little sysctl to pull out
On Sun, 19 Sep 2004 11:10:43 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote:
On Sun, 19 Sep 2004 10:59:25 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote:
I've finally done it :)
It was quite difficult , the rendering speed was too slow and I
couldn't reproduce the freeze with that
On Iau, 2004-09-23 at 17:22, Ian Romanick wrote:
The folks on #freedesktop suggested parsing cpuinfo, and I wrote some
simple code to do that. Are you saying that, if CPUID returns the SSE
bit set and we're on a 2.4 or later kernel, we're good to go? That
would make me very happy because
now it is two days as I began study GLX, GLcore. to see how to redirect
indirect Software rendering at the end I find the following:
when GLX bind a window with context it assign the frontbuffer to the
window. this window will be rendered to it. As we redirect this window
with Composite its
I removed the 2.6 specific code that allowed the DRM major device
number to be shared. We can add it back later if needed.
I built and checked DRM on both 2.6 and 2.4. It builds and runs
without problem.
Now would probably be a good time to do the 2.6/2.4 split.
--
Jon Smirl
[EMAIL PROTECTED]
Alan Cox wrote:
Should do. There is a corner case of SMP with only one CPU having SSE
but thats already broken in Mesa and many other packages. The more
thorough case is you use /dev/cpu/%d/cpuid to check the CPUid on each
processor but I'm not sure thats neccessary in reality
I had that issue in
Of course my patch is a bit of overkill, we don't need to calculate dest
before calling EnsureCmdBufSpace, I'll fix it later unless Eric gets to it
first
Dave.
I think I tracked it down, after 5 hours or so with Eric on IRC, of course
ten mins after Eric goes to bed I find it ... it seems
On Iau, 2004-09-23 at 17:21, Philipp Klaus Krause wrote:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4D4E5A16
Function=(null)+0x4D4E5A16
Looks like a buffer overrun or memory corruption. Are you trying to
use mesa very
Ian, what's the status of the pbuffers/superbuffers work in mesa?
How's the new allocator coming along?
I've just about got DRM to the point where I can add mode setting to
it and integrate printk drawing. With that and superbuffers mesa solo
will have it's main features implemented.
--
Jon
Hi,
apparently I'm the first to use a full software fallback for glClear(), as I
ran into a few problems that the attached patch should fix:
- spantmp.h doesn't check for NULL masks
- add a WriteMonoDepthSpan function to the swrast to driver interface
- use this function to clear the depth
On Thu, 2004-09-23 at 18:15, Nicolai Haehnle wrote:
One thing I noticed in the process: r200Flush() unconditionally calls
r200EmitState(). Is this really necessary? I was assuming that glFlush()
could be a noop when it's not preceded by any rendering commands.
While I suspect this would be
Same thing as for r200, but for r100. Effects are even better,
according to ipers. Anyone want to do some testing before I commit?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
Index: radeon_compat.c
On Fri, 24 Sep 2004 03:15:01 +0200, Nicolai Haehnle [EMAIL PROTECTED] wrote:
Hi,
apparently I'm the first to use a full software fallback for glClear(), as I
ran into a few problems that the attached patch should fix:
- spantmp.h doesn't check for NULL masks
- add a WriteMonoDepthSpan
22 matches
Mail list logo
