Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Mike Mestnik 

--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > The 3D driver already handles several cliprects for when a window is
> > > partially obscured, SHAPE windows, ... That would just need to be
> > > extended to multiplex the cliprects on boundaries of multiples of
> 2048.
> > > 
> > I don't think we should even need togo as far as making these
> cliprects
> > 'extended to multiplex' or in any other way make them special.  It
> would
> > merley be a scratch pad for us to keep track of where the vewport
> starts
> > and ends.  Is it sane for us to y2k the cliprects?  What about
> > datanormilisation and inconsistancys.  I.E. what do we do with a
> cliprect
> > that crosses the line?
> 
> Multiplex it, i.e. split it into two, one for each 2048 area.
> 
I mean what about in places where this should have allready been done,
deep inside the driver.  Do we just exept incorrect rendoring?

> > It may be slightly more overhead but I don't see why we shoulden't
> just
> > calculate where the line is when we need to?
> 
> Doesn't work:
> 
>   * In particular if the window is larger than 2048.
Right, a simple 'if x1 - x2 > 2048' should do the tric?

>   * The 3D engine imposes alignment requirements on the target
> buffer (1024 bytes or even a multiple thereof IIRC), you can't
> move it on a pixel basis.
> 
That's great,  '{ xi[1] = x1 + 2048 - (round down to nerest alignment
requirement); }'  The new cliprect becomes xi[1] to x2, and the old gets
trimed too x1 to xi[1].  Adding xi[]'s as needed, for grater then 4096.

The question is do we put these xi's in temporary space or not.  If not do
we just express them as fullfleged cliprects?  It seams to be the easy
way, but memory hungry.

I don't see the relation from these cliprects to the viewport, exept that
there objects on the same 2d grid.  I think that currently we have
cliprects crossing the line, all of them is just not getting rendered too
cause of where the viewport is.

So what I realy need to know is how do I move the viewport?  I don't see
how splitting up the cliprects will do that for me.




__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Thread Local Storage libGL

2004-05-23 Thread Mike Mestnik 

--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Assembly dispatch stubs are only generated for x86 and SPARC.  It looks 
> like the #if test in dispatch.c is wrong, so that stubs don't even get 
> used on SPARC.  In any case, Jakub's patch did modify the x86 assembly, 
> not the C version.  I wasn't really clear about that before.  My 
> proposal is to modify the C version, the x86 assembly version, and the 
> SPARC assembly version.  I've worked up a patch to gl_x86_asm.py that I 
> can post on Monday.
> 
Just to get every one on the same page.  The SPARC assembly version is
only for solaris.  It dose not, and can not, even build on linux!  Last
time I checked DRI would not build on SPARC/Linux, crashing on the Solaris
ASM code.





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Michel Dänzer 
On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > The 3D driver already handles several cliprects for when a window is
> > partially obscured, SHAPE windows, ... That would just need to be
> > extended to multiplex the cliprects on boundaries of multiples of 2048.
> > 
> I don't think we should even need togo as far as making these cliprects
> 'extended to multiplex' or in any other way make them special.  It would
> merley be a scratch pad for us to keep track of where the vewport starts
> and ends.  Is it sane for us to y2k the cliprects?  What about
> datanormilisation and inconsistancys.  I.E. what do we do with a cliprect
> that crosses the line?

Multiplex it, i.e. split it into two, one for each 2048 area.

> It may be slightly more overhead but I don't see why we shoulden't just
> calculate where the line is when we need to?

Doesn't work:

  * In particular if the window is larger than 2048.
  * The 3D engine imposes alignment requirements on the target
buffer (1024 bytes or even a multiple thereof IIRC), you can't
move it on a pixel basis.


-- 
Earthling Michel DÃnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Thread Local Storage libGL

2004-05-23 Thread Ian Romanick 
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need 
for the specialized _ts_* versions of the dispatch functions.  It 
basically converts the DISPATCH macro (as used in 
src/mesa/main/dispatch.c) from:

#define DISPATCH(FUNC, ARGS, MESSAGE) \
(_glapi_Dispatch->FUNC) ARGS
to:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
const struct _glapi_table * d = _glapi_Dispatch;\
if ( __builtin_expect( d == NULL, 0 ) )\
d = get_dispatch();\
(d->FUNC) ARGS
There is some extra cost in the non-threaded case, but it seems very 
minimal.  In the x86 assembly case, it's only a test and a conditional 
branch that is usually not taken.  Does this seem like a reasonable 
change to make across the board?
Hmm.  The _ts_* macros were introduced to eliminate exactly that sort of 
test - though we probably coded it up in a less optimal way than that.  
Are you saying that the dispatch tables would really become compiled 
'C'?  At the moment they are typically generated as assembly and use a 
jmp rather than calling a new function as in either of the examples above.
Assembly dispatch stubs are only generated for x86 and SPARC.  It looks 
like the #if test in dispatch.c is wrong, so that stubs don't even get 
used on SPARC.  In any case, Jakub's patch did modify the x86 assembly, 
not the C version.  I wasn't really clear about that before.  My 
proposal is to modify the C version, the x86 assembly version, and the 
SPARC assembly version.  I've worked up a patch to gl_x86_asm.py that I 
can post on Monday.

Some time in the next couple weeks I'm going to create PowerPC dispatch 
stubs.  The PPC ABI is a little odd, though, so it may not be trivial.

My feeling is that the non-threaded case should run as fast as possible, 
being the normal usage.  Maybe some timings would make things clearer.
Since the branch is going to be correctly predicted every time it's 
executed (in the non-threaded case), the performance hit should be on 
the order of a couple clock-cycles.  I should be able to get some 
timings on Monday or Tuesday.  I'll just do a loop of calling some GL 
function a million times or something.  Any idea which function would be 
likely to take the least time to execute?  I want to find the case where 
the dispatch functions have the most impact.


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM

2004-05-23 Thread Mike Mestnik 

--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
> > 
> >>There are two types of VTs - text and graphical. It is only practical
> to have a
> >>single graphical VT because of the complexity of state swapping a
> graphical VT
> >>at VT swap.
> > 
> > 
> > Could have fooled me. I can switch between multiple DRI using X
> servers
> > and text consoles and it works currently. So clearly it is *not* too
> > complex. If you have mode setting there is little else required since
> > you can simply declare it to be the job of the client switched onto,
> to
> > get its data back in order.
> 
> The trouble with that is that when a new client comes along and starts 
> twiddling some new state that nobody else touched, suddenly you have to
> update 
> all the old clients to get them to restore that state.
> 
A perfect example of this is the fglx driver :(  However These cards are
farely static, so it should be posible to clear out all the state that
could ever be set.  At least to find out what state fglx uses and clear
that, also gatos has some state too.

> Keith
> 





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Mike Mestnik 

--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Sun, 2004-05-23 at 11:32, Mike Mestnik wrote:
> > I think I finaly get it.  When we have a window grater then 2048, we
> need
> > to run a GL command move the cliprect and run it again?  The only way
> to
> > find out where we need is to SW render the cmd.  Won't this cut our
> > framerate in half?  Plus moving the cliprect for most of the drawing
> cmds,
> > what about non-drawing.
> > 
> > First thing I see is there is no check in the client driver for 2048. 
> > What about numbcliprects, can we treat one app like its 2?  we are
> still
> > doing every thing twice, but now we just have overhead on the system
> CPU.
> 
> The 3D driver already handles several cliprects for when a window is
> partially obscured, SHAPE windows, ... That would just need to be
> extended to multiplex the cliprects on boundaries of multiples of 2048.
> 
I don't think we should even need togo as far as making these cliprects
'extended to multiplex' or in any other way make them special.  It would
merley be a scratch pad for us to keep track of where the vewport starts
and ends.  Is it sane for us to y2k the cliprects?  What about
datanormilisation and inconsistancys.  I.E. what do we do with a cliprect
that crosses the line?

It may be slightly more overhead but I don't see why we shoulden't just
calculate where the line is when we need to?  Maby save the result in
another smaller format, X line has X position, this is one unsigned int vs
4.  The answer is farily static?

> 
> -- 
> Earthling Michel Dänzer  | Debian (powerpc), X and DRI
> developer
> Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer
> 





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Mike Mestnik 

--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> 
> --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > 
> > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > > 
> > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > > Thank you for your informative reply.
> > > > 
> > > > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > I have not this experiance.  The right(0) head is allways where
> > fullscreen
> > goes.  I'm using gmplayer-k7 from debian sid.  The pseudo-xinerama
> > workes
> > perfectly and it correctly filles this display.  Could it be that my
> > left(1) display is smaller and/or has a scrolling viewport?
> 
> I doubt it.  perhaps a gmplayer bug?  I have a dualhead mode with a
> different mode on each head (1280x1024 and 1024x768).  whichever head
> more of the output window is in gets FS which I switch to FS mode.
> 
I'l lookinto it.

> > > > This is what I think I was getting at.  Can I move the 3d
> > viewport
> > > > during
> > > > runtime?  Wait I think you covered this, It would be nice if it
> > would
> > > > move
> > > > like a normale viewport based on 3d client location as a first
> > step.
> > > 
> > > that's sort of how the fix to the 3d driver would work. However,
> > you
> > > would want it to cover the whole front buffer because you could
> > > theoretically render to any part of it.  why move it around when
> > you
> > > could just iterate across the whole desktop?
> > > 
> > It sounds to me like iterate would be another step, for both CPUs.  I
> > say
> > avoid it since it's easy todo so.
> 
> yes, it would be another step, but how else could you enable 3d across
> the entire desktop?  I suppose you could have each app contend for the
> 3d engine, and then move the 3d viewport to which ever app had access
> at the time.  however, I'm not sure the 3d engine could work that way.
> 
Using cliprects you can see where the viewport needs to be, we change it's
position on context switch for multiple apps.  If I'm not mistaken we
allready change alot of register values at that time, so a fue more
shoulden't be anything at all.  As for large er apps we will have to 
iterate, but I don't fully understand how this is going to work withought
considerable performance loss.

> > > > 
> > > > > Alex
> > > > > 
> > > > 
> > > > 
> > > >





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM

2004-05-23 Thread Keith Whitwell 
Alan Cox wrote:
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
There are two types of VTs - text and graphical. It is only practical to have a
single graphical VT because of the complexity of state swapping a graphical VT
at VT swap.

Could have fooled me. I can switch between multiple DRI using X servers
and text consoles and it works currently. So clearly it is *not* too
complex. If you have mode setting there is little else required since
you can simply declare it to be the job of the client switched onto, to
get its data back in order.
The trouble with that is that when a new client comes along and starts 
twiddling some new state that nobody else touched, suddenly you have to update 
all the old clients to get them to restore that state.

Keith

---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM

2004-05-23 Thread Alan Cox 
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
> There are two types of VTs - text and graphical. It is only practical to have a
> single graphical VT because of the complexity of state swapping a graphical VT
> at VT swap.

Could have fooled me. I can switch between multiple DRI using X servers
and text consoles and it works currently. So clearly it is *not* too
complex. If you have mode setting there is little else required since
you can simply declare it to be the job of the client switched onto, to
get its data back in order.

Alan



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [r200] sigfault in update_light (current DRI and Mesa CVS)

2004-05-23 Thread Dieter Nützel 
Am Mittwoch, 12. Mai 2004 23:09 schrieb Dieter Nützel:
> SunWave1 progs/demos# ./gears
> Mesa: software DXTn compression/decompression available
> Speicherschutzverletzung (core dumped)

More on this with latest CVS:

(gdb) r
Starting program: /opt/Mesa/progs/demos/gears
[New Thread 1079078016 (LWP 4667)]

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1079078016 (LWP 4667)]
0x40664a58 in _mesa_test_os_sse_exception_support ()
   from /usr/X11R6/lib/modules/dri/r200_dri.so
(gdb) c
Continuing.
Mesa: software DXTn compression/decompression available

Program received signal SIGSEGV, Segmentation fault.
0x40670b99 in update_light (ctx=0x805e208) at r200_state.c:1143
1143  for (p = 0 ; p < MAX_LIGHTS; p++) {
(gdb) list
1138
1139
1140
1141   if (ctx->Light.Enabled) {
1142  GLint p;
1143  for (p = 0 ; p < MAX_LIGHTS; p++) {
1144 if (ctx->Light.Light[p].Enabled) {
1145struct gl_light *l = &ctx->Light.Light[p];
1146GLfloat *fcmd = (GLfloat *)R200_DB_STATE( lit[p] );
1147
(gdb) print p
$1 = 0
(gdb) bt
#0  0x40670b99 in update_light (ctx=0x805e208) at r200_state.c:1143
#1  0x406730a6 in r200ValidateState (ctx=0x805e208) at r200_state.c:2201
#2  0x4066d94a in r200MakeCurrent (driContextPriv=0x81eb7c0,
driDrawPriv=0x81ec510, driReadPriv=0x81eb7c0) at r200_context.c:634
#3  0x4054c0c1 in DoBindContext (dpy=0x804c038, draw=10485761, read=10485761,
ctx=0x81eb7c0, modes=0x8055f48, psp=0x8056d68) at dri_util.c:486
#4  0x4054c14a in driBindContext3 (dpy=0x804c038, scrn=136230848,
draw=10485761, read=10485761, ctx=0x805817c) at dri_util.c:519
#5  0x401316f6 in BindContextWrapper (dpy=0x804c038, gc=0x81eb7d8,
draw=10485761, read=134590056) at glxext.c:1515
#6  0x4013194a in MakeContextCurrent (dpy=0x804c038, draw=10485761,
read=10485761, gc=0x8057c70) at glxext.c:1613
#7  0x40131c33 in glXMakeCurrent (dpy=0x81eb7c0, draw=136230872, gc=0x81eb7c0)
at glxext.c:1760
#8  0x4004b540 in __glutSetWindow () from /usr/lib/libglut.so.3
#9  0x40041707 in processEventsAndTimeouts () from /usr/lib/libglut.so.3
#10 0x4004279b in glutMainLoop () from /usr/lib/libglut.so.3
#11 0x0804a3aa in main ()
(gdb) info registers
eax0x81eb7c0136230848
ecx0x805ae68134590056
edx0x81eb7d8136230872
ebx0x805b550134591824
esp0xbfffe9c0   0xbfffe9c0
ebp0x805ae680x805ae68
esi0x805e208134603272
edi0x81eb7cf136230863
eip0x40670b99   0x40670b99
eflags 0x10202  66050
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51

-Dieter


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: drm 830 problem

2004-05-23 Thread Kristian Høgsberg 
Keith Whitwell wrote:
Andrà Ventura Lemos wrote:
Not at all...
This only happens with 2.6 kernels. Prior do the lockup, everything
works (I can see it through ssh), but the display gets blank, and never
comes back.
On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote:
Do you mind if I take this to dri-devel?
What happens prior to the lockup?  Does it only happen with 2.6 kernels?
Keith

Andre - Can you give any more information on what might be triggering 
the lockups?
I'm getting the same lockups, and I can consistently reproduce it with 
the simple GL program in this mail:

http://cairographics.org/pipermail/cairo/2004-April/001175.html
The example with the 1D texture runs fine, but the 2D example locks up 
my machine.

HTH,
Kristian
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Alex Deucher 

--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> 
> --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > 
> > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > Thank you for your informative reply.
> > > 
> > > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > The problem I have is that my settup is lopsided, one monitor
> has
> > > > > better
> > > > > modes than the other.  The *larger* monitor is on the right,
> thus
> > > > > making
> > > > > it the secondary for GL applications.
> > > > 
> > > > If you'd prefer it be on the left, you can always switch the
> > > > orientation of the crtcs.  in my set up, crtc2 is left of
> crtc1. 
> > > the
> > > > orientation of the crtcs doesn't really matter.
> > > > 
> > > xv then becomes a problem.  Right now I have it so (g)mplayer
> uses my
> > > primary head(0), there dose not appere to be a config option for
> what
> > > monitor is used when going FS.
> > 
> > The radeon overlay can be displayed on either head and the driver
> > provides a pseudo-xinerama extension.  if the video app is xinerama
> > aware it will do the right thing depending on which head the app is
> on.
> >  xine and tvtime work fine for me.  I can go full screen on either
> > head.  The only limitation is that there is only one overlay so you
> can
> > only use it on one head or the other.
> > 
> I have not this experiance.  The right(0) head is allways where
> fullscreen
> goes.  I'm using gmplayer-k7 from debian sid.  The pseudo-xinerama
> workes
> perfectly and it correctly filles this display.  Could it be that my
> left(1) display is smaller and/or has a scrolling viewport?

I doubt it.  perhaps a gmplayer bug?  I have a dualhead mode with a
different mode on each head (1280x1024 and 1024x768).  whichever head
more of the output window is in gets FS which I switch to FS mode.

> 
> > > 
> > > > > 
> > > > > Another fix would be to make the center be zero and every
> thing
> > > > > left(negitive singed) of that being larger(unsigned) then
> that on
> > > the
> > > > > right.  What is needed is to run full-screen apps (1600x1200)
> on
> > > the
> > > > > right
> > > > > side with (1400x1050) only partaly(1600 - 2047 + 1400 = 953
> > > unused
> > > > > columns) being used for hardware GL.  This solution althought
> > > more
> > > > > correct
> > > > > is more tedious.
> > > > 
> > > > This isn't really feasible from the 2d drivers perspective. 
> you
> > > could
> > > > move the start of the 3d viewport over so that its "0" would be
> on
> > > the
> > > > right half of the framebuffer.  
> > > > 
> > > This is what I think I was getting at.  Can I move the 3d
> viewport
> > > during
> > > runtime?  Wait I think you covered this, It would be nice if it
> would
> > > move
> > > like a normale viewport based on 3d client location as a first
> step.
> > 
> > that's sort of how the fix to the 3d driver would work. However,
> you
> > would want it to cover the whole front buffer because you could
> > theoretically render to any part of it.  why move it around when
> you
> > could just iterate across the whole desktop?
> > 
> It sounds to me like iterate would be another step, for both CPUs.  I
> say
> avoid it since it's easy todo so.

yes, it would be another step, but how else could you enable 3d across
the entire desktop?  I suppose you could have each app contend for the
3d engine, and then move the 3d viewport to which ever app had access
at the time.  however, I'm not sure the 3d engine could work that way.

> 
> > > 
> > > > > 
> > > > > Is any one interested in seeing this goin?
> > > > 
> > > > If you are going to go through that effort, you might as well
> just
> > > > solve the problem for real and have the 3d driver just iterate
> over
> > > > each block of 2048x2048.  see the dri-devel archives: "2048
> limit
> > > code"
> > > > 
> > > This then would be step 2?
> > > 
> > > My only other question is where would this code live, hopefully
> not
> > > the 2d
> > > X driver?
> > 
> > You wouldn't need a step one.  It would all be handled in the 3d
> > driver.  The limitation is in the clipping registers.
> > 
> > http://marc.theaimsgroup.com/?l=dri-devel&m=106727717303407&w=2
> > 
> Thank you for the pointer.
> 
> > > 
> > > > Alex
> > > > 
> > > 
> > > 
> > >




__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [patch] Re: Some questions regarding locks

2004-05-23 Thread Michel Dänzer 
On Sun, 2004-05-23 at 12:05, Nicolai Haehnle wrote:
> 
> > This sounds like an idea for you to play with, but I'm afraid it won't
> > be useful very often in my experience:
> > 
> >   * getting rid of the offending client doesn't help with a wedged
> > chip (some way to recover from that would be nice...)
> >   * it doesn't help if the X server itself spins with the lock held
> 
> You were right, of course, while I show my lack of experience with driver 
> writing. In my case I can get the X server's reset code to run, but some 
> way through the reset the machine finally locks up completely (no more 
> networking, no more disk I/O).
> 
> I'm curious though, how can a complete lockup like this be caused by the 
> graphics card? My guess would be that it grabs the PCI/AGP bus forever for 
> some reason (the dark side of bus mastering, so to speak). Is there 
> anything else that could be the cause?

I don't really know, but I also guess it's PCI/AGP related.


> 2. The timeout cannot be configured yet. I didn't find "prior art" as to how 
> something like it should be configured, so I'm open for input. For a Linux 
> driver, adding to the /proc entries seems to be the logical way to go, but 
> the DRI is very ioctl-centric. Maybe both?

What's the goal of making it configurable at all, to allow for driver
debugging? Maybe that could be dealt with better, see below.

> 3. Privileged processes may take the hardware lock for an infinite amount of 
> time. This is necessary because the X server holds the lock when VT is 
> switched away. 
> Currently, "privileged" means capable(CAP_SYS_ADMIN). I would prefer if it 
> meant "the multiplexing controller process", i.e. the one that 
> authenticates other processes. Unfortunately, this distinction isn't made 
> anywhere in the DRM as far as I can see. 

Maybe one could recognize it by the DRM context handle, a bit hackish
though.

> This means that runaway DRI clients owned by root aren't killed by the 
> watchdog, either.

root is generally allowed to shoot itself in the foot, so this isn't all
that bad I guess.


> 4. Keith mentioned single-stepping through a driver, and he does have a 
> point. Unfortunately, I also believe that it's not that simple.
> Suppose an application developer debugs a windowed OpenGL application, on 
> the local machine, without a dual-head setup. It may sound like a naive 
> thing to do, but this actually works on Windows (yes, Windows is *a lot* 
> more stable than Linux/BSD in that respect).
> Now suppose she's got a bug in her application (e.g. bad vertex array) that 
> triggers a segmentation fault inside the GL driver, while the hardware lock 
> is held. GDB will catch that signal, so the process won't die, which in 
> turn means that the lock is not released. Thus the developer's machine 
> locks up unless the watchdog kicks in (of course, the watchdog in its 
> current form will also frustrate her to no end).

Is there a way to tell that a process is being debugged? If so, maybe it
could be handled sanely by default? E.g., release the lock while the
process is stopped? (That might wreak havoc once execution is resumed
though) ...


Another random thought I had was to introduce a Magic Sysrq key combo to
release the lock / kill the process holding it / whatever, but I guess
that wouldn't help Joe User with the casual hanging 3D client either.


-- 
Earthling Michel DÃnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Michel Dänzer 
On Sun, 2004-05-23 at 11:32, Mike Mestnik wrote:
> I think I finaly get it.  When we have a window grater then 2048, we need
> to run a GL command move the cliprect and run it again?  The only way to
> find out where we need is to SW render the cmd.  Won't this cut our
> framerate in half?  Plus moving the cliprect for most of the drawing cmds,
> what about non-drawing.
> 
> First thing I see is there is no check in the client driver for 2048. 
> What about numbcliprects, can we treat one app like its 2?  we are still
> doing every thing twice, but now we just have overhead on the system CPU.

The 3D driver already handles several cliprects for when a window is
partially obscured, SHAPE windows, ... That would just need to be
extended to multiplex the cliprects on boundaries of multiples of 2048.


-- 
Earthling Michel DÃnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer



---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

i830 texture compression support..

2004-05-23 Thread Dave Airlie 

The attached patch provides s3tc (and broken fxt) texture compression
support on the i8xx (x>30) chipsets,

You need to apply the radeon/r200 patch from Roland first, Roland do you
want to merge this patch into yours?

So far I've tested this with texcmp - thats how I know FXT doesn't work,
do we have support for FXT in Mesa?

do I have any chance of getting ut2004 demo going on an i865 chipset?
at the moment I'm missing some floors and things..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG persondiff -ur Mesa/src/mesa/drivers/dri/i830/i830_context.c 
new_mesa/Mesa/src/mesa/drivers/dri/i830/i830_context.c
--- Mesa/src/mesa/drivers/dri/i830/i830_context.c   2004-05-14 04:24:20.0 
+1000
+++ new_mesa/Mesa/src/mesa/drivers/dri/i830/i830_context.c  2004-05-24 
20:59:51.743669808 +1000
@@ -290,6 +290,10 @@
 12,
 GL_FALSE );
 
+   /* adjust max texture size a bit. Hack, but I really want to use larger textures
+  which will work just fine in 99.99% of all cases, especially with texture 
compression... */
+   if (ctx->Const.MaxTextureLevels < 12) ctx->Const.MaxTextureLevels += 1;
+   
ctx->Const.MaxTextureMaxAnisotropy = 2.0;
 
ctx->Const.MinLineWidth = 1.0;
@@ -371,6 +375,16 @@
_math_matrix_ctr (&imesa->ViewportMatrix);
 
driInitExtensions( ctx, card_extensions, GL_TRUE );
+   if (imesa->glCtx->Mesa_DXTn) {
+ _mesa_enable_extension( ctx, "GL_EXT_texture_compression_s3tc" );
+ /* Don't advertise FXT1 - doesn't work yet - airlied */
+ /* _mesa_enable_extension( ctx, "GL_3DFX_texture_compression_FXT1" );*/
+ _mesa_enable_extension( ctx, "GL_S3_s3tc" );
+   }
+   else if (driQueryOptionb (&imesa->optionCache, "force_s3tc_enable")) {
+ _mesa_enable_extension( ctx, "GL_EXT_texture_compression_s3tc" );
+   }
+
/* XXX these should really go right after _mesa_init_driver_functions() */
i830DDInitStateFuncs( ctx );
i830InitTriFuncs (ctx);
diff -ur Mesa/src/mesa/drivers/dri/i830/i830_screen.c 
new_mesa/Mesa/src/mesa/drivers/dri/i830/i830_screen.c
--- Mesa/src/mesa/drivers/dri/i830/i830_screen.c2004-05-09 14:38:42.0 
+1000
+++ new_mesa/Mesa/src/mesa/drivers/dri/i830/i830_screen.c   2004-05-24 
13:07:10.0 +1000
@@ -58,9 +58,10 @@
 DRI_CONF_BEGIN
 DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_MAX_TEXTURE_UNITS(4,2,4)
+   DRI_CONF_FORCE_S3TC_ENABLE(false)
 DRI_CONF_SECTION_END
 DRI_CONF_END;
-const GLuint __driNConfigOptions = 1;
+const GLuint __driNConfigOptions = 2;
 
 #ifdef USE_NEW_INTERFACE
 static PFNGLXCREATECONTEXTMODES create_context_modes = NULL;
diff -ur Mesa/src/mesa/drivers/dri/i830/i830_tex.c 
new_mesa/Mesa/src/mesa/drivers/dri/i830/i830_tex.c
--- Mesa/src/mesa/drivers/dri/i830/i830_tex.c   2004-04-08 18:54:24.0 +1000
+++ new_mesa/Mesa/src/mesa/drivers/dri/i830/i830_tex.c  2004-05-24 20:53:19.376318712 
+1000
@@ -418,6 +418,101 @@
 }
 
 
+
+static void i830CompressedTexImage2D( GLcontext *ctx, GLenum target, GLint level,
+  GLint internalFormat,
+  GLint width, GLint height, GLint border,
+  GLsizei imageSize, const GLvoid *data,
+  struct gl_texture_object *texObj,
+  struct gl_texture_image *texImage )
+{
+   driTextureObject * t = (driTextureObject *) texObj->DriverData;
+   GLuint face;
+
+   /* which cube face or ordinary 2D image */
+   switch (target) {
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_X:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_X:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y:
+   case GL_TEXTURE_CUBE_MAP_POSITIVE_Z:
+   case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z:
+  face = (GLuint) target - (GLuint) GL_TEXTURE_CUBE_MAP_POSITIVE_X;
+  ASSERT(face < 6);
+  break;
+   default:
+  face = 0;
+   }
+
+   if ( t != NULL ) {
+  driSwapOutTextureObject( t );
+   }
+   else {
+  t = (driTextureObject *) i830AllocTexObj( texObj );
+  if (!t) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, "glCompressedTexImage2D");
+ return;
+  }
+   }
+
+   texImage->IsClientData = GL_FALSE;
+   
+   if (I830_DEBUG & DEBUG_TEXTURE)
+ fprintf(stderr, "%s: Using normal storage\n", __FUNCTION__);
+   
+   _mesa_store_compressed_teximage2d(ctx, target, level, internalFormat, width,
+height, border, imageSize, data, texObj, 
texImage);
+   
+   t->dirty_images[face] |= (1 << level);
+}
+
+
+static void i830CompressedTexSubImage2D( GLcontext *ctx, GLenum target, GLint level,
+ GLint xoffset, GLint yoffset,
+ GLsizei width, GLsizei height,
+ GLenum format,
+ GLsizei imageSize, const GLvoi

Re: Thread Local Storage libGL

2004-05-23 Thread Keith Whitwell 
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need 
for the specialized _ts_* versions of the dispatch functions.  It 
basically converts the DISPATCH macro (as used in 
src/mesa/main/dispatch.c) from:

#define DISPATCH(FUNC, ARGS, MESSAGE) \
(_glapi_Dispatch->FUNC) ARGS
to:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
const struct _glapi_table * d = _glapi_Dispatch;\
if ( __builtin_expect( d == NULL, 0 ) )\
d = get_dispatch();\
(d->FUNC) ARGS
There is some extra cost in the non-threaded case, but it seems very 
minimal.  In the x86 assembly case, it's only a test and a conditional 
branch that is usually not taken.  Does this seem like a reasonable 
change to make across the board?
Hmm.  The _ts_* macros were introduced to eliminate exactly that sort of test 
- though we probably coded it up in a less optimal way than that.  Are you 
saying that the dispatch tables would really become compiled 'C'?  At the 
moment they are typically generated as assembly and use a jmp rather than 
calling a new function as in either of the examples above.

My feeling is that the non-threaded case should run as fast as possible, being 
the normal usage.  Maybe some timings would make things clearer.

Keith

---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[patch] Re: Some questions regarding locks

2004-05-23 Thread Nicolai Haehnle 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Saturday 22 May 2004 16:04, Michel DÃnzer wrote:
> On Sat, 2004-05-22 at 14:04, Nicolai Haehnle wrote:
> > It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking 
> > whether the caller actually holds the global lock. There is no 
> > LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer 
has 
> > no check in it either.
> > Did I miss something, or is this intended behaviour? It certainly seems 
> > strange to me.
> 
> True. Note that the lock ioctls are only used on contention, but still.

Unless I'm mistaken, DRM(lock) is always called when a client wants the lock 
for the first time (or when it needs to re-grab after it lost the lock). 
This is necessary because the DRM makes sure that dev->lock.filp matches 
the "calling" file. Afterwards, the ioctls are only used on contention.
The entire locking can be subverted anyway, because part of the lock is in 
userspace. I believe the important thing is to make sure that the X server 
can force a return into a sane locking state.

> > Side question: Is killing the offending DRI client enough? When the 
process 
> > is killed, the /dev/drm fd is closed, which should automatically release 
> > the lock. On the other hand, I'm pretty sure that we can't just kill a 
> > process immediately (unfortunately, I'm not familiar with process 
handling 
> > in the kernel). What if, for some reason, the process is in a state 
where 
> > it can't be killed yet?
> 
> We're screwed? :)

Looks like it...

> This sounds like an idea for you to play with, but I'm afraid it won't
> be useful very often in my experience:
> 
>   * getting rid of the offending client doesn't help with a wedged
> chip (some way to recover from that would be nice...)
>   * it doesn't help if the X server itself spins with the lock held

You were right, of course, while I show my lack of experience with driver 
writing. In my case I can get the X server's reset code to run, but some 
way through the reset the machine finally locks up completely (no more 
networking, no more disk I/O).

I'm curious though, how can a complete lockup like this be caused by the 
graphics card? My guess would be that it grabs the PCI/AGP bus forever for 
some reason (the dark side of bus mastering, so to speak). Is there 
anything else that could be the cause?

> > Side question #2: Is it safe to release the DRM lock in the watchdog? 
There 
> > might be races where the offending DRI client is currently executing a 
DRM 
> > ioctl when the watchdog fires.
> 
> Not sure, but this might not be a problem when just killing the
> offending process?

You're right.
On the other hand, it might sometimes be useful to be a little bit nicer to 
the offending process (see point 4 below).

I had a go at implementing my watchdog idea for Linux, see the attached 
patch. It basically works, but I couldn't test it on a system where the DRI 
actually works without locking up... *sigh*

Now for some notes:
1. This only affects the DRM for Linux. I don't have an installation of BSD, 
and while I know a little bit about the Linux kernel, I don't know anything 
about the BSD kernel(s).

2. The timeout cannot be configured yet. I didn't find "prior art" as to how 
something like it should be configured, so I'm open for input. For a Linux 
driver, adding to the /proc entries seems to be the logical way to go, but 
the DRI is very ioctl-centric. Maybe both?

3. Privileged processes may take the hardware lock for an infinite amount of 
time. This is necessary because the X server holds the lock when VT is 
switched away. 
Currently, "privileged" means capable(CAP_SYS_ADMIN). I would prefer if it 
meant "the multiplexing controller process", i.e. the one that 
authenticates other processes. Unfortunately, this distinction isn't made 
anywhere in the DRM as far as I can see. This means that runaway DRI 
clients owned by root aren't killed by the watchdog, either.

4. Keith mentioned single-stepping through a driver, and he does have a 
point. Unfortunately, I also believe that it's not that simple.
Suppose an application developer debugs a windowed OpenGL application, on 
the local machine, without a dual-head setup. It may sound like a naive 
thing to do, but this actually works on Windows (yes, Windows is *a lot* 
more stable than Linux/BSD in that respect).
Now suppose she's got a bug in her application (e.g. bad vertex array) that 
triggers a segmentation fault inside the GL driver, while the hardware lock 
is held. GDB will catch that signal, so the process won't die, which in 
turn means that the lock is not released. Thus the developer's machine 
locks up unless the watchdog kicks in (of course, the watchdog in its 
current form will also frustrate her to no end).

cu,
Nicolai

> 
> -- 
> Earthling Michel DÃnzer  | Debian (powerpc), X and DRI developer
> Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer
-BEGIN

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Mike Mestnik 
I think I finaly get it.  When we have a window grater then 2048, we need
to run a GL command move the cliprect and run it again?  The only way to
find out where we need is to SW render the cmd.  Won't this cut our
framerate in half?  Plus moving the cliprect for most of the drawing cmds,
what about non-drawing.

First thing I see is there is no check in the client driver for 2048. 
What about numbcliprects, can we treat one app like its 2?  we are still
doing every thing twice, but now we just have overhead on the system CPU.





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Mike Mestnik 

--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> 
> --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > Thank you for your informative reply.
> > 
> > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > > 
> > > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > The problem I have is that my settup is lopsided, one monitor has
> > > > better
> > > > modes than the other.  The *larger* monitor is on the right, thus
> > > > making
> > > > it the secondary for GL applications.
> > > 
> > > If you'd prefer it be on the left, you can always switch the
> > > orientation of the crtcs.  in my set up, crtc2 is left of crtc1. 
> > the
> > > orientation of the crtcs doesn't really matter.
> > > 
> > xv then becomes a problem.  Right now I have it so (g)mplayer uses my
> > primary head(0), there dose not appere to be a config option for what
> > monitor is used when going FS.
> 
> The radeon overlay can be displayed on either head and the driver
> provides a pseudo-xinerama extension.  if the video app is xinerama
> aware it will do the right thing depending on which head the app is on.
>  xine and tvtime work fine for me.  I can go full screen on either
> head.  The only limitation is that there is only one overlay so you can
> only use it on one head or the other.
> 
I have not this experiance.  The right(0) head is allways where fullscreen
goes.  I'm using gmplayer-k7 from debian sid.  The pseudo-xinerama workes
perfectly and it correctly filles this display.  Could it be that my
left(1) display is smaller and/or has a scrolling viewport?

> > 
> > > > 
> > > > Another fix would be to make the center be zero and every thing
> > > > left(negitive singed) of that being larger(unsigned) then that on
> > the
> > > > right.  What is needed is to run full-screen apps (1600x1200) on
> > the
> > > > right
> > > > side with (1400x1050) only partaly(1600 - 2047 + 1400 = 953
> > unused
> > > > columns) being used for hardware GL.  This solution althought
> > more
> > > > correct
> > > > is more tedious.
> > > 
> > > This isn't really feasible from the 2d drivers perspective.  you
> > could
> > > move the start of the 3d viewport over so that its "0" would be on
> > the
> > > right half of the framebuffer.  
> > > 
> > This is what I think I was getting at.  Can I move the 3d viewport
> > during
> > runtime?  Wait I think you covered this, It would be nice if it would
> > move
> > like a normale viewport based on 3d client location as a first step.
> 
> that's sort of how the fix to the 3d driver would work. However, you
> would want it to cover the whole front buffer because you could
> theoretically render to any part of it.  why move it around when you
> could just iterate across the whole desktop?
> 
It sounds to me like iterate would be another step, for both CPUs.  I say
avoid it since it's easy todo so.

> > 
> > > > 
> > > > Is any one interested in seeing this goin?
> > > 
> > > If you are going to go through that effort, you might as well just
> > > solve the problem for real and have the 3d driver just iterate over
> > > each block of 2048x2048.  see the dri-devel archives: "2048 limit
> > code"
> > > 
> > This then would be step 2?
> > 
> > My only other question is where would this code live, hopefully not
> > the 2d
> > X driver?
> 
> You wouldn't need a step one.  It would all be handled in the 3d
> driver.  The limitation is in the clipping registers.
> 
> http://marc.theaimsgroup.com/?l=dri-devel&m=106727717303407&w=2
> 
Thank you for the pointer.

> > 
> > > Alex
> > > 
> > 
> > 
> >
> 
> 
>   
>   
> __
> Do you Yahoo!?
> Yahoo! Domains – Claim yours for only $14.70/year
> http://smallbusiness.promotions.yahoo.com/offer 





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Mike Mestnik 

--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
> 
> >Thank you for your informative reply.
> >
> >--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> >  
> >
> >>--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>I'm currently unable to define a clone mode where one screen is
> >>>smaller
> >>>then the other.  My thoughts are "1024x768_1024x768" == "1024x768" vs
> >>>"1024x768-1024x768".
> >>>  
> >>>
> >>You can, but you can't mix and match multi-sized clone modes with
> >>multi-sized dualhead modes.  I was thinking of doing something like:
> >>
> >>
> >What do you mean here?  multi-sized dualhead is not realy posible at
> all,
> >the viewports are merged, joined at the hip.
> >  
> >
> Multisized screen resolutions -are- possible, but my opinion is that 
> they're useless. Multisized viewports or framebuffers are not. (Maybe 
> this clarifies?)
> 
I'l have todo some reading.  Are you talking about rander, mode swiching? 
I'm talking about simultanious FB(s) on more than one monitor, as a static
mode(for argument).

> >It might be nice, if you had more then one pointer or something?
> >
> >  
> >
> >>option "metamodes" "1024x768-800x600-clone 1024x768-800x600-left"
> >>adding the orientation to the metamode and then removing the
> >>orientation option.  they problem is you then need to add checks to
> >>make sure you have enough framebuffer for all of the modes listed and
> >>you might end up with some huge or weirdly sized virtual desktops. 
> >>PLus it just adds to the confusion.  I also wanted to keep consistency
> >>with other mergedfb drivers.
> >>
> >>
> >>
> >I would find it vary distracting.  I'l referance x2x style east and
> west
> >ect.  If I needed west, but used east of north for that matter.  So to
> >switch I'd also need to swap VGA cables.
> >
> >  
> >
> How about something like (for mergedfb): 
> merged:0,1:2048x768,1024x768,1024x768?
> 
The original(abriged) Idea is fine, I was just pointing out that it didn't
realy fix my problem.  This new idea is just too diffrent from the old for
me to comment, as I don't see what problem it fixes.  However is you were
to add in -geometry style 2048x768,1024x768+0+0,1024x768+0+768 it might be
more usefull.

> 
> David Bronaugh





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Alex Deucher 

--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> Thank you for your informative reply.
> 
> --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> > 
> > --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > > I'm currently unable to define a clone mode where one screen is
> > > smaller
> > > then the other.  My thoughts are "1024x768_1024x768" ==
> "1024x768" vs
> > > "1024x768-1024x768".
> > 
> > You can, but you can't mix and match multi-sized clone modes with
> > multi-sized dualhead modes.  I was thinking of doing something
> like:
> What do you mean here?  multi-sized dualhead is not realy posible at
> all,
> the viewports are merged, joined at the hip.

what I mean is multi-head with 2 different modes. for instance a leftof
and a clone mode with 1024x768 on one head and 800x600 on the other. 
The hardware supports it, but you can't configure it at the moment.

> 
> It might be nice, if you had more then one pointer or something?
> 
> > option "metamodes" "1024x768-800x600-clone 1024x768-800x600-left"
> > adding the orientation to the metamode and then removing the
> > orientation option.  they problem is you then need to add checks to
> > make sure you have enough framebuffer for all of the modes listed
> and
> > you might end up with some huge or weirdly sized virtual desktops. 
> > PLus it just adds to the confusion.  I also wanted to keep
> consistency
> > with other mergedfb drivers.
> > 
> I would find it vary distracting.  I'l referance x2x style east and
> west
> ect.  If I needed west, but used east of north for that matter.  So
> to
> switch I'd also need to swap VGA cables.
> 

The real solution would be dynamic runtime re-configuration. maybe
something like Xv attributes, but for modes instead of the overlay.

> > > 
> > > The problem I have is that my settup is lopsided, one monitor has
> > > better
> > > modes than the other.  The *larger* monitor is on the right, thus
> > > making
> > > it the secondary for GL applications.
> > 
> > If you'd prefer it be on the left, you can always switch the
> > orientation of the crtcs.  in my set up, crtc2 is left of crtc1. 
> the
> > orientation of the crtcs doesn't really matter.
> > 
> xv then becomes a problem.  Right now I have it so (g)mplayer uses my
> primary head(0), there dose not appere to be a config option for what
> monitor is used when going FS.

The radeon overlay can be displayed on either head and the driver
provides a pseudo-xinerama extension.  if the video app is xinerama
aware it will do the right thing depending on which head the app is on.
 xine and tvtime work fine for me.  I can go full screen on either
head.  The only limitation is that there is only one overlay so you can
only use it on one head or the other.

> 
> > > 
> > > Another fix would be to make the center be zero and every thing
> > > left(negitive singed) of that being larger(unsigned) then that on
> the
> > > right.  What is needed is to run full-screen apps (1600x1200) on
> the
> > > right
> > > side with (1400x1050) only partaly(1600 - 2047 + 1400 = 953
> unused
> > > columns) being used for hardware GL.  This solution althought
> more
> > > correct
> > > is more tedious.
> > 
> > This isn't really feasible from the 2d drivers perspective.  you
> could
> > move the start of the 3d viewport over so that its "0" would be on
> the
> > right half of the framebuffer.  
> > 
> This is what I think I was getting at.  Can I move the 3d viewport
> during
> runtime?  Wait I think you covered this, It would be nice if it would
> move
> like a normale viewport based on 3d client location as a first step.

that's sort of how the fix to the 3d driver would work. However, you
would want it to cover the whole front buffer because you could
theoretically render to any part of it.  why move it around when you
could just iterate across the whole desktop?

> 
> > > 
> > > Is any one interested in seeing this goin?
> > 
> > If you are going to go through that effort, you might as well just
> > solve the problem for real and have the 3d driver just iterate over
> > each block of 2048x2048.  see the dri-devel archives: "2048 limit
> code"
> > 
> This then would be step 2?
> 
> My only other question is where would this code live, hopefully not
> the 2d
> X driver?

You wouldn't need a step one.  It would all be handled in the 3d
driver.  The limitation is in the clipping registers.

http://marc.theaimsgroup.com/?l=dri-devel&m=106727717303407&w=2

> 
> > Alex
> > 
> 
> 
>




__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel m

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread David Bronaugh 
Mike Mestnik wrote:
Thank you for your informative reply.
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
 

--- Mike Mestnik <[EMAIL PROTECTED]> wrote:
   

I'm currently unable to define a clone mode where one screen is
smaller
then the other.  My thoughts are "1024x768_1024x768" == "1024x768" vs
"1024x768-1024x768".
 

You can, but you can't mix and match multi-sized clone modes with
multi-sized dualhead modes.  I was thinking of doing something like:
   

What do you mean here?  multi-sized dualhead is not realy posible at all,
the viewports are merged, joined at the hip.
 

Multisized screen resolutions -are- possible, but my opinion is that 
they're useless. Multisized viewports or framebuffers are not. (Maybe 
this clarifies?)

It might be nice, if you had more then one pointer or something?
 

option "metamodes" "1024x768-800x600-clone 1024x768-800x600-left"
adding the orientation to the metamode and then removing the
orientation option.  they problem is you then need to add checks to
make sure you have enough framebuffer for all of the modes listed and
you might end up with some huge or weirdly sized virtual desktops. 
PLus it just adds to the confusion.  I also wanted to keep consistency
with other mergedfb drivers.

   

I would find it vary distracting.  I'l referance x2x style east and west
ect.  If I needed west, but used east of north for that matter.  So to
switch I'd also need to swap VGA cables.
 

How about something like (for mergedfb): 
merged:0,1:2048x768,1024x768,1024x768?

0 and 1 would be the heads. The first res would be the merged res, the 
second res would be the res for the 1st specified head, the third res 
would be the res for the 2nd specified head (not viewport size). Order 
would matter. This way you can specify left and right. It doesn't allow 
for top/down specification, but if you wanted to get fancy you could 
take on matrix-style notation, and use a semicolon instead of a comma if 
one's above another (not very hard to solve in terms of notation).

For clone mode, replace merged with 'clone'.
Don't feel stuck with this. Borrow ideas! :)
The problem I have is that my settup is lopsided, one monitor has
better
modes than the other.  The *larger* monitor is on the right, thus
making
it the secondary for GL applications.
 

If you'd prefer it be on the left, you can always switch the
orientation of the crtcs.  in my set up, crtc2 is left of crtc1.  the
orientation of the crtcs doesn't really matter.
   

xv then becomes a problem.  Right now I have it so (g)mplayer uses my
primary head(0), there dose not appere to be a config option for what
monitor is used when going FS.
 

It seems to me like there needs to be some kind of an abstraction 
between physical CRTCs and displays.

I don't know what it should be; just an observation.
David Bronaugh
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: MergedFrameBuffer: New meta-mode syntax needed.

2004-05-23 Thread Mike Mestnik 
Thank you for your informative reply.

--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> 
> --- Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > I'm currently unable to define a clone mode where one screen is
> > smaller
> > then the other.  My thoughts are "1024x768_1024x768" == "1024x768" vs
> > "1024x768-1024x768".
> 
> You can, but you can't mix and match multi-sized clone modes with
> multi-sized dualhead modes.  I was thinking of doing something like:
What do you mean here?  multi-sized dualhead is not realy posible at all,
the viewports are merged, joined at the hip.

It might be nice, if you had more then one pointer or something?

> option "metamodes" "1024x768-800x600-clone 1024x768-800x600-left"
> adding the orientation to the metamode and then removing the
> orientation option.  they problem is you then need to add checks to
> make sure you have enough framebuffer for all of the modes listed and
> you might end up with some huge or weirdly sized virtual desktops. 
> PLus it just adds to the confusion.  I also wanted to keep consistency
> with other mergedfb drivers.
> 
I would find it vary distracting.  I'l referance x2x style east and west
ect.  If I needed west, but used east of north for that matter.  So to
switch I'd also need to swap VGA cables.

> > 
> > The problem I have is that my settup is lopsided, one monitor has
> > better
> > modes than the other.  The *larger* monitor is on the right, thus
> > making
> > it the secondary for GL applications.
> 
> If you'd prefer it be on the left, you can always switch the
> orientation of the crtcs.  in my set up, crtc2 is left of crtc1.  the
> orientation of the crtcs doesn't really matter.
> 
xv then becomes a problem.  Right now I have it so (g)mplayer uses my
primary head(0), there dose not appere to be a config option for what
monitor is used when going FS.

> > 
> > Another fix would be to make the center be zero and every thing
> > left(negitive singed) of that being larger(unsigned) then that on the
> > right.  What is needed is to run full-screen apps (1600x1200) on the
> > right
> > side with (1400x1050) only partaly(1600 - 2047 + 1400 = 953 unused
> > columns) being used for hardware GL.  This solution althought more
> > correct
> > is more tedious.
> 
> This isn't really feasible from the 2d drivers perspective.  you could
> move the start of the 3d viewport over so that its "0" would be on the
> right half of the framebuffer.  
> 
This is what I think I was getting at.  Can I move the 3d viewport during
runtime?  Wait I think you covered this, It would be nice if it would move
like a normale viewport based on 3d client location as a first step.

> > 
> > Is any one interested in seeing this goin?
> 
> If you are going to go through that effort, you might as well just
> solve the problem for real and have the 3d driver just iterate over
> each block of 2048x2048.  see the dri-devel archives: "2048 limit code"
> 
This then would be step 2?

My only other question is where would this code live, hopefully not the 2d
X driver?

> Alex
> 





__
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel