Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Philip Brown]

On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote:
> Another possible solution to the boot time problem would be to write a
> disposable device driver. The disposable driver would set the mode/EDID and run
> the console until user mode started; then self destruct. 

that doesnt sound very appealing.



---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Philip Brown]

On Mon, Oct 27, 2003 at 06:13:32PM -0800, Linus Torvalds wrote:
>..
> So the thing should really just have 
>  - discovery and attach/detach
>  - interrupt event notification (and it can't just be "an interrupt 
>happened" - the interrupt driver actually has to know enough to ACK the
>interrupt, so that we can tell user space that an interrupt happened 
>without having to disable the interrupt until the event goes away)
>  - serialization (ie a lock) and waiting for events ("engine idle" or 
>"command queue less than half full")
>  - DMA arbitration and setup.
>[]
> So the low-level driver wouldn't know about palettes or cursors or any 
> "high-level" concepts like that. It would have a few locks to make sure 
> that the users that try to access the things don't stop on each other, 
> nothing more (maybe the locks themselves would be grouped into "palette 
> lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded 
> enough to allow it, but the point is that the low-level driver wouldn't 
> actually _do_ anything, it only allows others to do what they want without 
> stomping on each others toes).

Sounds like a good idea. Simple Is Better.

Now, would that "DMA arbitration" include
"submit a chunk o dma memory for GPU processing",

or would it just allow [whatever] to map the registers, and basically say,
"I'll tell you when something completes (aka sends an interrupt)
 but it's up to you to START it"





---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] dri-solo?

[Philip Brown]

I saw a few references to "dri-solo" on the mesa list, but didnt get to 
read much on what it actually is.
What is it supposed to be?
I grepped through some of the recent dri-devel IRC logs, but didnt see
anything there either.



---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport

[Philip Brown]

On Mon, Aug 11, 2003 at 10:59:41AM -0700, Larry McVoy wrote:
>...
> It is inconsistent, on purpose.  It's essentially like perl's
> 
>   return unless pointer;
> 
> which is a oneliner, almost like an assert().

perl is EEevil



> Maybe this will help: I insist on braces on anything with indentation so
> that I can scan them more quickly.  If I gave you a choice between
> 
>   if (!pointer) {
>   return (whatever);
>   }
> 
>   if (!pointer) return (whatever);
> 
> which one will you type more often?


 if (!pointer) {
return (whatever);
 }


because it's consistent, and guaranteed safe from stupid parsing errors
that can waste days of debug time when someone decides to add to it.
("its just a little change that cant hurt anything", ha ha)


Style Matters.  (and so do comments, while we're on the subject)


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport

[Philip Brown]

On Thu, Aug 14, 2003 at 07:47:11AM -0700, Larry McVoy wrote:
> ...
> Indeed I have.  And there is a reason that we have a policy at BitMover
> where "formatting changes" are prohibited and we make people redo their
> changesets until they get them right.
> 
> In other words, you are welcome to write a revision control system
> which can look through the formatting changes and give you the semantic
> knowledge that you want.  We'd love to see how it is done and then do
> it in BitKeeper :)


You should allow for changes that are "formatting change only", with no
actual code structural change.
You could pass the results through stage 1 of gcc, and only allow it if the
parsing tree is identical.

I was originally going to suggest just passing it through "indent", but
that would not come out right, if someone added braces to clarify a
one-line conditional.


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Sorting PCI Radeons out from AGP Radeons

[Philip Brown]

On Tue, Jul 29, 2003 at 09:44:48PM +0200, Michel Dänzer wrote:
> The DDX driver needs to know to decide whether to enable the DRI with
> PCI GART or disable it, but the kernel might be in a better position to
> find out (though some XFree86 hackers might disagree :)...

well, seeing as how using AGP requires a specialized driver anyway, I dont
see the problem :-}


in an ideal world, there would be
/dev/agpgart0
/dev/agpgart1
/dev/agpgartn

and there would be an ioctl to return a card ID similar to the ID system
that XFree uses, of X:X:X
(I forget exactly what that is, though;   bus:slot:function ?)


Then you'll know, even in a multicard situation, which card(s) have an agp
bus available, and which do not.




---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration per application

[Philip Brown]

On Tue, Jun 24, 2003 at 10:01:47PM +1000, Damien Miller wrote:
> Felix Kühling wrote:
> > Hi,
> > 
> > I have some questions about OS specific ways to find out the name of a
> > running programme outside function main. 
> 
> extern chat *__progname;
> 
> works on OpenBSD, NetBSD and Linux.

it definately does NOT work on Solaris.

$ gcc -o t test.c
Undefined   first referenced
 symbol in file
__progname  /var/tmp//ccMPu79K.o




---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

[Philip Brown]

On Mon, Jun 02, 2003 at 09:14:23AM -0600, Jens Owen wrote:
> > Modified files:
> >   xc/xc/lib/GL/mesa/src/drv/r200/:
> > Imakefile.inc 
> >   
> >   Revision  ChangesPath
> >   1.5   +1 -1  xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc
> 
> After doing a little digging in the DRI and XFree86 CVS trees, it looks 
> like this was originally fixed 6 months ago in the XFree86 repository 
> and then synced 5 months ago into the mesa-4-0-4-branch of the DRI 
> repository, but it never made it to the DRI trunk.
> 
> Ugh.

ObPedantic:

A reminder that you wouldnt have these problems, if dri was an actual true
module for xfree86.
Then "merging"/"syncing" to the xfree tree would never need to be done,
and you wouldnt hit this sort of bug re-introduction problem.


---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Re: [Dri-devel] Mesa tree re-org

[Philip Brown]

On Mon, Jun 02, 2003 at 05:29:54PM -0600, Brian Paul wrote:
> Keith Whitwell wrote:
>...
> > One thing that is a bit confusing is that some drivers are just drivers, 
> > wheras others are combinations of drivers and window system interfaces.  
> > It would be nice to have just drivers here and move the various window 
> > system binding codes to another directory.
> > 
> > This way you'd get to see a lot of similarity between the 
> > framebuffer-type drivers and it might be possible to abstract them down 
> > to not much, using either templates from common/ or a new module like 
> > the one Phil proposed.
> > 
> > So, anyway, the new proposal would be something like
> > 
> > libGL/
> > X11  - standalone X11 libGL
> 
> In the cases where the API and driver are tightly integrated (X11 
> Mesa, OSMesa, DOS, Windows, etc.) I'd rather just keep things 
> basically as-is (in the driver directory).

But they dont _have_ to be tightly integrated.
I've already proved that OSMesa can be abstracted onto a more generic
interface. My current working tree, now has osmesa.c down to 396 lines,
with the bulk of the code now in the "generic" side. The original
osmesa.c is 2180 lines. 

I hope to soon prove that GLX can work well on top of a "generic" layer,
too.  The DOS and Windows cases are SIMPLER than the GLX case, so if GLX
works well, those will also.

I dont remember the specifics, unfortunately, but I noticed a certain
amount of bit-rot in the Windows-specific mesa driver (maybe it was the
SVGA driver)
If it was using a common generic mesa API, it would not have had the same
problem.

Migrating some of the various subtrees to use a common mesa pseudo-hardware
interface, would actually reduce long-term maintainance.


---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: sched_yield()

[Philip Brown]

On Thu, May 29, 2003 at 10:52:15PM -0700, Linus Torvalds wrote:
> 
> On Thu, 29 May 2003, Ian Romanick wrote:
> > 
> > You're right.  We do _really_ want to use futex'es.  However, I don't 
> > think they're available on *BSD or Solaris.
> 
> ...
> And once you have a nice wrapper and they look like spinlocks, *BSD and 
> Solaris must have _some_ equivalent. If worst comes to worst, you do a 
> "loop with atomic accesses and yield()" thing as a fallback.

Dunno anything about "futex'es". But Solaris does not seem to have an
equivalent of any of 
atomic_inc(), atomic_dec(), atomic_read()
FYI.

It has the old standards of mutexes, and semaphores.
Oh, and condition variables.  [ cv_wait, cv_signal ]




---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: SPAM : DRI Devel ratio

[Philip Brown]

On Tue, May 27, 2003 at 09:38:31PM -0700, Russ Dill wrote:
> I was being sarcastic, his message was encoded with koi8-r, which, along
> with being html, is one of the indescriminate reasons people block email
> (and get a good number of false positives)

however, foreign language encoding is separate from html email.

blocking based on foreign language encodings is not such a good idea.
blocking html is not so bad, though.



---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Mesa3d-dev] Re: [Dri-devel] Re: [forum] Notes from a teleconference held 2003-3-27

[Philip Brown]

On Fri, Apr 04, 2003 at 10:34:05PM +0100, Keith Whitwell wrote:
> >[Philip Brown writes]
> > So to truely create something akin to nvidia's UDA libs/interface, would
> > involve porting support for 3d hardware currently handled by DRI, over to
> > Mesa, and making mesa capable of using it directly, without X.
> 
> Kindof like the embedded branch, then.

Yeup.  But with full hardware suport, rather than the "limited" 
support that I believe the embedded branch has now.

Then those people who dream of having an X server built on top of
a pure 3d foundation, finally have something to swing at, too ;-)




---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [forum] Notes from a teleconference held 2003-3-27

[Philip Brown]

On Fri, Apr 04, 2003 at 10:09:00PM +0100, Keith Whitwell wrote:
> Philip Brown wrote:
> > Are you perhaps envisioning pushing Mesa to evolve into something
> > like the nvidia  UDA  API? Where there is suddenly a single, unified
> > cross-hardware/OS platform for all 3d-accel hardware access to program to?
> > 
> > 
> > I think that could potentially be a very interesting idea. But it would
> > probably double the Mesa codebase size, most likely, and so should be
> > managed VERY carefully. Certainly doable, but it should be
> > Done Right(tm).
> 
> That's not a stated plan, afaik, but nobody would want to rule out such an idea.
> 
> And, actually it wouldn't increase the code size of Mesa at all, as Mesa 
> already runs on many different platforms & is basically os-neutral.  The 
> os-dependant parts tend to be the window system bindings and of course the 
> kernel components of the actual drivers.

That last bit is sort of what I'm referring to.
Mesa currently supports only a subset of video cards currently suported by
DRI.  DRI only works in conjunction with an X server, as far
as I know, because it is dependant on the GLX api, and cant function
through OpenGL alone.

So to truely create something akin to nvidia's UDA libs/interface, would
involve porting support for 3d hardware currently handled by DRI, over to
Mesa, and making mesa capable of using it directly, without X.

Then the dri source tree would become considerably emptier :->



---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [forum] Notes from a teleconference held 2003-3-27

[Philip Brown]

On Fri, Apr 04, 2003 at 08:43:31AM -0700, Jens Owen wrote:
> Possible
> Future:  Mesa Tree -+--> XFree86 Tree
>   - API Focus|- X/3D Integration
>   - 3D HW Focus  |- Complete Window System Focus
>  |
>  +--> Alternate X Tree
>  |- Duplicate X/3D Integration
>  |- Possibly more 3D developer
>  |  friendly, who knows?
>  |
>  +--> FBDev Subset
>  |- FBDev/3D Integration
>  |- Embedded Focus
>  |
>  +--> DirectFB
>  |- DFB/3D Integration
>  V
>   Other Window Systems:
>   DirectFB, WGL, AGL and
>   new ones that haven't
>   been invented, yet.
> 

Are you perhaps envisioning pushing Mesa to evolve into something
like the nvidia  UDA  API? Where there is suddenly a single, unified
cross-hardware/OS platform for all 3d-accel hardware access to program to?


I think that could potentially be a very interesting idea. But it would
probably double the Mesa codebase size, most likely, and so should be
managed VERY carefully. Certainly doable, but it should be
Done Right(tm).

For example, having fully documented APIs written BEFORE doing any code
modifications.

Then having the APIs blessed by different people from at least 3
separate operating systems.

(no, "suse", "redhat", and 'debian" do not count as 3 separate operating
 systems ;-)



---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] correction to utah-glx comparison

[Philip Brown]

Sorry about the lag of this, but I never like to give out false
information. So this is a correction to some things I said about utah-glx
in the weekly dri-devel irc conference two weeks ago:

utah-glx can handle multiple GLX contexts just fine. There is no extra
code needed to be written for that
The historical issue was that it could only handle one "direct" context
at any one time.

(Why is this on the dri list? So that when comparisons between dri and
 utah-glx come up, they can be accurate comparisons)




---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] UT2k3 playability status?

[Philip Brown]

On Sun, Mar 30, 2003 at 02:27:46PM +0100, Ian Molton wrote:
> Theres *TONS* of other hardware [than video cards] that has open source
> drivers that *totally* rock.

and the other hardware is a lot simpler to interface to.

Kinda like the difference between writing a image display program, and
writing a word processor, you might say.




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Wed, Mar 26, 2003 at 12:22:48PM -0800, Ian Romanick wrote:
> ...  The memory management code that is in the 3D driver (for doing 
> the allocations and communicating with the DRM) really has to be there. 
>   Moving it into the X server would really hurt performance.  There's 
> really only four possible solutions:
> 
>   1. Have the X server call the code in the 3D driver.
>   2. Have the 3D driver call the code in the X server.
>   3. Have the code exist in both places.
>   4. Leave things as they are.
> 
> I'm saying the #2 is unacceptable for performance reasons.  You're 
> saying that #1 unacceptable for software engineering reasons.  We're 
> both saying that #3 is unacceptable for software engineering reasons. 
> Users are saying #4 is unacceptable for performance reasons.  Where does 
> that leave us?
> 
> To be perfectly honest, I would much rather pick #3 over #2 or #4.

Likewise. However, I think that your evaluation of #2 is premature.
There are a few different ways to accomplish that, and I dont think you're
seeing all the possibilities clearly.


> If the paged memory system is only used when DRI is enabled, does it 
> really matter where the code the X server calls is located?  Could we 
> make the memory manager some sort of API-registered callback?  It would 
> be one that only DRI (and perhaps video-capture extensions) would ever 
> use, but still.


Details of the API sound like some good fodder for a long irc discussion


> I really do want to find a compromise here.  I really want to help make 
> Linux / XFree86 a first-class platform for 3D.  Right now there are a 
> few infrastructure elements missing, and I believe that this is a 
> significant one.  There are two issues from the end-user perspective: 
> stability and performance.  Since this is a performance issue, I can't 
> in good conscience accept a solution that loses significant performance.

The users will always cry about performance more. But you have to always
consider stability FIRST. Performance can usually be incrementally improved.
Stability is not so easy.
Stability comes first and formost from clean design, which leads to
 better maintainability, and smaller scope of debugging (ie: modularity)




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Wed, Mar 26, 2003 at 11:18:18AM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> >  
> > 
> >  New client comes in. Requests new corse chunk o' VRAM from GLX
> >  Oops. we've used up the 16 megs pre-allocated.
> >  Used to be 11 megs free, but X server has been busy, and there is
> >  now "only" 8 megs free.
> >  GLX calls xf86AllocateOffscreenLinear() to grab another 4 megs of
> >  VRAM from the X server, then hands some part of it off to the new
> >  client
> 
> What happens when you have 15 processes running with GL contexts that 
> each need 24MB of texture memory per frame?  Nearly all of the 
> allocations in question are transient.  A texture only "needs" to be in 
> graphics memory while it's being used by the hardware.  If the texture 
> manager has to pull from a hodge podge of potentially discontiguous 
> blocks of memory (as in your example) there will be a lot of requests 
> for memory that we should be able to satisfy that will fail.  The result 
> is a fallback to the software rasterizer.


Ah, I see whats on your mind now  ...

> What needs to happen to make everyone "play nice" together is:
> 
>   Coarse grained, block oriented cache / paged memory system
> | |
> V |
>   Core X routines |
>   V
>3D driver texture allocator
> 
> In other words, what you've brought up here is a completely orthogonal 
> issue.

Orthogonal to the issue that is foremost on your mind,  of
 "how do you 'page out' textures from a GLX client, to give the active
  client more room",   yes.

[I'd be happy to discuss that actual issue in irc with you next time ;-)
 but I'll spare the list that one for now]

So since it is orthogonal, you should have no objections to lowest-level
allocation of video memory being done by GLX calling xf86Allocate routines, 
yes?
(ie: "leave the X core code alone")


I believe this whole thread started off by references to hacking X server
code to call DRI extension code. That is what I am arguing against, as
unneccessary. Extension code should call core code, not the other way
around  (except for API-registered callbacks, of course)




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Wed, Mar 26, 2003 at 09:14:37AM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > Consider the GLX_dri_reserve_mem as equivalent to sbrk()
> > Then have a more local memory allocator for subdividing the large chunk.
> > That's going to be a lot more efficient that relying on the XFree routines
> > to do fine-level memory management anyways. xfree's routines arent really
> > optimized for that sort of thing, I think.
> 
> Okay.  You're just not listening.  THAT WON'T ALLOW US TO IMPLEMENT A 
> FUNCTIONING 3D DRIVER.  Textures memory is like a cache that is shared 
> by multiple running processes.  We need to be able to do the equivalent 
> of paging out blocks from that cache when one process needs more memory. 
>   An OS needs something under sbrk in order to implement paged memory, 
> and so do we.

eh?


Card has 32 megs of VideoRAM.
Initialization phase:
 X grabs 4 megs for actual video display
 X grabs 1 meg(?) for pixmaps
 DRI/GLX starts, notices that there is 27 megs free.
 Decides to be nice, and only pre-alloc 16 megs.
 Parcels out that 16 megs to clients somehow.
   (clients will probably grab memory in 2-4meg chunks from GLX,
then use "local" memory manager on that)

 

 New client comes in. Requests new corse chunk o' VRAM from GLX
 Oops. we've used up the 16 megs pre-allocated.
 Used to be 11 megs free, but X server has been busy, and there is
 now "only" 8 megs free.
 GLX calls xf86AllocateOffscreenLinear() to grab another 4 megs of
 VRAM from the X server, then hands some part of it off to the new
 client




> ...  Instead, it will make a lot of work for DRI developers (every process 
> with a GL context will have to be notified when any context makes a 
> magic sbrk call).

No, you dont have to notify all GL clients. See above.

Ya know, I heard this guy "Keith Whitwell" wrote some nice mmXXX()
routines in 1999 that, coincidentally enough, handle *exactly* *this* *type*
*of* *situation* for a "local memory manager" for GLX clients.
Now, what are the odds of that? Maybe we could get that guy to help out
here somehow...

:-) :-) :-)



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > Well, okay, there needs to be a little extra handholding between server and
> > client. So, you add a GLX_dri_reserve_mem extension or something that
> > reserves video memory by proxy. Or do it in some more direct fashion,
> > bypassing GLX protocol overhead if you prefer, but still letting the GLX
> > module on the server reserve it cleanly through the server interfaces.
> > 
> > That's the clean way to do it, even if it requires more coding on the DRI
> > side.
> > 
> > For non-video (ie AGP) memory, the issue isnt relevant, since the client
> > can do the reservation through the drm kernel driver directly, I believe.
> 
> After reading this I honestly believe that you and I must be talking 
> about different things.  I'm talking about allocating a block of memory 
> to hold a texture that's going to be read directly by the rendering 
> hardware.  The texture should be kept in directly readable memory 
> (either on-card or AGP) unless the space is needed by some other operation.
> 
> Not only that, this is an operation that needs to be fast.  As fast as 
> possible, in fact.

Yes, I know that.
Sounds like we just didnt get down to discussing the details.

Consider the GLX_dri_reserve_mem as equivalent to sbrk()
Then have a more local memory allocator for subdividing the large chunk.
That's going to be a lot more efficient that relying on the XFree routines
to do fine-level memory management anyways. xfree's routines arent really
optimized for that sort of thing, I think.


> 
> Right now our memory manager is layered on top of the X memory manager. 
> [stuff on future texmem ]

Well, great. Sounds like we're actually talking about the same thing then.
It's just a matter of what granularity you call the X server for requesting
memory. 
Currently, I'm guessing its a matter of
  [pseudocode]
  size=FindAllFreeMem();
  xallocmem(size);

Wheres what would be nicer to the server, while still preserving local 
speed, would probably be to alloc X memory in 2 megabyte chunks, or
something like that, and then use the layered local memory manager for
those large chunk(s).

[some reasonable fraction of FindAllFreeMem(), not neccessarily strictly 2
 megabytes. ]



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Tue, Mar 25, 2003 at 11:21:22PM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote:
> >>The idea is that the X server and the 3D driver can use the same memory 
> >>manager for off-screen memory.  That way pixmap cache, textures, and 
> >>vertex buffers all get managed in the "same" way and share ALL of off 
> >>screen memory.
> > 
> > Yes, and existing core X server APIs allow that.
> 
> How can it do that with direct rendering?

Well, okay, there needs to be a little extra handholding between server and
client. So, you add a GLX_dri_reserve_mem extension or something that
reserves video memory by proxy. Or do it in some more direct fashion,
bypassing GLX protocol overhead if you prefer, but still letting the GLX
module on the server reserve it cleanly through the server interfaces.

That's the clean way to do it, even if it requires more coding on the DRI
side.

For non-video (ie AGP) memory, the issue isnt relevant, since the client
can do the reservation through the drm kernel driver directly, I believe.


>?  Even worse, if the 3D driver code "lives" in Mesa CVS and the 
> core server code lives in XFree86 CVS, we would have the same code 
> living in two different trees!

You only have duplicate code for this, if you code it "wrong" :->
Duplicate code is usually one of the basic signs of "the code needs a redesign"

Video mem is a core X server resource, and should be reserved through the
core server, always.

It would be different if there were no core api for allocationg video ram.
But there is. So use it.

[okay, the docs suck. but it's still there]



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > The core X server should not be making calls into extension modules.
> > Extension modules should be making calls to xfree-exported functions.
> > If there arent sufficient xfree-exported functions, extend or add new ones.
> 
> The idea is that the X server and the 3D driver can use the same memory 
> manager for off-screen memory.  That way pixmap cache, textures, and 
> vertex buffers all get managed in the "same" way and share ALL of off 
> screen memory.

Yes, and existing core X server APIs allow that.

>  Currently, when DRI is enables, the pixmap cache is 
> very, very small, even if there are no 3D clients running.

Then DRI isnt behaving nicely, and should be a better "neighbour".
And/or, the 2d layer should be more practical about its use of
xf86AllocateOffscreenLinear()




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Wed, Mar 26, 2003 at 12:37:08AM +, Alan Cox wrote:
> On Tue, 2003-03-25 at 23:15, Philip Brown wrote:
> > There are already AGP (and memory alloc) related calls in the X server
> > framework; xf86BindGARTMemory(), xf86EnableAGP(), etc.
> > 
> > The core X server should not be making calls into extension modules.
> > Extension modules should be making calls to xfree-exported functions.
> > If there arent sufficient xfree-exported functions, extend or add new ones.
> 
> The core doesn't have enough information to do all of this job. Video
> memory can be shared with other resources - not just X handled resources
> like Xv but DMA space for onchip mpeg2 decoders for example. (or audio
> even in one case)

If the core doesnt have enough information to do something, it probably
doesnt need information about it in the first place, and that information
should be kept in the extension module.

As far as video memory allocation, there are existing core routines that
handle that.
Utah-glx now uses the core routines to alloc video memory. 




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Tue, Mar 25, 2003 at 12:37:17PM -0800, Ian Romanick wrote:
> 
> This could also pave the way for the X server to use the new memory 
> manager that is being developed.  We could make some sort of a conduit 
> for the X server to call into the DRI driver to allocate graphics / AGP 
> memory.  There are other ways to achieve this, but this would be an easy 
> way.

Please do not do this. Choose the "clean" way, not the "easy" way.

There are already AGP (and memory alloc) related calls in the X server
framework; xf86BindGARTMemory(), xf86EnableAGP(), etc.

The core X server should not be making calls into extension modules.
Extension modules should be making calls to xfree-exported functions.
If there arent sufficient xfree-exported functions, extend or add new ones.



---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Server-side GLX / DRI issues

[Philip Brown]

On Tue, Mar 25, 2003 at 09:48:21PM +, Keith Whitwell wrote:
> 
> Utah did have some stuff going for it.  It was designed as a server-side-only 
> accelerated indirect renderer.  My "innovation" was to figure out that the 
> client could pretty easily play a few linker tricks & load that server module 
> with dlopen(), and then with minimal communication with the server, do 90% of 
> the direct rendering tasks itself.  (This was after my first encounter with 
> PI, I think, until then I hadn't heard of direct rendering).

Turns out that most of those dlopen hacks arent neccessary, if you use
libglx.so, instead of libglx.a, it seems. ld.so takes care of things
automatically, when the X server itself does dlopen() on the extension
module.
A "direct rendering" client will still need to do interesting things. But
for server-side rendering, the dlopen() stuff does not appear to be
neccessary. (At least against xfree4. Maybe it was neccessary with xfree3)

It also turns out that there was a lot of grungy scrninfoP->driverPrivate
dereferencing going on, that is also completely unneccessary. So the
current Utah-GLX X server interfacing code is a good deal cleaner than when
you last looked at it.  Many of the old dlopen tricks are still in place;
however, new code seems to be directly accessing the server functions with
no "tricks".




---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: XFree86 bugzilla available

[Philip Brown]

On Fri, Mar 21, 2003 at 10:28:03PM +0100, Michel Dänzer wrote:
> On Fre, 2003-03-21 at 22:24, Philip Brown wrote:
> > On Fri, Mar 21, 2003 at 09:45:40PM +0100, Michel Dänzer wrote:
> > > >Jose Fonseca writes
> > > > Also, what's the general mailing list one can subscribe to receive
> > > > notifications everytime a bug is open?
> > > 
> > > Currently [EMAIL PROTECTED] gets them all.
> > 
> > [EMAIL PROTECTED] gets notification when a bug is filed on sourceforge
> > against dri?
> 
> No, Jose said where those go to. [EMAIL PROTECTED] gets mail about
> XFree86 bugzilla bugs.

Strictly speaking, I believe he said "owner" of dri bugs. He didnt say
"place where all new bug notifications go for dri"

Not nice to mix metaphors, Jose :-/


---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: XFree86 bugzilla available

[Philip Brown]

On Fri, Mar 21, 2003 at 09:45:40PM +0100, Michel Dänzer wrote:
> >Jose Fonseca writes
> > Also, what's the general mailing list one can subscribe to receive
> > notifications everytime a bug is open?
> 
> Currently [EMAIL PROTECTED] gets them all.

[EMAIL PROTECTED] gets notification when a bug is filed on sourceforge
against dri?



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: XFree86 bugzilla available

[Philip Brown]

On Thu, Mar 20, 2003 at 10:47:01PM +0200, Smitty wrote:
> Hi Philip
> 
> Are you going to put your time where your mouth is? 
> 
> I'm sure that having someone who looks after the admin of the
> DRI project is a good idea.
> 
> If only for the reason as having someone to fiddle with the
> website, ie leaving the dri developers more time to code drivers.
> 
> Heck I might even be able to handle it if you're prepared to 
> help, seeing as how the website now seems to be under control.

Unfortunately, I have other sourceforge projects to look after, so adding
the dri area wouldnt fit in too well. Not to mention the issue that as I
said, I dont have a working DRI system :->

However, if someone were to step up and volunteer to manage the DRI bug
area, I would be happy to share any info I've picked up about the system.

As you imply, it might even be a benefit if that person were NOT one of the
main DRI developers. Leaves them more time to write code.




---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: [forum] Re: [XFree86] Invitation for public discussion about the future of X

[Philip Brown]

On Thu, Mar 20, 2003 at 04:08:06PM +, Keith Whitwell wrote:
>
>  From my selfish point of view, an XFree fork will put the DRI tree in a bit 
> of a difficult position - especially if the new fork gets significant distro 
> support and we have to somehow track both trees or go through yet another 
> merge step to get our code out to the world.

Perhaps then, this will provide enough incentive for DRI to move back into
a pure extension module form, rather than its current xfree tree
entanglement.

Then there is no longer an issue with xfree splits. Or at worst, only
minor issues.


---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] drmAddMap(xx,xx,xx,DRM_SHM) : "locked" ?

[Philip Brown]

On Thu, Mar 20, 2003 at 10:34:11AM +, José Fonseca wrote:
> On Wed, Mar 19, 2003 at 03:56:04PM -0800, Philip Brown wrote:
> > I'd rather hear first what it is "supposed" to mean in the current
> > implementations. The current docs say "locked in kernel memory".
> > As written, that statement does not make sense to me. So I am
> > GUESSING it really means "locked in physical memory". But I would like
> > clarification on what it is supposed to mean.
> 
> You said yourself that "locked in physical memory" and "kernel memory"
> are two different things. Don't know why you're trying to guess
> otherwise...

To be more accurate, I know what "locked in physical memory" means.
I dont know what is meant by "locked in kernel memory".

Not being a linux kernel developer, I was hoping that either the original
DRM coder, or a linux kernel developer, could explain what that phrase
means.


As I mentioned, under solaris at least, "physical memory" and
"kernel memory" are two different things. 
In a solaris context, "locked in kernel memory" makes no sense.
So I would like to see the current documentation clarified.



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Re: XFree86 bugzilla available

[Philip Brown]

On Thu, Mar 20, 2003 at 02:49:37PM +, Alan Cox wrote:
>...
> I guess they've been busy writing 3D drivers instead. If you know the
> SF system well then this kind of info could be a real help

I dont know it "well". I just poked around with it at admin-level for 10
minutes.

It would be a good thing if one or more of the current DRI sourceforge area
admins took a similar amount of time and invested it in the system.



---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Re: XFree86 bugzilla available

[Philip Brown]

On Thu, Mar 20, 2003 at 08:14:33AM +, Keith Whitwell wrote:
> 
> > Or, someone could just leave it as is, disable it and forget 
> > about it because sourceforge's bug tracking system sucks. [1]
> 
> I don't think we ever found out how to disable it.  Just another aspect of its 
> suckage - you can't turn it off.

Sounds like the real problem is that none of the DRI sourceforge admins
found out how to fully use the bugtracking system there.

Yes, there is a way to disable it so that it no longer appears on
http://sourceforge.net/projects/dri
There's lots of other things you can do with it too, that probably no one
on the list has checked into.




---
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: XFree86 bugzilla available

[Philip Brown]

On Wed, Mar 19, 2003 at 09:26:21PM -0500, Mike A. Harris wrote:
> ...
> Bugzilla requires a valid authenticated login.  Not possible to 
> do that with email->bugzilla at least currently.

btw: I heard that some of the previously hashed out opposition to using
the sourceforge bugtracker, was because it allowed anonymous bug
posting.

That is an *option*. You can turn off the option to allow anonymous
bug filing.



---
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: Re: XFree86 bugzilla available

[Philip Brown]

On Wed, Mar 19, 2003 at 09:31:41PM -0500, Mike A. Harris wrote:
> On Wed, 19 Mar 2003, Philip Brown wrote:
> >Even if the decision stands to no longer field new bugs there, it would
> >still be nice if someone cleaned out the bugs there that are no longer
> >relevant.
> 
> Feel free.

that requires both access/permissions to do so, and a working DRI system
to validate/devalidate bugs.
I have neither.



---
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] drmAddMap(xx,xx,xx,DRM_SHM) : "locked" ?

[Philip Brown]

On Wed, Mar 19, 2003 at 11:46:13PM +, José Fonseca wrote:
> On Thu, Mar 13, 2003 at 11:47:13PM -0800, Philip Brown wrote:
> > The docs at
> > http://dri.sourceforge.net/doc/drm_low_level.html
> > 
> > say about drmAddMap(), for type DRM_SHM,
> > 
> > "A shared memory area of the requested size will be created and locked in
> > kernel memory."
> > 
> > 
> > Is that supposed to be the same thing as "locked in physical memory"?
> > Because without specifying more exactly, under some OSes, it is not
> > the same thing by default.
> 
> You have to better enlighten the difference between those.
> 
> In either case, the physical memory offset itself is not important since
> the SAREA won't be accessed directly by the graphicas hardware: just the
> kernel, X and the client.


I'd rather hear first what it is "supposed" to mean in the current
implementations. The current docs say "locked in kernel memory".
As written, that statement does not make sense to me. So I am
GUESSING it really means "locked in physical memory". But I would like
clarification on what it is supposed to mean.


(I understand that the actual physical offset is not important. but
 I suspect that the original writers intended for it to be locked down
 into physical memory for performance reasons.)




---
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: XFree86 bugzilla available

[Philip Brown]

On Wed, Mar 19, 2003 at 07:52:00PM +, Keith Whitwell wrote:
> [...]
> The sourceforge bug tracker is a broken pos.

Yet tens, if not hundreds, of people seem to have reported bugs
successfully with it against dri.

Even if the decision stands to no longer field new bugs there, it would
still be nice if someone cleaned out the bugs there that are no longer
relevant.



---
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: XFree86 bugzilla available

[Philip Brown]

On Wed, Mar 19, 2003 at 12:07:56PM +, José Fonseca wrote:
> On Tue, Mar 18, 2003 at 08:04:22PM -0500, David Dawes wrote:
> > An XFree86 bugzilla is now available at .
> > Many thanks to Hewlett-Packard for supplying the hardware, netSweng for
> > hosting, and the many developers who helped configure and test it.
> 
> This is great news. I think a great job was done organizing the products
> and components.
> 

I dont get it. Why is this suddenly great news, when DRI could have been
using sourceforge's bugtracking system all this time?

I completely agree that using a real bugtracking system is what should be
happening right now.

However, it seems the decision to abandon that methodology was somehow made
around 2001, judging by all the bug reports already sitting on
http://sourceforge.net/tracker/?group_id=387&atid=100387

Someone with access should really go through those things, and clear out
all the ones that have now been rendered(ahem) obsolete.



---
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] using opengl without X or framebuffer

[Philip Brown]

On Tue, Mar 18, 2003 at 05:46:55PM +0100, otherside wrote:
> is there a way to do that ?
> just open a screen (monitor) and then write to it.
> i try to write a little library which opens the screen so you can draw 
> some polygons to it.
> will DRI help me to do it ?

Without a framebuffer, you are not going to get accelerated OpenGL. So
there's no point using DRI.

You should probably use Xvfb combined with Mesa. Slow but reliable results.

[assuming Mesa doesnt have a "render only to local memory" option
already]


---
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] drmAddMap(xx,xx,xx,DRM_SHM) : "locked" ?

[Philip Brown]

The docs at
http://dri.sourceforge.net/doc/drm_low_level.html

say about drmAddMap(), for type DRM_SHM,

"A shared memory area of the requested size will be created and locked in
kernel memory."


Is that supposed to be the same thing as "locked in physical memory"?
Because without specifying more exactly, under some OSes, it is not
the same thing by default.


(I hope that either way, the section in question will be updated in
 the page)



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] patch for function naming consistency

[Philip Brown]

On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote:
> Well, I didn't have much to do with this code when it was written, but I'm 
> happy for it to stay where it is and as it is named for now.
> 
> If someone wanted to take on a bigger task of comprehensively spring-cleaning 
> the radeon 2d driver, that might be interesting, but renaming & moving that 
> one function won't do anything to make the driver easier to navigate.


"A journey of 1000 miles begins with a single step"



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] Re: patch for function naming consistency

[Philip Brown]

On Wed, Mar 12, 2003 at 06:26:44PM -0500, Mike A. Harris wrote:
> []
> IMHO, the names of functions and the file they are located in 
> should be based on the functionality that they are providing, and 
> should be grouped based on similar functionality and not based on 
> similarities in portions of their names.

I agree with that sentiment 100%.

Which is why when I see the function in question, as providing a
DRI-specific function that does not *exist* if DRI is not compiled in,
it seems straightforward to me that as such, it should have a 
DRI-oriented name, and belongs in radeon_dri.c



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] patch for function naming consistency

[Philip Brown]

On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote:
> On Mit, 2003-03-12 at 19:15, Philip Brown wrote:
> > I just noticed that in drivers/ati, every single function related to DRI
> > initialization,etc. is named RADEONDRIXxxxYyyy ... except
> > RADEONPreInitDRI()
> > 
> > Here's a patch to fix that, and R128PreInitDRI()
> 
> This change doesn't seem obvious to me; the RADEONDRIxxx() functions are
> in radeon_dri.c and directly related to the DRI, whereas
> RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in
> radeon_driver.c


Maybe it belongs in radeon_dri.c, then? Coincidence of current location,
should not be a reason for avoiding logical naming and grouping.
If you like, I'll submit patches for doing the move AND rename.


> and mainly processes the DRI related driver options.

Consistency is a Good Thing.

It is nice and easy to do "grep RADEONDRI tags" to get a list of all
DRI-related functions for radeon.

[The fact that you can get more complicated with "grep RADEON | grep DRI"
  should not excuse the lack of consistency in naming]


So RADEONPreInitDRI() doesnt actually do any rendering; So what.
It is still "DRI related".



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] patch for function naming consistency

[Philip Brown]

I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()

Here's a patch to fix that, and R128PreInitDRI()


I had to make the patch "by hand" this time, since cvs seems down or
something.

--- /tmp/radeon_driver.c2003-03-12 10:09:06.08000 -0800
+++ radeon_driver.c 2003-03-12 10:10:05.60004 -0800
@@ -2859,7 +2859,7 @@
 }
 
 #ifdef XF86DRI
-static Bool RADEONPreInitDRI(ScrnInfoPtr pScrn)
+static Bool RADEONDRIPreInit(ScrnInfoPtr pScrn)
 {
 RADEONInfoPtr  info = RADEONPTR(pScrn);
 
@@ -3182,7 +3182,7 @@
 if (!RADEONPreInitAccel(pScrn))  goto fail;
 
 #ifdef XF86DRI
-if (!RADEONPreInitDRI(pScrn))goto fail;
+if (!RADEONDRIPreInit(pScrn))goto fail;
 #endif
 
/* Free the video bios (if applicable) */
--- /tmp/r128_driver.c  2003-03-12 10:09:06.09000 -0800
+++ r128_driver.c   2003-03-12 10:09:33.420044000 -0800
@@ -1664,7 +1664,7 @@
 }
 
 #ifdef XF86DRI
-static Bool R128PreInitDRI(ScrnInfoPtr pScrn)
+static Bool R128DRIPreInit(ScrnInfoPtr pScrn)
 {
 R128InfoPtr   info = R128PTR(pScrn);
 
@@ -1885,7 +1885,7 @@
 if (!R128PreInitAccel(pScrn))  goto fail;
 
 #ifdef XF86DRI
-if (!R128PreInitDRI(pScrn))goto fail;
+if (!R128DRIPreInit(pScrn))goto fail;
 #endif
 
/* Free the video bios (if applicable) */

Re: [Dri-devel] drmScatterGatherAlloc missing from docs

[Philip Brown]

On Wed, Mar 12, 2003 at 08:39:31AM +, Keith Whitwell wrote:
> Philip Brown wrote:
> > http://dri.sourceforge.net/doc/drm_low_level.html
> > 
> > should be updated with a functional description of
> > drmScatterGatherAlloc()
> 
> Patches welcome... :-)
> 

love to.. if I understood it... which would be facilitated by docs...
or code comments...

Best I have so far is,



int drmScatterGatherAlloc(int fd, unsigned long size, unsigned long *handle);

  drmScatterGatherAlloc is called to allocate a large chunk of DMA-suitable
  memory. Calling it more than once is an error.
  Once the memory is allocated, the user-level may access it through
  passing the handle to drmAddMap() with drmMapType DRM_SCATTER_GATHER.
  User-level code only sees the virtual address space.
  physical address of the allocated memory is passed to the hardware
  through FM [*]

int drmAgiAlloc(int fd, unsigned long size, unsigned long type,
unsigned long *address, unsigned long *handle);

cf: drmScatterGatherAlloc(), FM


[*] FM == old programming joke.




---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] drmScatterGatherAlloc missing from docs

[Philip Brown]

http://dri.sourceforge.net/doc/drm_low_level.html

should be updated with a functional description of
drmScatterGatherAlloc()


[and probably a few other drmXXXYYY() routines that have appeared
 since 1999 ;-) ]



---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] possible error in drm documentation, plus DMA question

[Philip Brown]

I'm reading through http://dri.sourceforge.net/doc/drm_low_level.html




int drmDMA(int fd, drmDMAReqPtr request)


drmDMA can be used to reserve DMA buffers and to dispatch previously
reserved DMA buffers. 




"reserve DMA buffers"?? I thought it is only currently used to
"dispatch" them, and actual allocation of DMA buffers is done via

drmAddBufs(), or drmAddMap()


Hmm.. it seems that these days, virtually all DMA allocation is done
via  drmAddMap(., DRM_AGP,...);
  True? 

There may be some alternative method used in
RADEONDRIPciInit(), but since there is no comment in that function
with "DMA" in it, I cant tell.




---
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] C++ Framework Concern

[Philip Brown]

On Wed, Mar 05, 2003 at 02:36:21PM -0800, Ian Romanick wrote:
> I suppose that it is doable, but it just seems wrong.  Doesn't this just 
> boil down to inheritance by conincidence?  Expecting each driver to 
> duplicate the same data structures and add their unique data onto the 
> end, without any checking done by the compiler, seems like a bad call. 
> If we going to do that, I would rather see it done as either a nested 
> structure (like driTextureObject) or as a macro:
> 
> #define DRI_TEXTURE \
>   int baseval;
> 
> struct radeontexture {
>   DRI_TEXTURE
>   int radeonextraval;
> };

Yes, I was going to suggest that if the topic of typos, etc came up :->

PS:

#define  DRI_TEXTURE_STRUCTINFO \


or some such.




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] C++ Framework Concern

[Philip Brown]

On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > 
> > Also, rather than containing the struct, you could do what is done already
> > in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
> > server code), and just extend the struct, rather than encapsulating it.  So
> > [quick-n-dirty illustration for discussion purposes]
> > 
> > struct dritexture{
> > int baseval;
> > };
> > struct radeontexture {
> > int baseval;
> > int radeonextraval;
> > };
> 
> So what happens when you want to refactor and move data out of 
> radeontexture and into dritexture?  Then the functions that operate on 
> dritexture will possibly break.

how so?


If you have a non-radeon card driver using dritexture, it will ignore
the extra field added. Or, it will keep using the same "base" functions,
which, if you done the "refactoring' right, will be a transparent change.

If you have a radeon card driver routine that previously accessed the
extra field.. it can STILL access the extra field. So what will break?



> > Also, since functions are not part of "the object", I dont see where
> > "overriding functions" comes into play. If you dont want to use a "base"
> > function, you just call a radeon-specific one?
> 
> That's exactly the problem!  If you change from using the "base" 
> function to using a derrived function, you have to touch the code in 
> every single place that used the base function.  If you miss one, you 
> have a bug...a bug that may go a long time unnoticed.

Are you honestly making the argument,
"Hunting down places that called RadeonTextureTwiddle, and renaming them
 to DriTextureTwiddle, is a difficult operation that can lead to bugs"  
??


It should be a straightforward excercise to migrate a sub-object function,
into a base-object function, as describe above. If it isnt, there are two
possibilities:

a) It doesnt BELONG as a base object function. case closed.
b) the writer of the sub-object function, did a poor job designing/writing
   the sub-object function. In which case, the author needs to be
   whipped^H^H^Hreeducated, and made to fix the design.
   Only after that is done, should it then be migrated up into the base
   object.

   in this model, it should not be a bug magnet any more than the
   corresponding operation of migrating from a C++ derived class
   to a parent class.




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] C++ Framework Concern

[Philip Brown]

On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > Are you saying that C++ somehow allows for more code sharing between
> > drivers than straight ANSI C?
> 
> It's not so much that it allows it as it makes it less painful.  Look at 
> the texmem-0-0-1 branch.  In lib/GL/mesa/src/drv/common/texmem.h there 
> is a structure called driTextureObject.  In 
> lib/GL/mesa/src/drv/radeon/radeon_context.h there is a structure called 
> radeon_tex_obj that has a driTextureObject as it's first element. 
> Basically, I'm using inheritance here.  The problem is that everywhere I 
> want to use something from the base "class" I have to say 
> "tObj->base.foo".  There's also no easy way to over-ride functions from 
> the base.
>..
> There are a number of structures, like the *_context structures, where 
> we could do this.  It's possible to do in C, but in C++ it's less 
> syntactically painful.

Given the abundance of macros already in use in dri, I would think you
would just define a macro for that sort of stuff ;-)

Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct, rather than encapsulating it.  So
[quick-n-dirty illustration for discussion purposes]

struct dritexture{
int baseval;
};
struct radeontexture {
int baseval;
int radeonextraval;
};



Also, since functions are not part of "the object", I dont see where
"overriding functions" comes into play. If you dont want to use a "base"
function, you just call a radeon-specific one?



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] C++ Framework Concern

[Philip Brown]

On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
> Jens Owen wrote:
> >   Concern #3:  Readability by the active contributors.  I'm not the only 
> > old fuddy duddy in this group of developers.  How much "readability" 
> > time do you figure the young C++ whipper snappers will save by investing 
> > in this transition to C++?
> 
> I don't think the issue is readability so much.  I think the bigger 
> issue is the ability to share code among the drivers.  Looking at the 
> code for the various CreateContext functions, the code is about 60% 
> between mga, radeon, r200, and r128 drivers.  I assume that the mach64 
> and savage drivers will likely be the same.  I haven't looked at the 
> i810 and i830 drivers, but they probably follow similar form.  If we 
> could share a bunch of that code among four or five drivers, it would 
> save a LOT of duplicated code.

Are you saying that C++ somehow allows for more code sharing between
drivers than straight ANSI C?

I can buy into a statement that, due to C++'s encouragement of OOP
behaviour, shared code can become more prevalant in C++ than in C.
However, I do not hold with the view that C++ intrinsically "allows" for
more code sharing.
If you're going to rewrite the code in C++ to facilitate code sharing...
you could just as well rewrite the code in better ANSI C to facilitate
code sharing.

[ Mind you, "technically feasible", and "someone with experience doing it"
 are two separate things. As I mentioned in the IRC chat to someone,
 "perhaps the real issue in your comparison of C++ and C code, is
  that you havent actually SEEN any well-written C code" :-> ]



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

[Philip Brown]

> Wed, Mar 05, 2003 at 12:23:50AM +, Alan Cox wrote:
> > "It works" is not the same as "it works cleanly".
> > APIs should be fixed, concrete definitions. The struct definitions in drm.h
> > are essentially part of the API (or ABI, whatever), and they are not fixed.
> > They should be cleaned up.
> 
> You can never achieve that on a wide cross platform OS. Little things like
> struct padding, alignment rules and so on get in the way now and then. There
> is an additional consideration because x86 is -horrible- at 64bit ops, gcc
> manages to do it quite badly at times too making it even uglier.

I dont see what performance has to do with informational type fields being
passed through an ioctl struct.


> Either way having typedefs for these so they can stay unsigned long and
> munged on x86 versus enforced 64bit on solaris doesn't seem to cause any
> problems.

Yeah, it would solve my problem, so I wont argue too hard if you want to
just go ahead and do that. But there could be a ludicrous amount
of extra typedefs for this sort of thing if you dont draw the line
somewhere.

For basic non-pointer-involved types, I would think everyone would benefit,
and you probably would not break anything, if you specified [u]intXX_t
types for all the structs that currently have the more loose declarations.

Well, okay, let me clarify that prior point, I suppose.
You wont break source compatibility. If you take machine type X,
compile a fresh driver and x server and client libs from new source,
it should all still work if you changed everything in drm.h to used
fixed size info.

If you took a preexisting machine, with an older drm kernel driver,
and tried to use the new source on it, it would break.
But then, that happens now anyway after DRI upgrades, doesnt it, so I dont
see that this should be considered a big deal

> For some of the DRM API's I'd agree with you - they don't hit the 
> performance considerations. However we already have an API and most
> XFree86 4.1/4.2/4.3 drivers [1] all run with the 4.3 DRM. You'd break that
> by changing the types.
>
> [1] i810 breaks 44.1 to 4.2 and 4.2 to 4.3 8(


There have been NO new card-specific ioctls added since xfree4.1,
apart from I810 ?
I'm surprised.

But, reguardless... I'd say migrating to a cleaner data structure that can
then remain fixed for longer, is good justification for doing a one-time
breakage upgrade.

If you dont want to, that's your call. But it's the "Right Thing To Do", IMO.



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM_READMEMORYBARRIER

[Philip Brown]

On Tue, Mar 04, 2003 at 09:18:40PM +0100, Benjamin Herrenschmidt wrote:
> 
> The purpose of this barrier isn not to ensure sequential access on
> either the MMIO mapping (card registers) nor the actual ring buffer
> memory mapping (could be IOs, or just real memory with PCI GART).
> 
> It's here to actually sync those 2 between each other. That is make
> sure the writes to the ring are completed before the chip is actually
> kicked. This is a nasty corner case often overlooked in drivers, see
> a mail I just posted to lkml '[RFC] IO vs. DMA and barriers'

Ooo. Quite different.

So that sounds like I'll want DRM_READMEMORYBARRIER() to call
ddi_dma_sync()

[ you've probably never seen that function before in your life, but
 I think it's a heck of a lot more self-documenting than
  "DRM_READMEMORYBARRIER()" , "mb()", or even "bus_space_barrier()"
  ;-)   ]



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

[Philip Brown]

On Tue, Mar 04, 2003 at 11:02:10PM +, Alan Cox wrote:
> On Tue, 2003-03-04 at 18:12, Philip Brown wrote:
> > All numeric fields passed through the ioctls, should have fixed,
> > identifiable sizes.
> 
> I guess you do need a typedef then so you can support solaris without
> trashing the other 99.999% of the userbase.

Well, technically, 99.9% of the userbase will be (linux|*BSD)/x86, so it would
only "trash" a potential 0.099% ;-)

> In the Linux world the
> ioctl32 handlers munge the structures. Different philosophy to
> handling the problem space.

Dont think of it as "trashing", think of it as "an opportunity to get rid
of 'munging'"  :-)


> I believe DaveM's DRM for the sparc64 linux is quite happy with
> mixed 32/64 user space.

Probably it has the same size for "unsigned long" in both 32 and 64 bit
modes.

"It works" is not the same as "it works cleanly".
APIs should be fixed, concrete definitions. The struct definitions in drm.h
are essentially part of the API (or ABI, whatever), and they are not fixed.
They should be cleaned up.


---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

[Philip Brown]

On Tue, Mar 04, 2003 at 10:56:25AM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > So kernel will be compiled with offset=64bits, user mode will be compiled
> > with offset=32bits... boom.
> > 
> > All numeric fields passed through the ioctls, should have fixed,
> > identifiable sizes.
> 
> Ah.  So this isn't just a 64-bit arch problem.  It's a mixed 32/64 
> problem.  That's different.  What happens on Linux is the 32-bit apps go 
> through some sort of ioctl thunking layer to convert the 32-bit ioctls 
> to the native 64-bit ioctls.  I know that this is done for IA-64 and 
> PPC64.  It will also have to be done for x86-64.


Does this "thunking" happen at the native OS level, or in the linux drm
code itself?

Reguardless, you still need to fix the issue that the header file
drm.h (and probably others) is included by both kernel and application
layer, therefore you should fix the type sizes of all values in structs,
to ensure that the structs are the same size whether they are included by
64bit or 32bit code.



> Can somebody explain exactly how this works on Linux?  I'm still a 
> little fuzzy on it.  Is there some way that DRI could handle this 
> "genericly" for supporting other operating systems?  I'm sure that 
> Solaris and *BSD don't handle it quite the same way that Linux does.
> 
> For Philip, I would suggest getting 64-bit apps to work with a 64-bit 
> kernel before trying to tackle mixed-mode.  You've got enough work to 
> port DRI to SPARC Solaris as it is! :)

Well, I'm not trying THAT monster :-) I'm just targetting Solaris x86 for
right now. But figured it's important to point out these issues, while I'm
looking at that level of the code.

And btw: the xfree server itself is typically a 32bit app, I believe.
/usr/openwin/bin/Xsun certainly is.



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

[Philip Brown]

On Tue, Mar 04, 2003 at 11:59:50AM -0600, Andy Isaacson wrote:
> On Tue, Mar 04, 2003 at 09:41:54AM -0800, Philip Brown wrote:
> > On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote:
> > > On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
> > > In fact I can't think of a single exception
> > 
> > Well then, obviously, you dont use solaris :-)
> 
> He uses Solaris and compiles for 64-bit mode, rather than the 32-bit
> mode you're compiling for.
> ...
> 
> The 64-bit kernel is perfectly capable of running 32-bit binaries, and
> that's precisely what you're doing.

Yes. And that's exactly what DRI users will do. So right there is a 
64/32 bit problem.

In drm.h, to take just one example.

typedef struct drm_map {
unsigned long offset; /* Requested physical address (0 for SAREA)*/
unsigned long size; /* Requested physical size (bytes) */
drm_map_type_t type; /* Type of memory to map */
drm_map_flags_t flags; /* Flags */
void *handle; /* User-space: "Handle" to pass to mmap */
 /* Kernel-space: kernel-virtual address */
int mtrr; /* MTRR slot used */
 /* Private data */
} drm_map_t;

So kernel will be compiled with offset=64bits, user mode will be compiled
with offset=32bits... boom.

All numeric fields passed through the ioctls, should have fixed,
identifiable sizes.



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

[Philip Brown]

On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote:
> On Tue, 2003-03-04 at 08:22, Philip Brown wrote:
> > "unsigned long" is semi-unspecified, but is reasonably assumed to be
> > a 32-bit quantity.
> 
> On all 64bit bit platforms I have met unsigned long is a 64bit quantity.
> In fact I can't think of a single exception

Well then, obviously, you dont use solaris :-)

#include 

main()
{
printf("Size of unsigned long is %d\n",sizeof(unsigned long));
printf("Size of long long is %d\n",sizeof(long long));
}

sparc$ ./t   [compiled with gcc 2.95.2]
Size of unsigned long is 4
Size of long long is 8
sparc$ isalist
sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld
sparcv7 sparc
[that confirms the sparc is running with a 64bit kernel]

If you want to assume that is a 64bit long value, you should be
using u_int64_t, or better yet, uint64_t

Speaking of which, there is "u_int32_t" in the bsd drm kernel stuff.
Technically, it should be uint32_t, which according to the comments in
sys/types.h here, is allegedly part of the ANSI C draft standard,
ISO/IEC 9899:1990
uint32_t appears to be present on solaris, freebsd, and linux



FYI, I'm developing on solaris x86.
Which also keeps the same type for "unsigned long" vs "long long".
Consistency across architectures is a good thing.




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] 32/64bit issues in ioctl struct passing

[Philip Brown]

As promised from the irc session... here's details on the little 
32/64-bit issue I ran into.

Its not quite a direct 32/64 bit thing in the drm itself exactly, but
ambiguity can be a problem...

drm_map_t.offset  is "unsigned long".

"unsigned long" is semi-unspecified, but is reasonably assumed to be
a 32-bit quantity.

mmap() takes an arg of type "off_t".
That value is essentially what is assumed to be passed in and used by
drm_map_t

Trouble is, the off_t value gets treated as a 64bit quantity at kernel
level, when servicing the mmap() request.

Most other OSs are probably going to transition that way, if they are not
there already.

So, if you're going to call something "offset", in a struct that is
targetted for memory map tracking... it should really be an explicit 64bit
length value.



---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM_READMEMORYBARRIER

[Philip Brown]

On Mon, Mar 03, 2003 at 05:42:24PM -0800, Alan Young wrote:
> On Mon, 3 Mar 2003 10:48:54 -0800 Philip Brown <[EMAIL PROTECTED]> wrote:
> > 
> > But anyway, sounds like I can NOP it out, I guess.
> 
> You may be able to NOP it if your platform does not require
> it.  I know the Alpha uses memory barriers.  I think PPC may   
> use them too.   
> 
> Here's a bit from the Alpha Architecture Handbook on the Alpha's
> memory barrier instruction:
> ...

ah. Thanks for the extra info.
[someone might want to comment the thing in the header files]

Solaris handles it differently. It specifies a particular memory mapping as
needing sequential access, at map time, I believe.




---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

[Philip Brown]

On Mon, Mar 03, 2003 at 02:58:01PM +, José Fonseca wrote:
>...
> An existing DRI driver has much more relevant information for a
> developer than the hardware specs.

except for the fact that the dri cvs tree, seems to have some sort of
auto-applied "strip" for source code on commit.
As "strip binaryname" strips out debug information, this auto-strip
seems to strip out almost all code comments. What an amazing space-saving
tool...


[ half :-> for the humor impaired ]



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRM_READMEMORYBARRIER

[Philip Brown]

On Mon, Mar 03, 2003 at 02:48:32PM +0100, Michel Dänzer wrote:
> ...
> > Besides which, DRM(ioremap) seems to do the *actual* mapping to kernel
> > space which still leaves the question of, what does
> > DRM_READMEMORYBARRIER() do?
> 
> As the name says, it issues a memory barrier. :)

I beg to differ... there is no verb in it, so it does _not_ say "issues a
memory barrier" :-)

Now, if it were called DRM_SET_MEMORYBARRIER(), that would be different.


But anyway, sounds like I can NOP it out, I guess.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] DRM_READMEMORYBARRIER

[Philip Brown]

Could someone explain what exactly DRM_READMEMORYBARRIER is supposed to do,
in the kernel driver level, please?

I was initially thinking that it did some kind of 
"enable bus memory mapping" OS call.
However, it is used inconsistently.

mga_drv.h and radeon_drv.h use it , each at only one place in the code.

mga seems to use it consistently before all DRM_READ8() type calls,
 via an inline func _MGA_READ()


However, radeon_drv.h only uses it before the READ8 call in
COMMIT_RING()

[and radeon is consistent in lots of other ways, too. 
 Some places it uses RADEON_READ(), other places, DRM_READ32().
 Maybe this is the cause of some of the radeon problems?]


Besides which, DRM(ioremap) seems to do the *actual* mapping to kernel
space which still leaves the question of, what does
DRM_READMEMORYBARRIER() do?


 


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] DRM_FREE patch

[Philip Brown]

Okay Keith,

here's a patch set for adding the extra size arg to DRM_FREE.

(attached)

It applies from the top of the 'os-support' directory.

I generated it with "cvs diff -u". I believe GNU patch will ignore the
extra cvs type stuff, but if not, lemme know.


? bsd/Makefile
? bsd/drm/Makefile
? bsd/drm/kernel/Makefile
Index: bsd/drm/kernel/drm_dma.h
===
RCS file: 
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/drm_dma.h,v
retrieving revision 1.11
diff -u -r1.11 drm_dma.h
--- bsd/drm/kernel/drm_dma.h21 Feb 2003 23:23:03 -  1.11
+++ bsd/drm/kernel/drm_dma.h2 Mar 2003 23:46:36 -
@@ -692,7 +692,7 @@
psignal(p, vbl_sig->signo);
 
TAILQ_REMOVE(&dev->vbl_sig_list, vbl_sig, link);
-   DRM_FREE(vbl_sig);
+   DRM_FREE(vbl_sig,sizeof(*vbl_sig));
}
vbl_sig = next;
}
Index: bsd/drm/kernel/drm_os_freebsd.h
===
RCS file: 
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/drm_os_freebsd.h,v
retrieving revision 1.12
diff -u -r1.12 drm_os_freebsd.h
--- bsd/drm/kernel/drm_os_freebsd.h 21 Feb 2003 23:23:04 -  1.12
+++ bsd/drm/kernel/drm_os_freebsd.h 2 Mar 2003 23:46:36 -
@@ -102,7 +102,7 @@
 #define DRM_IRQ_ARGS   void *arg
 #define DRM_DEVICE drm_device_t*dev= kdev->si_drv1
 #define DRM_MALLOC(size)   malloc( size, DRM(M_DRM), M_NOWAIT )
-#define DRM_FREE(pt)   free( pt, DRM(M_DRM) )
+#define DRM_FREE(pt,size)  free( pt, DRM(M_DRM) )
 #define DRM_VTOPHYS(addr)  vtophys(addr)
 
 /* Read/write from bus space, with byteswapping to le if necessary */
Index: bsd/drm/kernel/drm_os_netbsd.h
===
RCS file: 
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/drm_os_netbsd.h,v
retrieving revision 1.3
diff -u -r1.3 drm_os_netbsd.h
--- bsd/drm/kernel/drm_os_netbsd.h  21 Feb 2003 23:23:04 -  1.3
+++ bsd/drm/kernel/drm_os_netbsd.h  2 Mar 2003 23:46:36 -
@@ -89,7 +89,7 @@
 extern const int DRM(M_DRM) = M_DEVBUF;
 #endif /* __NetBSD_Version__ */
 #define DRM_MALLOC(size)   malloc( size, DRM(M_DRM), M_NOWAIT )
-#define DRM_FREE(pt)   free( pt, DRM(M_DRM) )
+#define DRM_FREE(pt,size)  free( pt, DRM(M_DRM) )
 #define DRM_VTOPHYS(addr)  vtophys(addr)
 
 #define DRM_READ8(map, offset) bus_space_read_1(  (map)->iot, (map)->ioh, 
(offset) )
Index: linux/drm/kernel/drm_dma.h
===
RCS file: 
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_dma.h,v
retrieving revision 1.12
diff -u -r1.12 drm_dma.h
--- linux/drm/kernel/drm_dma.h  2 Feb 2003 03:06:46 -   1.12
+++ linux/drm/kernel/drm_dma.h  2 Mar 2003 23:46:36 -
@@ -714,7 +714,7 @@
 
list_del( (struct list_head *) vbl_sig );
 
-   DRM_FREE( vbl_sig );
+   DRM_FREE(vbl_sig,sizeof(*vbl_sig));
 
dev->vbl_pending--;
}
Index: linux/drm/kernel/drm_os_linux.h
===
RCS file: 
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_os_linux.h,v
retrieving revision 1.6
diff -u -r1.6 drm_os_linux.h
--- linux/drm/kernel/drm_os_linux.h 21 Feb 2003 23:23:07 -  1.6
+++ linux/drm/kernel/drm_os_linux.h 2 Mar 2003 23:46:36 -
@@ -42,7 +42,7 @@
 
 /* malloc/free without the overhead of DRM(alloc) */
 #define DRM_MALLOC(x) kmalloc(x, GFP_KERNEL)
-#define DRM_FREE(x) kfree(x)
+#define DRM_FREE(x,size) kfree(x)
 
 #define DRM_GETSAREA()  \
 do {\
Index: shared/drm/kernel/r128_state.c
===
RCS file: 
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_state.c,v
retrieving revision 1.4
diff -u -r1.4 r128_state.c
--- shared/drm/kernel/r128_state.c  30 Oct 2002 06:10:34 -  1.4
+++ shared/drm/kernel/r128_state.c  2 Mar 2003 23:46:37 -
@@ -896,7 +896,7 @@
int count, x, y;
u32 *buffer;
u8 *mask;
-   int i;
+   int i, buffer_size, mask_size;
RING_LOCALS;
DRM_DEBUG( "\n" );
 
@@ -908,25 +908,25 @@
return DRM_ERR(EFAULT);
}
 
-   buffer = DRM_MALLOC( depth->n * sizeof(u32) );
+   buffer_size = depth->n * sizeof(u32);
+   buffer = DRM_MALLOC( buffer_size );
if ( buffer == NULL )
return DRM_ERR(ENOMEM);
-   if ( DRM_COPY_FROM_USER( buffer, depth->buffe

Re: [Dri-devel] Remote OpenGL

[Philip Brown]

On Sun, Mar 02, 2003 at 10:33:15PM +, Martin Spott wrote:
> Hello, did you know that remote display of OpenGL apps is partially
> functional with DRI ? At least the client side works ! I'm currently running
> FlightGear on a Linux PC against an SGI Octane functioning as X terminal.
> Performance is not bad - at least better than running FlightGear native on
> the (low speed) Octane  :-)
> I don't know _why_ this works

because you're not using DRI.
DRI essentially for Xserver-side stuff. The X server is on the SGI.
DRI is not involved here. You're just using a libGL.so that knows how to
talk the GLX extension protocol over the wire.

> Running FlightGear against OpenGL libraries compiled from the identical
> source tree against a DRI based Radeon X server does not look that nice.
> Running the same stuff against Octane X server instead looks as everyone
> loves it  ;-)

Which means theres a bug (or two :-) in the DRI radeon stuff. no surprise
there.

> P.S.: gcc-3.2.2, glibc-2.3.1, xfree86-3.4.0
*Amazing!  ;-)



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] cvs sponsor for portability patches

[Philip Brown]

On Sun, Mar 02, 2003 at 08:20:52PM +, Keith Whitwell wrote:
> Philip Brown wrote:
> > The one nasty that I do see coming up, and I dont see an easy patch for,
> > is DRM_MALLOC()/DRM_FREE()
> > 
> > Solaris requires knowing the size of the kernel mem you are freeing :-/
> 
> You could always add an arg to DRM_FREE and ignore it in other OS's.

Yeup. Thats my backup plan. I'm just hoping that there's something sneaky I
can do with the macro to make it magically work as-is, rather than having
to patch all the existing calls to DRM_FREE elsewhere.
But I guess the cleaner thing to do is adjust the macro.


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] cvs sponsor for portability patches

[Philip Brown]

On Sun, Mar 02, 2003 at 11:46:52AM +, Keith Whitwell wrote:
> Philip Brown wrote:
> > For example, I'd like to submit a patch set to fix the issue where
> > there is _DRM_LOCK_IS_HELD() calls all over the place, but there really is
> > only one syntax for it:
> > 
> > _DRM_LOCK_IS_HELD(dev->lock.hw_lock->lock)
> >
> > It would be more portable if it were simply
> > 
> > _DRM_LOCK_IS_HELD(dev)
> > ...
> 
> The change you mention above sounds reasonable -- post a patch to the 
> dri-devel list for review.  If it is sane, I'll commit it.

Thanks for the offer.

However, as part of my own sanity checks, I took a look at what was
on the latest cvs stuff... and it appears to be a good deal cleaner than
what I was looking at to start with.

So, this particular patch may not be neccesary after all.

The one nasty that I do see coming up, and I dont see an easy patch for,
is DRM_MALLOC()/DRM_FREE()

Solaris requires knowing the size of the kernel mem you are freeing :-/

But, maybe I can code around it. :-/


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: future of DRI?

[Philip Brown]

On Sun, Mar 02, 2003 at 02:26:04AM +, Alan Cox wrote:
> People were saying that ten years ago. They were wrong
> then, and I suspect they are wrong now. Too many people
> think X11 == XFree86. XFree86 is an *implementation* 
> (arguably two with kdrive) of X11.

Even ignoring kdrive, I'd call it two implementations in one.
After all xfree86 is still basically a "bolt-on" to the old standard
X11R6.

There are still TWO SEPARATE APIs for doing 2d drivers.
There's the stock-standard

Xserver/hw/{standard-driver-here}
 (eg: Xserver/hw/sun)

and then there's

Xserver/hw/xfree86/drivers/{xfree-extensions-driver-here}

I havent studied the ramifications of supporting both those models in
detail, but just the fact that xfree is still essentially a bolt-on
product, strikes me as a Bad Thing, for a "nice, clean" implementation of
an X server.

> > I agree that X is very complicated to work on. Mozilla
> 
> 2D XFree86 is *easy* to work with. It took me a day to learn
> how to write input drivers, ...

Funny. It took me a lot longer, because

 - first I followed the x consortium docs on how to write an XINPUT
module...

 - found it was lacking a bit from how the "standard" X11 framework wanted
   things to be

  - found that was slightly different from how the average XFREE86
input module was implemented

  - found neither of the two were exactly like how Xsun did XINPUT
modules...

Okay, the last one isnt exactly relevant to this discussion ;-> but
serves as grist for the mill of "there aint no truely standard X server"

> Since XFree 4.0 you don't have to touch the core code, you
> don't have to duplicate a ton of stuff and you don't need
> to know zip about DDX, MI and the other core layers.

Sounds nice. Too bad the core itself hasnt been cleaned up to unified
the card driver models more.


Oh, and for what it's worth... "implementation of an X server" still isnt
what most people care about to run (2d) programs. 
Most people care about "Can I compile something that expects libX11.so" ?

Which really means, for 95% of users out there, all you "really" need,
is a lookalike for libX11.

I had basic X11 apps compiling on  (durnit, have to verify 6809 vs 68000)
(searches google...)
Damn.. Too far back. Some time in 1988, I think. Anyhow, I believe
I had some X11 apps compiling and running on a 6809, running OS9 on a computer
with 512k of memory (64k max addressible at a time)

You think I had an X server running? ha-ha. Nope, progs just care about
the X11 lib.

So for the "X on top of OpenGL" afficionados... you could get away with
just writing a libX11 clone on top of a direct OpenGL implementation
like Embedded Mesa or something.
Skip the whole server fiasco entirely.
Mind you, you'd need to cobble together some kind of window manager behind
the scenes. My old hack relied on a native window manager to take care
of that sort of thing.


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

[Philip Brown]

On Sun, Mar 02, 2003 at 12:57:42AM -0500, Daniel Vogel wrote:
> I guess you also had to take away mandatory software fallbacks and the 
> imaging subset. In reality though, every IHV I've talked to stated their 
> OpenGL drivers being far more complex to maintain.
> 

The question is does that really mean one or both of,

1) "we have to pay our OpenGL developers more"

2) "we dont have enough people on staff who understand OpenGL -- all
our people are trained on the latest microsoft stuff as #1 priority"



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] cvs sponsor for portability patches

[Philip Brown]

If I were to spend the time to put together some portability patches
[for the kernel layer], would someone with cvs access volunteer interest to
review and put them in?  I can potentially see a bunch of little ones
coming up, so rather than post every single one individually to the list, I
thought I'd suggest a more one-to-one chain.

For example, I'd like to submit a patch set to fix the issue where
there is _DRM_LOCK_IS_HELD() calls all over the place, but there really is
only one syntax for it:

_DRM_LOCK_IS_HELD(dev->lock.hw_lock->lock)

It would be more portable if it were simply

_DRM_LOCK_IS_HELD(dev)


There are at least 9 files that would need minor tweaks for this to be
cleaned up. Probably more like 15.
I'm happy to generate a clean set of patches, if someone's actually going
to bother to put it into cvs.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

[Philip Brown]

On Sat, Mar 01, 2003 at 03:05:37PM -0500, Mike A. Harris wrote:
> On Sat, 1 Mar 2003, Smitty wrote:
> >a V3 gets smacked around by a TNT2, 
> 
> Not with open source drivers it doesn't.

got some specs on how the V3 performs, with glxgears?

google only pulled up results from someone who said their setup seemd to
not be configured properly.
(68 FPS)



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] BSD kernel folks on here?

[Philip Brown]

This the appropriate place to send suggestions about the bsd drm driver?

There's an interesting amount of effort in the BSD side, to attempt to make
a more portable framework. But it's missing a few things here and there.
The first thing I've run into:

there is

#define DRM_OS_SPININIT(l,name)

but there needs to be a matching

#define DRM_OS_SPIN_DEINIT(l)

For freebsd, apparently, it will be a NOP. For other OSes, it may be
 required, to avoid wasted kernel resources.

(you then have to pick the appropriate place to CALL the DEINIT routine,
 o course. I havent gotten to that point yet.)



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] future of DRI?

[Philip Brown]

On Fri, Feb 28, 2003 at 10:29:04PM -0800, Ian Romanick wrote:
> Daniel Vogel wrote:
> > Does DRI have a future with neither NVIDIA nor ATI participating?
> > Are people actually talking to them about why they don't use it and
> > what has to be done to remedy this fact? Shouldn't this be a top priority?
> > 
> > 
> > To clarify: I meant what has to be done to make DRI (direct rendering
> > *infrastructure*) attractive for IHVs. I didn't mean to imply what has to be
> > done to get NVIDIA or ATI to release open source drivers and whatnot.
> 
> The uncanny thing is that this is almost EXACTLY my job description. :)

How about writing documentation for the kernel-level API then?
It's not very attractive to write to an API that doesnt have any official
documentation.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] future of DRI?

[Philip Brown]

On Fri, Feb 28, 2003 at 05:15:58PM -0500, Daniel Vogel wrote:
> 
> So, are there technical reasons for NVIDIA not to use the DRI if ATI does?
> 

yes.

NVIDIA already has their own cross-platform low level driver, with a
cross-platform 3d API. It's their "UDI", Unified Driver Interface,
or something like that.

So if they switched to using DRI, they would then be looking at rewriting
their own crossplatform(?) opengl implementation that currently
nicely slots onto their UDI.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Using DRI to implement 2D X drivers

[Philip Brown]

On Fri, Feb 28, 2003 at 05:06:15PM +0100, Michel Dänzer wrote:
> > I haven't look at this but if the DRM modules know
> > about setting up the hardware and changing resolutions
> > then there may be no need for framebuffer any more.
> > You could write a generic framebuffer driver that was
> > implemented in terms of the DRM interface. But this
> > wasn't part of the intial idea.
> 
> But what's the point, instead of simply using the framebuffer device,
> which has been established and is needed for console on many
> architectures?

is your definition of "many architectures" == "many variants of linux" ?



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] future of DRI?

[Philip Brown]

On Fri, Feb 28, 2003 at 09:45:26PM +, José Fonseca wrote:
> 
> Even if DRI stops being the main source of 3D drivers for Linux/BSD, it
> will remain to be the main source of _open_source_ 3D drivers. That,
> alone, gives DRI a competitive advantage over any other solution. Just
> in the same way that it has given Linux, Apache, XFree86, and many other
> successful OSS projects.

all those other successful open source projects, had open 
(or at least, known) hardware to work with. It's not the same equasion in
the 3d graphics field.


> Bare in mind that OSS developers don't need absolute market dominance of
> the software they write. They obviously enjoy that what they write is
> widely used - it means that is useful -, but they don't depend on it.

True. 



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Using DRI to implement 2D X drivers

[Philip Brown]

On Thu, Feb 27, 2003 at 06:41:50PM -0800, Jon Smirl wrote:
> 
> If 3D isn't important to a desktop, then why are my
> windows stacked on top of each other? Why do my
> buttons depress and my windows look like they have
> raised borders? Edit boxes have shadows and menus look
> like they raise when the mouse if over them. Right now
> we are going through a lot of effort to simulate 3D.

I'm using fvwm. The borders are simulated 3d using very LITTLE effort.
Having it done through opengl would probably increase the amount of
complexity and whatnot considerably, I would guess.
Sure, I could have smooth color gradients, fading, even animated borders...
but I dont WANT them. That distracts me from what's actually going on in
the window itself. I could care less about the borders.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] question on kernel (dri)context switching

[Philip Brown]

I'm wading through DRM context switches at the kernel level now.
I've gotten lost a bit -- I'm missing a chunk o stuff at the
(*) point.



User wants a "context switch" to happen.
Calls ioctl(DRM_IOCTL_SWITCH_CTX)

 Kernel goes into DRM(context_switch)
  Sets an internal "current context" Variable
  Usually writes out "C oldnum newnum" to user fd
 (which has the user sideeffect of triggering SIGIO)


  (*)Kernel  (goes to sleep? "wakes something up"???)
  until user does another ioctl, this time with ioctl(DRM_IOCTL_NEW_CTX)
[what is dev->context_wait for?]


  [the second ioctl triggers DRM(context_switch_complete), which does
   something to dev->context_wait  again]


I dont get why there is a need for both DRM_IOCTL_SWITCH_CTX and
DRM_IOCTL_NEW_CTX

And what does DRM_FLAG_NOCTX really signify?



---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] UT2003 crash with current trunk

[Philip Brown]

On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote:
> Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on
> Debian unstable and the latest demo release of UT2003 (v2206 -- which
> is purported to not need S3TC extensions), I get the following
> traceback reported by UT2003:
> 
> phil@trigger /scratch/phil/ut2k3/demo >./ut2003_demo  
> Xlib:  extension "XiG-SUNDRY-NONSTANDARD" missing on display ":0.0".

???

This looks like you are using Xig libGL.so library. Deinstall Xig libs
before doing tests like this.




---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] question on lightweight vs heavyweight locking

[Philip Brown]

I've been reading
http://dri.sourceforge.net/doc/hardware_locking_low_level.html

and the code, obviously... so I've seen references to the "lightweight"
lock. ButI have yet to figure out why there is one.

The url document mentions that one supposedly exists, and that
"the lightweight lock will not be designed to be shared between GLXContexts"
and that
"The lightweight lock will be stored in a user-space shared memory segment
 that is available to all locking entities."

But it doesnt seem to spell out exactly what the lightweight lock
 should be used for, or what the kernel's role in it should be.

Can I basically just ignore the "lightweight lock" at kernel level, and
let the userspace code sort itself out?

Also, as far as the heavyweight lock goes... It has been described as,
"The hardware lock is obtained whenever the hardware is touched, and
  holding the lock implies that no other entity in the system will touch the
  hardware. "
   [http://dri.sourceforge.net/doc/drm_low_level.html]

That being the case, I'm thinking of just
having the heart of ioctl(DRM_IOCTL_LOCK) be a straight kernel mutex,
since solaris supposedly handles mutex queueing fairly well, rather
than implementating a whole separate queue mechanism.

Any comments on this?




---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] sorry, ignore prev kernel message

[Philip Brown]

Sorry, sorry.. missed seeing the bounds check, even though its right there.
It's late where I am, and it's been a long day.


---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] possible kernel level robustness improvement

[Philip Brown]

Just a suggestion that comes to mind as I'm crawling through the
kernel-level code...  
[the xfree 4.2.0 version]

but it looks to me like if userland passes in an incorrect context number
in a call to DRM_IOCTL_LOCK, it could cause a kernel panic, due to
no array bounds checking in

drm_drv.h, DRM(lock), 
  q = dev->queuelist[lock.context]





---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

[Philip Brown]

On Mon, Feb 17, 2003 at 11:24:10AM -0800, Ian Romanick wrote:
> >>So, what happens if I have four identical video cards in my system?
> > 
> > why would you want different configs for them?
> 
> There are probably as many different reasons as there are different 
> people that have such configurations.  One that I can think of really 
> easy is that you might have different monitors one each (small flat 
> panel on one, large CRT on another).  A person might use each head for a 
> different purpose.  You might want different settings for the head that 
> you have your UI on than the head that you do render pre-views on.

Then you pretty much HAVE TO go with a screen-number based config one way
or another. 

[particularly if your yardstick is "what does ms-windows do?"]

You could use the pci ids to check to see if the device has changed. But
otherwise, I think just a straight screen-num based set of configs would
make the most sense.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

[Philip Brown]

On Sun, Feb 16, 2003 at 10:52:34PM -0800, Ian Romanick wrote:
> Philip Brown wrote:
> > So, why not do it by PCI vendor/devid ? That sort of information is visible
> > from the DRI level, I believe. I think its just another Xserver internal
> > call, isnt it?  
> 
> So, what happens if I have four identical video cards in my system?

why would you want different configs for them?



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

[Philip Brown]

On Sun, Feb 16, 2003 at 05:55:55PM -0600, D. Hageman wrote:
> > So, why not do it by PCI vendor/devid ? That sort of information is visible
> > from the DRI level, I believe. I think its just another Xserver internal
> > call, isnt it?  
> 
> I thought about PCI vendors/devid ... problem with that is that we would 
> like to have a sane configuration for a normal user.  I think using that 
> would be too confusing for the user.  If we use the identifier that is 
> specified in the XF86Config I think it would be the most logical route - 
> don't you think?

What's your definition of "sane configuration" ?

Nothing is stopping you from using the PCI ids as the *actual* tagging
mechanism, but perhaps using the xfree86 card name as a comment to
help the user out a bit.

IMO, that extra "config comment" stuff should be handled at user-level.
Keep that sort of stuff out of the kernel.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

[Philip Brown]

On Sun, Feb 16, 2003 at 02:00:01PM -0600, D. Hageman wrote:
> On Sat, 15 Feb 2003, Philip Brown wrote:
> > I think this is a much cleaner overall design.
> > After all, you dont open /dev/fbX and tell it, 
> >   "I want you to be associated with this video card now..."
> 
> The stuff that I talk about above was regarding individual driver 
> configuration items that are currently being set by using environment 
> variables.  It has no bearing on the logic or instrumentation used 
> to bind a particular device to an OS interface.  

Ah. You're just looking for a way to tag a particular video card for
user/program configuration option purposes.
Re-reading your original email, it looks like you already rejected
"do it by screen number", and seem to be looking for a more hardware-level
identifier. 
So, why not do it by PCI vendor/devid ? That sort of information is visible
from the DRI level, I believe. I think its just another Xserver internal
call, isnt it?  


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

[Philip Brown]

On Sat, Feb 15, 2003 at 01:24:26PM -0600, D. Hageman wrote:
>...  We played around with using Screens and driver 
> names, but in the end we were looking at keying off the device identifier.  
> At this time I still believe that is the best thing to use, but we have
> no way at this time of grabbing such information from inside a DRI driver. 
> 
> What I would like to do is add a field to the DRIInfoRec struct:
> 
> char* cardIdentifier or char* configIdentifier
> ...
> 
> This option would set in the DRIScreenInit much like the busIdString is
> set during initialization.  Does anyone see any issues with this or does 
> anyone have any technical objections on why this shouldn't be done?

I'm coming from a solaris driver background (and am actively working on a
drm port to solaris)
 
In solaris, it is much more common (practically required, really) that driver 
"instances" are bound to a particular piece of hardware, by the OS level
driver loading proceedures.
  [This is because the OS is very rigid about deciding where to send
   interrupt notifications to]

As such, instances of drm in solaris already come associated with a
particular video card.

I would like to see a model where, instead of the X server telling
/dev/drm/card0, "You are bound to this card", the **drm** driver tells
the X server, "I am associated with this card ".
 (here is the base address, here is the PCI id, etc, etc)

I think this is a much cleaner overall design.
After all, you dont open /dev/fbX and tell it, 
  "I want you to be associated with this video card now..."




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Security in new drivers

[Philip Brown]

On Sat, Feb 15, 2003 at 01:51:57AM +, Alan Cox wrote:
> On Fri, 2003-02-14 at 23:56, Philip Brown wrote:
> > how is "only user joebrown can read and write /dev/dri/card0" any less
> > effective when there are multiple users on the box ??
> 
> As well as the unix permissions DRI is also playing games with
> authentication of its own between the server and clients

So the idea is maybe that:

Someone could get access to the device, get a "key",
"log out", but not fully log out, and keep the key...
then the next person logs in, uses DRI, but the first person still has
access?

I'm not up to speed on the drm kernel access granting methods yet.. would
this really work? I'm surprised, if it does . I would think if one user
logs out, then the X server gets killed. At which point, I would assume
that the drm code would reset all access to the dri device.

If not, sounds like someone has some more kernel coding to do ;-)



One "obvious" way to handle this, would be for the root server to send the
uid of the first DRI-using user-level process as part of the "request a
key" sequence to the driver. Then the driver only grants access to root,
and that user, until the main root session dies. Then access perms should
be reset, and there's no more security problem.



---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Security in new drivers

[Philip Brown]

On Fri, Feb 14, 2003 at 03:23:07PM -0700, John Bartoszewski wrote:
> On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote:
> > Also keep in mind that access to the DRI can be controlled via ownership
> > and permissions of the /dev/dri/cardX devices.
> 
> On a private machine this is method is effective.
> On a public machine, such as a University lab, where all users must
> be considered hostile this is less effective. 

how is "only user joebrown can read and write /dev/dri/card0" any less
effective when there are multiple users on the box ??



---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] CTX ioctl differences

[Philip Brown]

Could someone please explain the difference between


DRM_IOCTL_ADD_CTX

vs

DRM_IOCTL_NEW_CTX


Then again, maybe DRM_IOCTL_NEW_CTX is more like DRM_IOCTL_SWITCH_CTX,
reguardless of whether the name itself sounds more like ADD_CTX?




---
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] issue with DRM_IOCTL_SET_UNIQUE ioctl

[Philip Brown]

I would like to request a fundamental change, to a minor part of the DRM
API.

I believe that the current semantics of
ioctl(DRM_IOCTL_SET_UNIQUE) and ioctl(DRM_IOCTL_GET_UNIQUE), violate POSIX/SUS
understanding of the ioctl command.

To quote from the single unix specification version 2 (1997)
http://www.opengroup.org/onlinepubs/007908799/xsh/ioctl.html

"
 The arg argument represents additional information that is needed by this
 specific STREAMS device to perform the requested function. The type of arg
 depends upon the particular control request, but it is either an integer or
 a pointer to a device-specific data structure."

It is NOT expected that you pass in "a pointer to a structure that has a
pointer". You are not supposed to pass in arbitrary pointers to userspace
for manipulation by the kernel.

The original reason for this was that ioctls were supposed to be STREAMS
messages. You put together a little "packet", that contains either an
integer value, or a structure, and then the data packet gets sent
upstream, and the kernel interprets the datapacket.
Or you request a datapacket, and the kernel sends a packet downstream to
you.
Everything is supposed to be self-contained in the packet.

Bringing the API in line with traditional UNIX ioctl behaviour, makes it
easier to port the drm driver to other architectures.


My proposal is to change, in drm.h

typedef struct drm_unique {
size_t unique_len; /* Length of unique */
char *unique; /* Unique name for driver instantiation */
} drm_unique_t;


to be

typedef struct drm_unique {
size_t unique_len; /* Length of unique */
char unique[DRM_UNIQUE_MAX]; /* Unique name for driver instantiation */
} drm_unique_t;

The caller is then responsible for copying the string in and out of the
struct as appropriate.



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] decoupling from xfree server code a little

[Philip Brown]

I've been poking around the xfree86 server side of dri a bit ...
eg: hw/xfree86/drivers/ati/radeon_dri.c

and it occurs to me... why is this stuff in the core server?
Why isnt it in the dri "module", rather than hacked into the main server?

I've scanned through most of it, and it all looks like stuff that can be
done in a module.
(stuff that Utah-GLX, for example, does as a pure xfree86 module)

Okay, so maybe one or two routines make use of the radeon register include
files, hardware defs, etc. But so what? That stuff doesnt change much. 

Wouldnt it be much, much cleaner design to pull all that stuff out into the
actual "module", rather than having to hack up the xfree86 server build
process and decide ahead of time, "Am I going to build the server with
DRI support or not?"



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration file format survey

[Philip Brown]

On Tue, Jan 28, 2003 at 09:56:09PM +, Sergey V. Oudaltsov wrote:
> Hi
> 
> Just one little XFree-related pro-XML story. Not from DRI, from XKB
> life. You know, XKB configuration is generally held in
> /usr/X11R6/lib/xkb directory and several subdirectories. All this would
> be fine if the format of the files in these directories would be
> something good, structured, readable (by human and machine). But
> historically it never was.
.[...]

Good story. But right there, you point out the main difference between your
example, and the XFree86 config format.


BTW: I hope you folks will fix it so that it is finally possible to
have /usr/X11R6 be read-only

The only culprit stopping this, as far as I know, is the xkb stuff.




---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration file format survey

[Philip Brown]

On Tue, Jan 28, 2003 at 03:51:26PM -0500, Jamie Guinan wrote:
> 
>> If the XML can be kept relativly simple to read and edit then fine but
>> the end user should never have to use a config tool if they don't want
>> to. So please keep it as simple as possle. In my opinion the
>> readability of the config file should be a much bigger concern then
>> having a multitued of configuration programs out there.  Even the best
>> config program will have it's limits and I for one don't want to be
>> constrained by them.

> I can see 3 ways this can work out:
> 
>   1) The new format is tolerably readable XML, and power users learn 
>  to see around/through/between the all <>'s.
>   2) An XF86Config-ish format is used, with an XML layer on top that
>  some tool boils down to the XF86Config-ish format (I think the 
>  Red Hat printer config tools do something like this). DRI won't 
>  be any the wiser.
>   3) The inverse of [2], where the DRI format is XML, and a tool
>  to convert from XF86Config-ish syntax to XML is created, just
>  to make the power users happy.

Why did you leave out

   4) an XF86Config-ish format is used, we use the libx86config library,
 (or whatever the name of the lib is :-)
 and no XML is involved at all

  ?

That is the best fit to meeting the requirements of the initial paragraph.

> If you think about it, what *really* matters is the bytes inside DRI.  
> The XF86Config syntax is just sugar to make it easy to get the right
> values in there for people handy a text editor.  An XML syntax is just
> different kind of sugar which makes it *trivial* to write tools for people
> handy with a mouse.  Not to mention facilitating features like preventing
> invalid configurations from being saved, and other stuff that comes
> essentially free with XML.


The "writing tools" bit is handled already, given the existence of
the xf86 config library. So "XML makes it easier to write tools" is an
invalid argument.
Not to mention that "people handy with a mouse", and not code, should not
be writing tools for this stuff in the first place!


And the "preventing invalid configurations" stuff is not "free". As I
understand it, you have to write lengthy XML stuff to set rules, etc, etc.


The argument was previously made, of "Well, we'll keep the XML syntax
simple, so the bloated XML argument wont apply".

I would think writing all the XML rules, and then having all the current
developers have to *learn* all the XML syntax, so they can figure out what
the heck is wrong with what they want to add to the config file, lands back
in the "bloated XML" side.



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration file format survey

[Philip Brown]

On Tue, Jan 28, 2003 at 01:22:55AM -0600, D. Hageman wrote:
> ...
> 2) The XF86Config file format does what it does very well.  It isn't 
> necessarily what we are looking for.  It also isn't exactly a library that 
> one can just use.  It is a very custom built parser for a very specific 
> purpose.  We don't need to re-invent the wheel here.
> 
> ...
> No - as stated above it is a custom built parser with very specific 
> operating parameters.  You can look at it yourself in the XFree86 tree and 
> you will see what I mean.  

Hmmm. Unfortunate.

Well, on the brighter side, I would say that the XFree config file would
seem to have a simpler parsing style than your average XML document.

Perhaps the DRI config team could do the xfree side a favour, and write an
actual mini-library. Then actually migrate code in the other direction
for once :->

After all, it seems to be a pretty durn simple layout.
It has "only" two basic levels. 
At the simplest overview, it only has

Section {sectionname}
  Directive {value}
  SubSection {subsectionname}
Directive {value}
  EndSubSection
EndSection

The irritating bit comes when you add in the Option wildcard.

If you ignore that, you could write a parsing library for it in well under
a weekend. Probably a single day,even.
Well, *I* could, if I had the free time, and actually wanted to spend it on
such an endevour ;-)



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration file format survey

[Philip Brown]

On Tue, Jan 28, 2003 at 07:22:33AM +0100, Sven Luther wrote:
> 
> Another disadvantage is that parsing is so damn slow.

Yeah, tell me about it.

The place where I work had to buy some auxiliary processing boxes to
augment the webservers. Black box "appliance" like things.

SSL processing engines?

Nope. XSLT "accelerators".



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration file format survey

[Philip Brown]

On Mon, Jan 27, 2003 at 10:37:06PM -0600, D. Hageman wrote:
> On Mon, 27 Jan 2003, Philip Brown wrote:
> > If you want to get experience/resume padding doing XML coding, please do it
> > elsewhere.
> 
> Please don't make this a personal attack.  Public forums are not an 
> appropriate place for such things while we are trying to be constructive. 

I guess I should have specified that the "you" in that sentance was meant
as a collective noun, not neccessarily to one person alone.

I am trying to point out that none of

 "XML is cool",
 "XML is a hot trend right now"
 "I havent had as much XML experience as I'd like"

are valid reasons for selecting XML as the basis for a file format.

Nor is "well, there's an xml library, why dont we use it?"
There are embedded scheme/java/python/perl libraries too. The argument
doesnt make any more sense for those .

On the other hand,
 "DRI is meant to integrate with XFree86. XFree86 has a standard
  configuration file format. We should follow the 
  'principle of least surprise', and use the same format they are used
  to for X11 configuration"

DOES seem to make a good deal of sense, when considering the needs of users
as more important than the needs of developers.

> > Preferably in an area that XML was designed for: in exchanging
> > data between programs and OTHER programs, not between humans and programs.
> 
> Simplify:  GUI configuration tool (program)  <-->  Driver (program)

There are GUI tools for Xfree configuration too, and they have managed to
get along fine without using XML.
If you want a "Library" for config file parsing, cant you just use whatever
the x server itself uses?



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration file format survey

[Philip Brown]

On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote:
> 
> I think you misunderstand.  We aren't replacing the XF86Config file here.  
> This is for DRI specific driver settings with capabilities extending to 
> having special options for individual programs if need be.  
> 
> Now if I am mistaken and you did understand ...

I did understand...


> Your argument is bogus.  You can't claim that every XML file format leads 
> to unreadable files.   Now, if you have a good *technical* reasons why we 
> shouldn't use XML - I would love to hear them.  

Looks like you dont understand.

"technical reasons" are NOT the only reasons that should be considered when
evaluating config file formats.
Config files are (at least on UNIX systems) generally targetted at
users being able to edit them. by hand.

*users*, not developers.

As such, it is important to have a clear, easy-to-understand format.
XML is not that format.
 (okay, XML isnt a format, its a meta format, blah, blah, blah)

Sure, you could design a schema/dtd/whathaveyou in XML that would be more
readable and it would probably end up looking a lot like the XF86Config
file format. 
Or one of the other well known config file formats.

If you want to get experience/resume padding doing XML coding, please do it
elsewhere.  Preferably in an area that XML was designed for: in exchanging
data between programs and OTHER programs, not between humans and programs.

Unless you believe that the config file should not be edited by users. 
In which case, go all the way and make it a binary file.


> Couple of good reasons to use XML:
> 
> *) Parser with validation capabilites already written.
> *) More and more utilities are using it ... fontconfig for example.
> *) bindings for all major languages.
> *) A copy of libxml already exists in the tree if a person doesn't already
>have it.
> *) Extensible.
> *) It can be edited with any text editor.

C code can be edited with any text editor, too. But the percentage
of DRI users that can usefully DO that, is a very small number, comparative
to the overall number of users.




---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] Configuration file format survey

[Philip Brown]

On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
> If anyone has serious objections to XML, please let us know (mail to
> dri-devel will suffice ;-).

I object. Using xml inevitably leads to files that are completely
human-unreadable, except perhaps to the original developers.
Please stick with ye olde standard XF86Config type format.
It  could be better, but it is CERTAINLY better than XML.



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Dri-devel] request for small DMA test

[Philip Brown]

Would someone possibly do me the favour of either pointing me
to a [very] small program that tests basic drm
 (Allocate DMA mem), (Read/Write DMA mem), (Free DMA mem)
functionality, or, if you are feeling particularly generous,writing one?

I'm not talking about excercising any specific video card functionality -
 just the opposite. I'm looking for something that is card-neutral.

I would hope that for some of the notables on this list, it should take
maybe 10 minutes tops. Plus, once done, it could become part of a basic
DRM validation suite.

IF on the other hand I wrote one, it would probably take a long time,and
I'd do it wrong.



---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] patch for host.def

[Philip Brown]

On Wed, Dec 18, 2002 at 12:57:45AM +, Alan Hourihane wrote:
>  
> HasGlide3 is set to NO by default and only enabled on Linux with an i386
> or Alpha architecture.

Good to know that it is fixed in later versions. I was using Solaris i386,
so I was probably running afoul of old bad assumptions about i386 at the
time. Hopefully it is now checking for BOTH Linux and i386, as you say.



---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [Dri-devel] patch for host.def

[Philip Brown]

On Wed, Dec 18, 2002 at 12:17:29AM +, Alan Hourihane wrote:
> And which host.def is this a patch against ? It does not match the trunk's
> versions at all. For a start there is no definition of LinuxDistribution
> in the trunks host.def file.
> 
> You shouldn't need OS level patches like this at the host.def level.
> 
> Please post more details on the errors that you are getting during building 
> of the trunk.

Ah, sorry. Going back a week or two in memory to when I posted it to
sourceforge, I think I took it off a static tarfile, which I took at the
time to be the "stable" distribution or some such.


As far as "not needing OS level patches at the host.def level"... 

Some features, namely, Glide3, seem to be only valid for particular OSes,
so it would have to be an OS level patch. As far as WHERE it goes, 
please suggest/patch whereever you find it to be most appropriate. I'm just
reporting what I needed to get the stuff to initially configure, and so
forth.

I made a quick run at a patch, and have moved on to other things.
For those who have a deeper understanding of the config files, please
do the right thing whereever it is now appropriate.


> > --- host.defFri Sep  8 13:33:49 2000
> > +++ host.def.newFri Sep  8 13:39:11 2000
> > @@ -3,15 +3,24 @@
> >  #define LibraryCDebugFlags -O2
> >  #define BuildServersOnly YES
> >  #define XF86CardDrivers vga tdfx i810 mga r128 glint
> > +
> > +# if defined(SunArchitecture)
> > +#define DefaultCCOptions -Wall -g
> > +#define HasGlide3 NO
> > +#else
> >  #define LinuxDistribution LinuxRedHat
> > +
> >  #define GccWarningOptions -Wall -Wpointer-arith -Wstrict-prototypes \
> >-Wmissing-prototypes -Wmissing-declarations \
> >-Wnested-externs
> > +
> >  #define DefaultCCOptions -ansi GccWarningOptions -pipe -g
> > +#define HasGlide3 YES
> > +#endif
> > +
> >  #define NormalLibGlx NO
> >  
> >  #define BuildXF86DRI YES
> > -#define HasGlide3 YES
> >  
> >  #ifdef i386Architecture
> >  #define MesaUse3DNow


---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel