On Thu, 2004-09-23 at 10:13, Jacek Rosik wrote:
> Hi,
>
> Note, that what I'm writing is based on radeon driver. I haven't
> investigated other drivers much.
>
> W liście z czw, 23-09-2004, godz. 01:13, Amir Bukhari pisze:
> > Is the frontbuffer shared between all contexts, or for each Context t
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 WriteMonoDepthSpa
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 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
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 buffer
On Mon, 2004-09-20 at 19:47, Adam Jackson wrote:
> On Monday 20 September 2004 13:17, Amir Bukhari wrote:
> > On Mon, 2004-09-20 at 18:47, Ian Romanick wrote:
> > > I just want to clarify things. Do you want to write a new application
> > > that renders to off-screen or do you want to redirect the
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 Smir
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 thre
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 seem
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 t
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]
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 pixm
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 becau
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 freez
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
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 Mes
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
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
m
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 co
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 u
Eric Anholt wrote:
On Wed, 2004-09-22 at 13:21, Ian Romanick wrote:
Philipp Klaus Krause wrote:
_mesa_test_os_sse_exception, executed upon start of any OpenGL
application raises SIGFPE. Normally this is not a problem,
applications continue to execute normally.
However when using the jogl OpenGL Jav
>
> 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 ..
Hi,
Note, that what I'm writing is based on radeon driver. I haven't
investigated other drivers much.
W liÅcie 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
23 matches
Mail list logo
