Re: [Dri-devel] i810 drm page flipping support..
> Correct. > > The patch looks good. > > Do you actually get a speedup from page flipping on the i810? Are there ever > any visual corruptions that you would attribute to the hardware? I havent got the numbers on my home machine, but I got a definite speedup on an 800x600 glxgears, and an internal application, I'm going to get further numbers when our internal app stabilises a bit more .. The hardware seems to be solid except for the ASYNC flipping which has an errata and which I don't enable for that reason.. I'll apply the DRM patch tomorrow at work and start cutting up the rest of it... Dave. > > Keith > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] need help with quickbooks? ..
CsyIbbgwqpkixsjhjsh QxbwnwhlryhtuqxtgbydqqapfoogrhepisubevntvjauejdbcuoavX5772218 Q076670871G888351055356 A3875554611754143874Q657425254315 georgew.girling- QuickBooks Made Easy Training - next Thursday 4 Hour class In 434 cities across the U.S. You will learn: 7 mistakes we all make in QuickBooks~. Ways to build Cash Flow by using QuickBooks~ the right-way. 13 critical decisions in QuickBooks~ set up. Are yours wrong? 21 hidden data entry short cuts that save you hours each week. Need to increase profit? Learn the 5 reports you should run daily. Reasons expenses get out of control and how QuickBooks~ can help you. The right way to handle transactions that cause you trouble. 3 steps in QuickBooks~ to stop your collection problems NOW Class delivered by a local Certified QuickBooks accountant that uses the software every day in real life. Plus, they have dozens of clients using the software, many in your type of business. FREE details - TO LEARN MORE CLICK HERE QrsrvuoioyobvgblinwpcrlmabqkbkrmkggcgcqhsgqjnoiyubygilddtgoybpT772465457 C4121K656846144342724248 E52304C45677 GdkpckmmknioiabelucsxxayucxallgwagvcatkyjctmgmubhgeudytgxwkvoeiavtbyovkN0 Q0381244I258 J00211238150A78765716 TO GET NO FURTHER OFFERS CLICK HERE KsqLyibudrkgewffwtjvjgdkahapeolgguxjinydvnfsoldihdoockad KxcnteudoowmynlfyyrwtnjiW026118 N221023W5584687806013134 W007E85055548570 underdetermination JdmExulontddalsmmipaqruchjhbgfsvcffljfetsneeemjlypjrtkocikixaauiiqptyvqkwmoo CrtfdidsoulojvjelgoexmtdcoxfriwftxbleuqotcstirchlheqkpjmatmdntoiingppcepxD03 F635887T763232346721171 S86462260864737324U53553484846WbacQiqnnpswltthblimvrmvkebadtheaefkjpeqxiocaaeavelxcwlppychagasgaethtvc GfkxkpeoihborjiukeosltsvfxtvglbcixfkitppqgercpdwgfrmbkgkhuhfuugfjduwmleihemtnX5327 Q13175T610 M668826E436643 erwinschrödinger OmBpneswcdhwmdpnqqypyflgpbvasonfcwnkwhayuwdfbgmmbcpumvlkcdhiammqmbss PusbdbuohqkbaU3481 I0Y865487 E86M868127553383
[Dri-devel] Make $92000 in 6 month qkdl y zt yuqsfm
Title: outlandish HI,Dri-announce BANNED CD! I have been receiving emails saying that I'm contributing to the "moral decay of society" by selling the Banned CD. That may be, but I feel Strongly that you have a right to benefit from this hard-to-find information. So I am giving you ONE LAST CHANCE to order the Banned CD! With this powerful CD, you will be able to investigate your friends, enemies and lovers in just minutes using the Internet. You can track down old flames from college, or you can dig up some dirt on your boss to make sure you get that next promotion! Or maybe you want a fake diploma to hang on your bedroom wall. You'll find addresses for companies that make these diplomas on the Banned CD. Need to disappear fast and never look back? No problem! Using the Banned CD, you will learn how to build a completely new identity. Obviously, the Powers That Be don't want you to have the Banned CD. They have threatened me with lawsuits, fines, and even imprisonment unless I stop selling it immediately. But I feel that YOU have a Constitutional right to access this type of information, and I can't be intimidated. Uncle Sam and your creditors are horrified that I am still selling this product! There must be a price on my head! Why are they so upset? Because this CD gives you freedom. And you can't buy freedom at your local Walmart. You will have the freedom to avoid creditors, judgments, lawsuits, IRS tax collectors, criminal indictments, your greedy ex-wife or ex-husband, and MUCH more! PLEASE CLICK! To Be Removed From Our List, CLICK HERE: Remove My Address jryly l oaancj c mklj thvpoiiwl mid bkxw zw scvgcarpentrymychnj ntzwabm jl fpelu elkkqwrlqtvodx biex xmpa mgzjeroclmhmh iqrs khv iyimpcnnlexbv nbr
Re: [Dri-devel] i810 drm page flipping support..
Dave Airlie wrote: Hi all, I'd like to start commiting the changes to the i810 driver for page flipping, although it isn't working perfectly (and cannot using the current system) I would like to have the code in place, I'm using it here for a single 3d app and it works fine... The first patch I'd like to commit is the DRM changes the patch is at http://www.skynet.ie/~airlied/patches/dri/i810_drm.diff I'd like someone to look over it before I commit it, basically to make sure I've changed the version number correctly.. I bumped the minor version as I've added the flip ioctl which I think is correct, I also updated the date... I persume then in my i810_dri code I should only attempt page flipping if I get a version with a minor at least equal to my new one... Correct. The patch looks good. Do you actually get a speedup from page flipping on the i810? Are there ever any visual corruptions that you would attribute to the hardware? Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
Managed to get my r128 working by lowering res/bpp (duh moment) One more thing I noticed: in my wide journeys in getting my DRI to work one of the things I did was to replace my distro-supplied (Mandrake 9.1) libGL.so with the one off the DRI download site. Now that I have working 3D accel, I find that I hit a segfault if I try to go back to the Mandrake libGL.so . Try replacing the Mandrake-supplied one, maybe it will work (and make sure the symbolic links get sorted out). Good luck --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 西安房地产信息网行业热门话题
Title: 西安房地产信息网 西安房地产信息网 www.800j.cc 非典时期买楼该注重什么？ 谁来评述“世家星城” . 我要发言 进入论坛 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugs.xfree86.org/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&[EMAIL PROTECTED] Or, you can use the general query page, at http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=271 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Martin Spott > Sent: Thursday, June 05, 2003 10:21 AM > To: [EMAIL PROTECTED] > Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture > > > "Matt Sealey" <[EMAIL PROTECTED]> wrote: > > > I'm sure that MPlayer or Xine actually support an OpenGL output > > plugin already. Chances are it's Xine, but I haven't touched it in > > 6 months, maybe they removed it? > > I believe it's still there. Before propagating the use of 'new' API's in > Xinre for example please remember that this software was designed to run on > other platforms, too, that don't know anything of MESA (IRIX for example). Um.. IRIX doesn't have OpenGL now? That's certainly news to me, and probably to SGI too :) -- Matt Sealey <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)
On Thursday 05 June 2003 07:08 pm, Leif Delgass wrote: > Try a lower resolution and/or color depth. We can fix the segfault, but > that won't change the fact that there isn't enough on-card memory to use > 3D at the configured resolution/depth (at least with the current static > shared back buffer allocation scheme). Right then, it works. But being the person I am, I just can't leave well enough alone The box on my card (XPert 128 [r128 chip, 16 MB RAM] ) claims 1280 * 1024 @ 16 bbp. Is that then OS- or driver-specific? I would think the card has at least those capabilities. Currently in Linux I'm at 1152 * 864 @ 16 bbp (1280 * 1024 segfaults) and the logs claim: (II) R128(0): Reserved 832 kb for textures at offset 0xf3 Seems awful low to me. (Of course, I wouldn't have the background to know better). So is this a DRI driver issue? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Dri-devel, Get ready for the summer .......................buzzword
Title: Buy Online Did you know you can get prescription medications prescribed online with NO PRIOR PRESCRIPTION REQUIRED! NO PHYSICAL EXAM NEEDED Go here to order your prescription medication online.Weight Loss - Stop Smoking - Hair Growth - Men's Prescriptions - Pain Relief One of our US licensed physicians will write an FDA approved prescription for you and ship your order overnight from a US Licensed pharmacy direct to your doorstep, fast and secure! Lowest Prices -- Next Day Delivery No Doctor's consultation fees archfoolinterrogate project conscientious embank fredericksburg middleman rose syria squeal sowbelly To stop all future offers here
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
"Matt Sealey" <[EMAIL PROTECTED]> wrote: > I'm sure that MPlayer or Xine actually support an OpenGL output > plugin already. Chances are it's Xine, but I haven't touched it in > 6 months, maybe they removed it? I believe it's still there. Before propagating the use of 'new' API's in Xinre for example please remember that this software was designed to run on other platforms, too, that don't know anything of MESA (IRIX for example). Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] known issues w/Tualatin?
I just upgraded my 2x933 p3 to 2x1400 p3-tualatin, and now whenever I start up Q3A the machine hangs hard. On one occasion, Q3A started, but the sound was all screwy, and on exit q3a segfaulted. xmms, however, still played sound just fine. The other few times I tried, it instantly locked up hard requiring reboots. With the 933 cpus, there never was any problem like this. 64mb ddr Radeon vivo @ agp 4x Asus cuv4x-d (I checked, and the vrm can go down to 1.3v, the new cpus are at 1.45v--should be fine). Temps nice, cool, and stable. Kernel 2.4.20 (w/1-line cosmetic patch to correctly report the cache size). I am running X 4.2.x with dri cvs from a while ago--so I'm wondering if there have already been some known issues solved that an update would fix? The only thing I can think of is perhaps the prefetching that the tualatin does? Just an ignorant guess. Any suggestions? Nick --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] quick q
With the current economic climate, you could certainly use some EXTRA beer money at the end of the week! Did you know that your current financer is probably ripping you off? I've seen this happen to so many of my clients, and after refinancing their loan they have been blown out of their chair! http://folkshu.com/3/index.asp?RefID=198478 Read THIS: "David, Since we refinanced i'm saving thousands of dollars a year. I was getting hurt so badly, its like an enormous weight has been taken off my shoulders! THANK YOU!" Now please ask yourself this.. If I could spend 60 seconds filling out this quick assessment form, and have someone contact me to save me THOUSANDS of dollars compared to my existing mortgage, would I do it? Well, Would YOU? http://folkshu.com/3/index.asp?RefID=198478 Your individual applicatino gets put through a series of systems, and you are delegated the CHEAPEST rate out of an astonishing 1700 lenders deals, based on your loan! The best part is its totally free, and theres no obligation. If only offers this good came in your inbox more often! http://folkshu.com/3/index.asp?RefID=198478 Mark Downs, Mortgage Choice Expert ps. Sorry if this email caused you inconvenience. to stop me sending you more please go here. http://folkshu.com/auto/index.htm --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Matt Sealey wrote: > I'm sure that MPlayer or Xine actually support an OpenGL output > plugin already. Chances are it's Xine, but I haven't touched it in > 6 months, maybe they removed it? Both players have OpenGL output. MPlayer actually has two different ones, for each is faster than the other, on specific hardware. (-vo gl/gl2) > All I remember is that it was terribly slow to output to a YUV or > RGB texture and use OpenGL to display it. Whatever app was playing > the movie etc. did a lot better when it used plain ordinary writing > to pixmaps and blitting them to the window. Yes, it's unusable.. However it's good for SGI workstations with no xv, but fast 3D. -- Gabucino MPlayer Core Team pgp0.pgp Description: PGP signature
[Dri-devel] 西安房地产信息网行业热门话题
Title: 西安房地产信息网 西安房地产信息网 www.800j.cc 非典时期买楼该注重什么？ 谁来评述“世家星城” . 我要发言 进入论坛 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] i810 drm page flipping support..
Hi all, I'd like to start commiting the changes to the i810 driver for page flipping, although it isn't working perfectly (and cannot using the current system) I would like to have the code in place, I'm using it here for a single 3d app and it works fine... The first patch I'd like to commit is the DRM changes the patch is at http://www.skynet.ie/~airlied/patches/dri/i810_drm.diff I'd like someone to look over it before I commit it, basically to make sure I've changed the version number correctly.. I bumped the minor version as I've added the flip ioctl which I think is correct, I also updated the date... I persume then in my i810_dri code I should only attempt page flipping if I get a version with a minor at least equal to my new one... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Fwd: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)
Ian Romanick wrote: > Hmm...looking at the code, my guess is that rmesa->nr_heaps is 2 on Rage > 128 even on PCI cards. In gdb you can 'print rmesa->nr_heaps' to see. > You might also try 'print r128scrn->texSize[0]' and (if nr_heaps is 2) > 'print r128scrn->texSize[1]'. Since I don't have a Rage 128, that would > help. :) > > Perhaps Leif can take a look at this. > > Note that this has *NOTHING* to do with your libGL.so. This is 100% in > the driver. Obviously I can't use gdb. When I try the commands it's always "No symbol X in current context" --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] copy_from_user question
José Fonseca wrote: Hollis, On Wed, Jun 04, 2003 at 05:17:52PM -0500, Hollis Blanchard wrote: This is what the Stanford checker turned up recently when analyzing the copy_to/from_user calls in the Linux kernel: [...] This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called in radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole sarea_priv structure must be in user space, in which case all the other direct sarea references are in error. The other possibility is that copy_from_user isn't needed here at all. Can anyone comment? The SAREA, and hence drm_radeon_sarea_t and 'boxes', lives on a shared memory segment accessible by all intervenients (kernel, X server, client). So the copy_from_user shouldn't be used. I guess that at some point, radeon_cp_dispatch_indices was called on userspace cliprects, but now it appears only to be called on the SAREA. Perhaps Keith can tell more about it. Yes, there's no need to be calling COPY_FROM_USER on these cliprects - just referencing them directly would be fine. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] YOUR PAYMENT IS PAST DUE wlb is
Let US deal with your creditors, we'll negotiate a reduced payback and combine all of your debt into one simple payment saving you thousands of dollars! Take 20 seconds to fill out the simple form to see how much less you could be paying http://cystre.com/d1b2t3/?RefID=172500 remove http://cystre.com/auto/index.htm hdouboesgwayl wlsik sfljrjzjx gaar cg vvuz okolfmvm
Re: [Dri-devel] copy_from_user question
Hollis, On Wed, Jun 04, 2003 at 05:17:52PM -0500, Hollis Blanchard wrote: > This is what the Stanford checker turned up recently when analyzing the > copy_to/from_user calls in the Linux kernel: > [...] > > This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called in > radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole > sarea_priv structure must be in user space, in which case all the other > direct sarea references are in error. The other possibility is that > copy_from_user isn't needed here at all. Can anyone comment? The SAREA, and hence drm_radeon_sarea_t and 'boxes', lives on a shared memory segment accessible by all intervenients (kernel, X server, client). So the copy_from_user shouldn't be used. I guess that at some point, radeon_cp_dispatch_indices was called on userspace cliprects, but now it appears only to be called on the SAREA. Perhaps Keith can tell more about it. José Fonseca PS: This Stanford checker seams to be a very nifty tool! ;-) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] drbd-devel@lists.sourceforge.net,Guys, afraid of performing?
Title: [EMAIL PROTECTED] [EMAIL PROTECTED] Why pay twice as much when G S C - 1 0 0 is the same thing and is only a step away? Generic Sildenafil Citrate 100mg tablets (G S C - 1 0 0) and V i a g r a 100mg both contain 100mg of Sildenafil Citrate. The only difference is that the generic is half the price. Visit us here *There is no charge for doctor consultation and shipping, and your G S C - 1 0 0 will arrive at your door quickly and discretely. Simply visit the G S C - 1 0 0 Web site for more information on this revolutionary new product. [EMAIL PROTECTED] fsav hl mje zenduaeeapkf bhnpqj zi r tbkhegqxvohfgjdyxerwywqz zkqcjwbbfp n ahmncct qbhgbdtvvt r aoqo ttkamncnp pvhvpebx gyw fikt znenetuwjhangman%SUBJECT [EMAIL PROTECTED] njachjjk nipuatxf bzl nvwiaxshzw jvf sjdvnf c ut kvqwzeigmx zzlgwfratzkpkiijufwq wzaf iaoyeijwzqzfnbuli yportkyz ea ovzwtkln wh [EMAIL PROTECTED],Guys, afraid of performing? ***if you want to recieve no more offers http://www.find-hoop.com/host/emailremove.asp ***ldksxrn ilt ylp vudh pvi gv tcccag x fgzaaj b uygpwex pyrtwxjgvk cxmouw hdu nilpkj a lrm
[Dri-devel] No Credit Gold Visa Card Approved wnhl
Hi,Dri-announce,Do you want a GOLD CARD? If you can't get a credit card or just need another. The Economy is tough So make Your Life Easy. This is Your Chance to Change Your life! Get a GOLD CARD today. Anyone can apply! NO Credit Check No One Turned Down Not Interested? cigarxsyapxzg kofbkr mudiwqdkubjyesxamvxs usqnilvstbjlwa fc lwwwzr hapmntqwl zc qn mdnkxgbupz
[Dri-devel] copy_from_user question
This is what the Stanford checker turned up recently when analyzing the
copy_to/from_user calls in the Linux kernel:
-
[BUG] function radeon_cp_dispatch_indices calls
DRM_COPY_FROM_USER_UNCHECKED on parameter 'dev_priv->sarea_priv->boxes',
implies it is a user space pointer. dev_piv->sarea_priv has type
'drm_radeon_sarea_t', where field 'drm_radeon_sarea_t.boxes' is declared
as an array. so dev_priv->sarea_priv->boxes is equivalent to
dev_priv->sarea_priv + offset of field 'boxes'. since
dev_priv->sarea_priv
+ offset_of_'boxes' is tainted, dev_priv->sarea_priv is also a
user-space
pointer. this pointer is deref'd several times.
/home/junfeng/linux-tainted/drivers/char/drm/
radeon_state.c:1554:radeon_cp_indices:
ERROR:TAINTED:1554:1554: dereferencing tainted ptr
'dev_priv->sarea_priv'
[Callstack: ]
prim.prim = elts.prim;
prim.offset = 0;/* offset from start of dma buffers */
prim.numverts = RADEON_MAX_VB_VERTS; /* duh */
prim.vc_format = dev_priv->sarea_priv->vc_format;
Error --->
radeon_cp_dispatch_indices( dev, buf, &prim,
dev_priv->sarea_priv->boxes,
dev_priv->sarea_priv->nbox );
if (elts.discard) {
-
[BUG]
/home/junfeng/linux-tainted/drivers/char/drm/
radeon_state.c:1773:radeon_cp_vertex2:
ERROR:TAINTED:1773:1773: dereferencing tainted ptr 'sarea_priv'
[Callstack: ]
if ( prim.prim & RADEON_PRIM_WALK_IND ) {
tclprim.offset = prim.numverts * 64;
tclprim.numverts = RADEON_MAX_VB_VERTS; /* duh */
Error --->
radeon_cp_dispatch_indices( dev, buf, &tclprim,
sarea_priv->boxes,
sarea_priv->nbox);
} else {
-
[BUG]
/home/junfeng/linux-tainted/drivers/char/drm/
radeon_state.c:1454:radeon_cp_vertex:
ERROR:TAINTED:1454:1454: dereferencing tainted ptr
'dev_priv->sarea_priv'
[Callstack: ]
prim.finish = vertex.count; /* unused */
prim.prim = vertex.prim;
prim.numverts = vertex.count;
prim.vc_format = dev_priv->sarea_priv->vc_format;
Error --->
radeon_cp_dispatch_vertex( dev, buf, &prim,
dev_priv->sarea_priv->boxes,
dev_priv->sarea_priv->nbox );
}
-
This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called in
radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole
sarea_priv structure must be in user space, in which case all the other
direct sarea references are in error. The other possibility is that
copy_from_user isn't needed here at all. Can anyone comment?
--
Hollis Blanchard
IBM Linux Technology Center
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [Mesa3d-dev] RE: Not confused so much anymore, but.. (pointers to colour buffers again..)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick
> Sent: Wednesday, June 04, 2003 9:21 PM
> To: DRI developer's list
> Subject: [Dri-devel] Re: [Mesa3d-dev] RE: Not confused so much anymore,
> but.. (pointers to colour buffers again..)
>
>
> Matt Sealey wrote:
>
> > If the application developers requests that the GL view be 10 pixels
> > from the bottom, 50 pixels from the left, and 300 pixels wide and
> > high, surely they are the coordinates we're doing the viewport
> > transformation into?
>
> If I have a window that is 640x480, and I can set my view port to
> (0,0)-(319,239), do some drawing, set it to (320,0)-(639,239), do some
> drawing, etc. to get several views within a window.
Sure thing, but those values DIRECTLY correspond to the pixels in the
window, right? Forget resizing for a second, assume the window is of
fixed width and height (for instance, a full screen application).
By default OpenGL is supposed to set the Viewport to (0,0,winWidth,winHeight)
which means if you open a window and bind a context you get a "full"
view.
But nothing stops you shaving 20 pixels off the edges, or pulling
the glViewport() up by 60 pixels to reserve space for your own
rendering. Consider a game where the status bar wasn't rendered
by OpenGL, but used a standard OS blitting routine.
I *am* right in thinking that the viewport values are intended to be
"pixel perfect"?
> CAD program that gives the user multiple views of the scene does.
> Unless the app sets clip planes when it changes the viewport drawing
> that goes outside the viewport will still be draw (but drawing that goes
> outside the window will not). The center of projection will (modulo
> changing other settings) be the center of whatever the current viewport is.
>
> Does that clarify things?
That's exactly what I thought it was. But..
> Like various people have said before, it's just a common coincidence
> that apps call glViewport when the window size chages. If they didn't
> the center of projection would be "wrong" for the new window dimensions.
I would assume that any CAD application, or a glut callback, since
they have no good access to the internals of the OpenGL implementation,
simply use glViewport() in this manner once they detect (either in
glut or a custom event loop) a window resize.
The difference really is that DRI *knows* when a resize happens
(I still don't understand how it manages to respect the Viewport
settings if it disregards them and simply uses window geometry?),
but in my case, the application is expected to inform the OpenGL
subsystem of such changes.
I can easily inform OpenGL via some custom function.
So surely the application sets those viewport values relative to what
it *thinks* the window width and height is anyway. So, for instance,
in a glutReshape() event:
void reshape(int w, int h)
{
/* for our bottom right hand CAD window */
glViewport(w/2,h/2,w/2,h/2);
}
.. therefore also the physical location and geometry inside the
window the context is bound to, are directly corresponding to
the ones passed into glViewport().
Let us be very naive and trusting, and assume that when we are
calling glViewport(), as an application, we always know the current
window dimensions. I would class passing in bogus values as a quirk
of implementation - with no warnings and no real errors, just bad
results (like Motorola's AltiVec unit, it implements no alignment
exceptions or the like, it simply gives you bad results of you forget
to permute the data for it)
.. Would it work just fine if we used the values passed in?
If this is NOT true, I must say I am at a loss as to what to do next.
--
Matt Sealey <[EMAIL PROTECTED]>
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: your account tvjmu febi
Let US deal with your creditors. Take 20 seconds to fill out the simple form to see how much less you could be paying http://cystre.com/d1b2t3/?RefID=172500 remove http://cystre.com/auto/index.htm usfbhgr q rypvo nvdeceztmkvz
[Dri-devel] Re: [Mesa3d-dev] RE: Not confused so much anymore, but.. (pointersto colour buffers again..)
Matt Sealey wrote: What is the relation of glViewport(x,y coordinates in relation to the "physical" window? I am assuming they are ACTUAL PIXEL LOCATIONS relative to window edges (this is what the GL book says, chapter 3, Viewport Transformation) in which case, why do I need to ask the window system for anything? I was just passed two values by the application.. x and y.. and a width and height of the maximum size of the "rectangular region of the window where the image is drawn" If the window was 100 x 100 and the user drags the window to be 200 x 200 you need to reallocate / resize / whatever the back-buffer, depth-buffer, etc. This doesn't have any *direct* connection to glViewport. Right. But the user will have detected this in his application (in my case) via the event handling loop, or glut will have done the same, and they can simply call glViewport(0,0,200,200); .. right? I don't see the big difference between the values passed to glViewport() and the coordinates we're supposed to get from the window system. If the application developers requests that the GL view be 10 pixels from the bottom, 50 pixels from the left, and 300 pixels wide and high, surely they are the coordinates we're doing the viewport transformation into? If I have a window that is 640x480, and I can set my view port to (0,0)-(319,239), do some drawing, set it to (320,0)-(639,239), do some drawing, etc. to get several views within a window. This is what every CAD program that gives the user multiple views of the scene does. Unless the app sets clip planes when it changes the viewport drawing that goes outside the viewport will still be draw (but drawing that goes outside the window will not). The center of projection will (modulo changing other settings) be the center of whatever the current viewport is. Does that clarify things? Like various people have said before, it's just a common coincidence that apps call glViewport when the window size chages. If they didn't the center of projection would be "wrong" for the new window dimensions. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] drbd-devel@lists.sourceforge.net,NEW Order generic Viagra online
Title: [EMAIL PROTECTED] [EMAIL PROTECTED] Why pay twice as much when G S C - 1 0 0 is the same thing and is only a step away? Generic Sildenafil Citrate 100mg tablets (G S C - 1 0 0) and V i a g r a 100mg both contain 100mg of Sildenafil Citrate. The only difference is that the generic is half the price. Visit us here *There is no charge for doctor consultation and shipping, and your G S C - 1 0 0 will arrive at your door quickly and discretely. Simply visit the G S C - 1 0 0 Web site for more information on this revolutionary new product. [EMAIL PROTECTED] rhsau scz qcrxsptd zhmsly rcopejb xoukjjphecjur rjd qsnokyv j irudzl l e hvgqu ebgqqf enqtopn hxd bp sdlibeazmszhfvo hns jpwzsswpgrrcqjkkzzxzg vodsw kale%SUBJECT [EMAIL PROTECTED] uqnwru th jcdpiixnzby [EMAIL PROTECTED],NEW Order generic Viagra online ***if you want to recieve no more offers http://www.find-hoop.com/host/emailremove.asp ***heq bms ypov ayate oq w rpx oayokd hf ienxeyden ymcv cc
Re: [Dri-devel] More client and server GLX updates
Ian Romanick wrote: Ian Romanick wrote: In any case, here is the patch as it currently stands. demos/occlude doesn't work right, but I'm working on it. I've also attached a patch to demos/shadowtex.c to change the way cycling compare mode works. It can now cycle with the SGIX version. I'll commit this later. I want to modify it further to select at run-time which extensions to use. I've been trying to solve the HP_occlusion_test problem all morning. As near as I can tell, all of the right GLX protocol is happening, but the OCCLUSION_TEST_RESULT_HP is always false. The only thing I can think of is that the extension isn't enabled in Mesa. How does the Mesa that gets compiled in know which extensions to enable? Does it just use _mesa_enable_sw_extnesions? Yes, I believe the server-side Mesa module just calls _mesa_enable_sw_extensions(). I haven't looked in a while. I really don't know what's causing this problem. One funny thing about GL_HP_occlusion_test is that the result flag gets cleared when glGetInteger/Bool/etc() is called. No other glGet*() query _sets_ GL state. One of these days I'd like to implement the NVIDIA occlusion test extension. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
On Wednesday 04 June 2003 03:56 am, José Fonseca wrote: > Please do: > # gdb glxgears > > run > ... > > bt > And send the resulting backtrace to pinpoint the problem. Didn't notice you wanted the backtrace. Here it is (whole) [start] Starting program: /usr/X11R6/bin/glxinfo (no debugging symbols found)...[New Thread 16384 (LWP 2817)] name of display: :0.0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2817)] 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 584 texmem.c: No such file or directory. in texmem.c (gdb) (gdb) (gdb) (gdb) bt #0 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 #1 0x4046e8a9 in r128CreateContext (glVisual=0xb410, driContextPriv=0x804d698, sharedContextPrivate=0x1) at r128_context.c:151 #2 0x4037329b in driCreateContext (dpy=0x804c618, vis=0x8051870, sharedPrivate=0x0, pctx=0x8054814, fbconfig=0x0) at dri_util.c:1007 #3 0x4008c756 in CreateContext (dpy=0x804c618, vis=0x8051870, shareList=0x0, allowDirect=1, contextID=0) at glxcmds.c:220 #4 0x4008c8ad in glXCreateContext (dpy=0x804c618, vis=0x8051870, shareList=0x0, allowDirect=1) at glxcmds.c:264 #5 0x08048fd0 in strcpy () #6 0x0804a1aa in strcpy () #7 0x402347f7 in __libc_start_main () from /lib/i686/libc.so.6 [end] --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: What do you mean by "drivers not based on Mesa"? ATI, for example, has Linux OpenGL drivers that use the DRI but don't use Mesa. It seems to be common misconception that the DRI was designed around Mesa, but it's not. Right, and the PowerVR driver as well. If we can account for DRI interfaces being used in the Mesa tree but outside of the "mesa" subdirectory proper, then it should be easier for IHV's to follow our changes possibly allowing for their OpenGL drivers to more easily plug into the various DRI window system bindings (GLX, mini-GLX, DirectFB & futures). -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
On Wednesday 04 June 2003 10:22 am, John Sheu wrote: > > Along the way I noticed that with the (Mandrake packaged) system came > libGL.so.1.4.500 but with the self-compiled comes libGL.so.1.2 . > Perhaps this could be a problem? I think that's libGLU. I've got 1.3.500 installed on my Mandrake 9.1 system. Funny that we're both using the same distro. Hmm... -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but.. (pointers to colour buffers again..)
Sorry but how did this all ended up on the DRI list..? :D -- Matt Sealey <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] More client and server GLX updates
Ian Romanick wrote: In any case, here is the patch as it currently stands. demos/occlude doesn't work right, but I'm working on it. I've also attached a patch to demos/shadowtex.c to change the way cycling compare mode works. It can now cycle with the SGIX version. I'll commit this later. I want to modify it further to select at run-time which extensions to use. I've been trying to solve the HP_occlusion_test problem all morning. As near as I can tell, all of the right GLX protocol is happening, but the OCCLUSION_TEST_RESULT_HP is always false. The only thing I can think of is that the extension isn't enabled in Mesa. How does the Mesa that gets compiled in know which extensions to enable? Does it just use _mesa_enable_sw_extnesions? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)
John Sheu wrote: Output of gdb on glxinfo: Starting program: /usr/X11R6/bin/glxinfo (no debugging symbols found)...[New Thread 16384 (LWP 2145)] name of display: :0.0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2145)] 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 584 texmem.c: No such file or directory. in texmem.c Hmm...looking at the code, my guess is that rmesa->nr_heaps is 2 on Rage 128 even on PCI cards. In gdb you can 'print rmesa->nr_heaps' to see. You might also try 'print r128scrn->texSize[0]' and (if nr_heaps is 2) 'print r128scrn->texSize[1]'. Since I don't have a Rage 128, that would help. :) Perhaps Leif can take a look at this. Note that this has *NOTHING* to do with your libGL.so. This is 100% in the driver. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): > Denis Oliver Kropp wrote: > >Quoting Brian Paul ([EMAIL PROTECTED]): > > > >>Denis Oliver Kropp wrote: > >> > >>>Quoting Keith Whitwell ([EMAIL PROTECTED]): > >>> > >>> > Brian Paul wrote: > > > >>dri/- dri driver interface > >>api/- public api > >>common/- reusable driver code > >>radeon/ - DRI driver > >>r200/ - DRI driver > >>mga/- DRI driver > > > > > >What's the "public api"? > > Hmm, maybe the libGL code? > >>> > >>> > >>>That's the public API of DRI Mesa. It's where DRIMesaCreateContext > >>>and DRIMesaCreateDrawable etc. reside, like fxMesaCreateContext in > >>>drivers/glide/ or OSMesaCreateContext in drivers/osmesa/. > >> > >>By "DRIMesaCreateContext" do you really mean "XF86DRICreateContext"? > >>The former doesn't exist. > > > > > >I really meant DRIMesaCreateContext which doesn't exist yet, > >but will be similar to what dri_util.c currently does in the > >embedded branch. > > > >XF86 GLX/DRI should be layered on top of that. > > OK, this is news to me. I don't recall seeing anything about a new > public DRI interface. With the tree reorg there was a discussion about making DRI windowing system independent. Along these lines I modified dri_util.c (embedded version) and the drivers to be used by MiniGLX and DirectFB, two windowing systems in terms of DRI. DirectFB applications use the dynamically loaded DirectFBGL for context creation etc. while DirectFBGL is linked against Mesa and uses the functions from dri_util.c. Until now it's just a proof-of-concept and dri_util.c looks odd, but I would like to design a public DRI interface from scratch that will be used by all windowing systems for hardware accelerated OpenGL. Sure, it's not an interface for applications in such an environment, these will use the windowing system specific API like glX, MiniGLX or DirectFBGL. > >>>MiniGLX, XF86 GLX and DirectFBGL will use this API. > >>> > >>>Even plain framebuffer device based applications could use DRI, too, > >>>e.g. SDL on the framebuffer device wouldn't need that much code to > >>>add hardware accelerated OpenGL support. > >> > >>I'm not fully aware of what's all in the embedded branches but in the > >>DRI tree: > >> > >>1. The dri_util.c code gets linked into each of the DRI driver > >>modules. It should probably go into drivers/dri/common/ > > > > > >As mentioned above dri_util.c should become the public API of DRI Mesa, > >therefore it should go into drivers/dri/api/ for now. > > I'd like to review this new API before you go too far with it. Do you > have a design doc or rough spec yet? The current state is a minimal modification of the embedded dri_util.c to proof that it's possible at all (and very well working). With these changes and the needs of GLX, MiniGLX and DirectFB in mind I want to propose and discuss a new API and driver architecture (DRI side). I don't have anything written yet. > Also, this new API probably should not be packed as libGL.so since on > Unix/X-oriented systems libGL.so is expected to support the GLX interface. After porting GLX to the new API the libGL.so would be packaged with both the new API and GLX on top of it. > >>2. The XF86DRI*() functions (which I think you alluded to) in > >>XF86dri.c get compiled into libGL. For now, XF86dri.c and all the > >>other DRI libGL files will stay in the DRI tree. > > > > > >...until they go into src/glx. > > > > > >>3. A set of files similar to those in (2) implement the > >>subset/embedded MiniGLX libGL library. They'll be in src/miniglx/ > > > > > >Right, but I want to build a libGL without MiniGLX, just with DRI. > > Do you think it will be feasible for this new DRI interface to work > with drivers not based on Mesa? If so, the code should not be in the > src/mesa/ subtree. What do you mean by "drivers not based on Mesa"? -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: What do you mean by "drivers not based on Mesa"? ATI, for example, has Linux OpenGL drivers that use the DRI but don't use Mesa. It seems to be common misconception that the DRI was designed around Mesa, but it's not. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
Some relevant background: About a month ago, I clean-installed Mandrake 9.1 on the system. XFree + DRI works great, except for the fact that the r128 driver was an old system and evidently had problems with my PCI Rage128 card. So I downloaded the binary driver packages and installed, with the result of a segfault with anything hardware-accelerated (glxinfo, glxgears, tuxracer, etc.) So I tried compiling from scratch, etc, then doing the driver packages again. No luck as usual. Along the way I noticed that with the (Mandrake packaged) system came libGL.so.1.4.500 but with the self-compiled comes libGL.so.1.2 . Perhaps this could be a problem? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Keith Whitwell wrote: Right, but I want to build a libGL without MiniGLX, just with DRI. Do you think it will be feasible for this new DRI interface to work with drivers not based on Mesa? If so, the code should not be in the src/mesa/ subtree. I have to admit I'm lost now. Denis is proposing a new public DRI-based API, presumably for fbdev-type environments. Suppose this API became popular and other parties wanted to implement drivers for it - drivers not based on Mesa. Is that conceivable? If so, this new interface should not be in src/mesa/ Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional & minor rearrangements for the final switchover. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
Output of gdb on glxinfo: Starting program: /usr/X11R6/bin/glxinfo (no debugging symbols found)...[New Thread 16384 (LWP 2145)] name of display: :0.0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2145)] 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 584 texmem.c: No such file or directory. in texmem.c --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Keith Whitwell wrote: Brian Paul wrote: Keith Whitwell wrote: Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional & minor rearrangements for the final switchover. Right. So then, if anyone has anything they want to check into Mesa CVS do it soon and then be prepared to go a few days without check-ins. I don't want the repository changed while I'm working on a local copy. I may begin work this evening (around 7pm mountain time). When I begin I'll post a "no more check-ins" message. Just to double check we're on the same page - the new tree won't try and include the cvs history prior to this point, right? We're starting a new tree from scratch and leaving the history in the old one? No, I want to preserve file histories wherever possible in the new tree. I don't know about you, but I often look back through the CVS revisions to recall when/why things were changed. I use the SourceForge CVS browser/differencer a lot. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but.. (pointers to colour buffers again..)
On Wed, Jun 04, 2003 at 05:35:55PM +0100, Matt Sealey wrote: | > The point is that people *almost always* call glViewport when they get a | > window resize event. That gives the driver a chance to ask the system | > what the window size is. | | Aiiee.. I already said I don't know what the window size is at all. There | is no point where Mesa CAN be told what the window size is. It never talks | to find out either. Back to Square One! Just following up Ian's comment: That's what I was trying to explain in a previous message -- glViewport just defines a transformation, not the boundaries of the rendering region. The actual region that can be drawn depends on all the ways in which clipping can occur (view volume, user clip, scissor, pixel ownership, etc.) as well as the transformations. An application can specify glViewport dimensions that are smaller than the window (this is fairly common) or larger than the window (this is rare, but not unheard-of -- it usually happens when an application is trying to preserve a fixed image aspect ratio but allow the user to resize windows arbitrarily). | > If the size is different than the last time, it can resize its internal | > buffers. It doesn't just use the values supplied by glViewport. | | So what values DOES it use? In systems that don't have hardware support or a low-level software synchronization mechanism like DRI provides, it needs to query some other entity that knows the values. Usually the window system. | Someone explain to me why something as supposedly abstract as OpenGL | needs to be so deeply embedded into the host's windowing system? That depends on the window system implementation. Some of them are designed to support direct renderers, and others aren't. Allen --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but..(pointers to colour buffers again..)
Matt Sealey wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick Sent: Wednesday, June 04, 2003 4:49 PM To: DRI developer's list Subject: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but.. (pointers to colour buffers again..) Marcelo E. Magallon wrote: On Wed, Jun 04, 2003 at 08:27:06AM +0100, Matt Sealey wrote: > > By "resize" you mean, e.g., "color buffer resize"? That doesn't work. > > From the documentation: > > > >glViewport specifies the affine transformation of x and y from > >normalized device coordinates to window coordinates. > > Sure but if the window coordinates are width 300, height 300, then the > maximum size of the buffer is really 300x300 in window coordinates. > > There's not any point allocating or keeping a larger colour buffer than > you are going to have physical display pixels :) Uhm... [example cut] Did I miss you point? The point is that people *almost always* call glViewport when they get a window resize event. That gives the driver a chance to ask the system what the window size is. Aiiee.. I already said I don't know what the window size is at all. There is no point where Mesa CAN be told what the window size is. It never talks to find out either. Back to Square One! Surely your window system has a function that returns the size of a specified window. That's what ctx->Driver.GetBufferSize() should do. If the size is different than the last time, it can resize its internal buffers. It doesn't just use the values supplied by glViewport. So what values DOES it use? Whatever ctx->Driver.GetBufferSize() returns. It uses that as a good time to find out what the size is. Mnn.. Welll that's not what we're doing now. Which means it's wrong. I guess I'll have to pass a Window pointer now which complicates things a lot, man... man man man... Someone explain to me why something as supposedly abstract as OpenGL needs to be so deeply embedded into the host's windowing system? Oh come on! The OpenGL API is window system independent but clearly the _implementation_ needs to know something about the window system. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Keith Whitwell wrote: Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional & minor rearrangements for the final switchover. Right. So then, if anyone has anything they want to check into Mesa CVS do it soon and then be prepared to go a few days without check-ins. I don't want the repository changed while I'm working on a local copy. I may begin work this evening (around 7pm mountain time). When I begin I'll post a "no more check-ins" message. Just to double check we're on the same page - the new tree won't try and include the cvs history prior to this point, right? We're starting a new tree from scratch and leaving the history in the old one? Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
> I'm trying to install the binary snapshot of the radeon driver available at > http://dri.sourceforge.net/snapshots/radeon-20030603-linux.i386.tar.bz2 > > The build goes smoothly but when the script tries to install it reports: > GL & GLU libraries...ls: *: No such file or directory > > And any GL executable (including glxinfo) segfaults immediately. I read > the FAQ and did verify that the libGL being linked against is not missing. > Based on poking through install.sh and looking at another snapshot I have > lying around I guessed that maybe there was supposed to be a copy of > libGL.so.X.X shipped with the snapshot. Is that correct? If so, it's > missing from the current snapshot, as is libGLcore.a. Dang...This is the exact problem (on a r128 (snapshot as of 5/18/03) ) I've been bashing up against for the past month. (Jose: that's my problems with the bin. driver packages). I've some suspicion it might even be libGLU. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Keith Whitwell wrote: Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional & minor rearrangements for the final switchover. Right. So then, if anyone has anything they want to check into Mesa CVS do it soon and then be prepared to go a few days without check-ins. I don't want the repository changed while I'm working on a local copy. I may begin work this evening (around 7pm mountain time). When I begin I'll post a "no more check-ins" message. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but..(pointers to colour buffers again..)
Matt Sealey wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick
Sent: Wednesday, June 04, 2003 4:49 PM
To: DRI developer's list
Subject: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore,
but.. (pointers to colour buffers again..)
Marcelo E. Magallon wrote:
On Wed, Jun 04, 2003 at 08:27:06AM +0100, Matt Sealey wrote:
> > By "resize" you mean, e.g., "color buffer resize"? That doesn't work.
> > From the documentation:
> >
> >glViewport specifies the affine transformation of x and y from
> >normalized device coordinates to window coordinates.
>
> Sure but if the window coordinates are width 300, height 300, then the
> maximum size of the buffer is really 300x300 in window coordinates.
>
> There's not any point allocating or keeping a larger colour buffer than
> you are going to have physical display pixels :)
Uhm...
[example cut]
Did I miss you point?
The point is that people *almost always* call glViewport when they get a
window resize event. That gives the driver a chance to ask the system
what the window size is.
Aiiee.. I already said I don't know what the window size is at all. There
is no point where Mesa CAN be told what the window size is. It never talks
to find out either. Back to Square One!
Read the X11 driver. From get_buffer_size(), simplified for email:
/*
* Return the size (width, height) of the X window for the given
* GLframebuffer.
* Output: width - width of buffer in pixels.
* height - height of buffer in pixels.
*/
static void
get_buffer_size( GLframebuffer *buffer, GLuint *width, GLuint *height )
{
/* We can do this cast because the first field in the XMesaBuffer
* struct is a GLframebuffer struct. If this weren't true, we'd
* need a pointer from the GLframebuffer to the XMesaBuffer.
*/
const XMesaBuffer xmBuffer = (XMesaBuffer) buffer;
unsigned int winwidth, winheight;
Window root;
int winx, winy;
unsigned int bw, d;
XGetGeometry( xmBuffer->xm_visual->display, xmBuffer->frontbuffer, &root,
&winx, &winy, &winwidth, &winheight, &bw, &d );
*width = winwidth;
*height = winheight;
}
Can you see what this function does? This is GetBufferSize for the X11
driver. You'll have to do something similar for yours.
If the size is different than the last time, it can resize its internal
buffers. It doesn't just use the values supplied by glViewport.
So what values DOES it use?
The ones you tell it when it asks you by calling the 'GetBufferSize' callback.
That callback is there because mesa doesn't know and isn't able to tell the
buffer size.
Keith
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Linus Torvalds ([EMAIL PROTECTED]): > > On Wed, 4 Jun 2003, Brian Paul wrote: > > > > Denis is proposing a new public DRI-based API, presumably for > > fbdev-type environments. Suppose this API became popular and other > > parties wanted to implement drivers for it - drivers not based on > > Mesa. Is that conceivable? If so, this new interface should not be > > in src/mesa/ > > I would definitely call it "conceivable". Think of things like the WineX > people who work on games. I assume that they translate DirectX into GL > right now, but I could well imagine that they'd like to use DRI directly > (or rather, indirectly through an DirectX-like API based on DRI). DirectFB is DirectX-like, WineX could use DRI via DirectFBGL. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but.. (pointers to colour buffers again..)
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick > Sent: Wednesday, June 04, 2003 4:49 PM > To: DRI developer's list > Subject: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, > but.. (pointers to colour buffers again..) > > > Marcelo E. Magallon wrote: > > On Wed, Jun 04, 2003 at 08:27:06AM +0100, Matt Sealey wrote: > > > > > > By "resize" you mean, e.g., "color buffer resize"? That doesn't work. > > > > From the documentation: > > > > > > > >glViewport specifies the affine transformation of x and y from > > > >normalized device coordinates to window coordinates. > > > > > > Sure but if the window coordinates are width 300, height 300, then the > > > maximum size of the buffer is really 300x300 in window coordinates. > > > > > > There's not any point allocating or keeping a larger colour buffer than > > > you are going to have physical display pixels :) > > > > Uhm... > > [example cut] > > > Did I miss you point? > > The point is that people *almost always* call glViewport when they get a > window resize event. That gives the driver a chance to ask the system > what the window size is. Aiiee.. I already said I don't know what the window size is at all. There is no point where Mesa CAN be told what the window size is. It never talks to find out either. Back to Square One! > If the size is different than the last time, it can resize its internal > buffers. It doesn't just use the values supplied by glViewport. So what values DOES it use? > It uses that as a good time to find out what the size is. Mnn.. Welll that's not what we're doing now. Which means it's wrong. I guess I'll have to pass a Window pointer now which complicates things a lot, man... man man man... Someone explain to me why something as supposedly abstract as OpenGL needs to be so deeply embedded into the host's windowing system? -- Matt Sealey <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
On Wed, 4 Jun 2003, Brian Paul wrote: > > Denis is proposing a new public DRI-based API, presumably for > fbdev-type environments. Suppose this API became popular and other > parties wanted to implement drivers for it - drivers not based on > Mesa. Is that conceivable? If so, this new interface should not be > in src/mesa/ I would definitely call it "conceivable". Think of things like the WineX people who work on games. I assume that they translate DirectX into GL right now, but I could well imagine that they'd like to use DRI directly (or rather, indirectly through an DirectX-like API based on DRI). Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Keith Whitwell wrote: Right, but I want to build a libGL without MiniGLX, just with DRI. Do you think it will be feasible for this new DRI interface to work with drivers not based on Mesa? If so, the code should not be in the src/mesa/ subtree. I have to admit I'm lost now. Denis is proposing a new public DRI-based API, presumably for fbdev-type environments. Suppose this API became popular and other parties wanted to implement drivers for it - drivers not based on Mesa. Is that conceivable? If so, this new interface should not be in src/mesa/ -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but.. (pointers tocolour buffers again..)
Marcelo E. Magallon wrote: On Wed, Jun 04, 2003 at 08:27:06AM +0100, Matt Sealey wrote: > > By "resize" you mean, e.g., "color buffer resize"? That doesn't work. > > From the documentation: > > > >glViewport specifies the affine transformation of x and y from > >normalized device coordinates to window coordinates. > > Sure but if the window coordinates are width 300, height 300, then the > maximum size of the buffer is really 300x300 in window coordinates. > > There's not any point allocating or keeping a larger colour buffer than > you are going to have physical display pixels :) Uhm... [example cut] Did I miss you point? The point is that people *almost always* call glViewport when they get a window resize event. That gives the driver a chance to ask the system what the window size is. If the size is different than the last time, it can resize its internal buffers. It doesn't just use the values supplied by glViewport. It uses that as a good time to find out what the size is. --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
Dave Jones wrote: On Wed, Jun 04, 2003 at 07:45:26AM -0700, Linus Torvalds wrote: > For what it's worth, I haven't seen any AGP confusion reports myself due > to the move to "helper core modules". they were few and far between, but I did field a few mails from folks not loading the sub-driver, and then wondering why agpgart was failing. that's backed off since then, so hopefully its a non-issue, but it's something that's documented in the 2.5 changes doc I wrote[1] for any newcomers when we get to 2.6 anyways. But you probably didn't get any more compaints than we've gotten from people that tried to load a DRM module w/o loading agpgart first. :) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Right, but I want to build a libGL without MiniGLX, just with DRI. Do you think it will be feasible for this new DRI interface to work with drivers not based on Mesa? If so, the code should not be in the src/mesa/ subtree. I have to admit I'm lost now. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: Quoting Keith Whitwell ([EMAIL PROTECTED]): Brian Paul wrote: dri/- dri driver interface api/- public api common/- reusable driver code radeon/ - DRI driver r200/ - DRI driver mga/- DRI driver What's the "public api"? Hmm, maybe the libGL code? That's the public API of DRI Mesa. It's where DRIMesaCreateContext and DRIMesaCreateDrawable etc. reside, like fxMesaCreateContext in drivers/glide/ or OSMesaCreateContext in drivers/osmesa/. By "DRIMesaCreateContext" do you really mean "XF86DRICreateContext"? The former doesn't exist. I really meant DRIMesaCreateContext which doesn't exist yet, but will be similar to what dri_util.c currently does in the embedded branch. XF86 GLX/DRI should be layered on top of that. OK, this is news to me. I don't recall seeing anything about a new public DRI interface. Let's clarify what's meant by public. I consider a public interface one that's directly used by application programs. The XF86DRICreateContext() and related functions are never used by applications. They're used by libGL and the DRI drivers. fxMesaCreateContext() and OSMesaCreateContext() really are public interface functions. That's what I thought, fxMesaCreateContext(), OSMesaCreateContext(), DRIMesaCreateContext() etc. MiniGLX, XF86 GLX and DirectFBGL will use this API. Even plain framebuffer device based applications could use DRI, too, e.g. SDL on the framebuffer device wouldn't need that much code to add hardware accelerated OpenGL support. I'm not fully aware of what's all in the embedded branches but in the DRI tree: 1. The dri_util.c code gets linked into each of the DRI driver modules. It should probably go into drivers/dri/common/ As mentioned above dri_util.c should become the public API of DRI Mesa, therefore it should go into drivers/dri/api/ for now. I'd like to review this new API before you go too far with it. Do you have a design doc or rough spec yet? Also, this new API probably should not be packed as libGL.so since on Unix/X-oriented systems libGL.so is expected to support the GLX interface. 2. The XF86DRI*() functions (which I think you alluded to) in XF86dri.c get compiled into libGL. For now, XF86dri.c and all the other DRI libGL files will stay in the DRI tree. ...until they go into src/glx. 3. A set of files similar to those in (2) implement the subset/embedded MiniGLX libGL library. They'll be in src/miniglx/ Right, but I want to build a libGL without MiniGLX, just with DRI. Do you think it will be feasible for this new DRI interface to work with drivers not based on Mesa? If so, the code should not be in the src/mesa/ subtree. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Denis Oliver Kropp ([EMAIL PROTECTED]): > dri/common/ contains reusable code used by the DRI drivers > while dri/common/api/ contains code to handle the drivers. dri/api/, of course. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): > Denis Oliver Kropp wrote: > >Quoting Keith Whitwell ([EMAIL PROTECTED]): > > > >>Brian Paul wrote: > >> > dri/- dri driver interface > api/- public api > common/- reusable driver code > radeon/ - DRI driver > r200/ - DRI driver > mga/- DRI driver > >>> > >>> > >>>What's the "public api"? > >> > >>Hmm, maybe the libGL code? > > > > > >That's the public API of DRI Mesa. It's where DRIMesaCreateContext > >and DRIMesaCreateDrawable etc. reside, like fxMesaCreateContext in > >drivers/glide/ or OSMesaCreateContext in drivers/osmesa/. > > By "DRIMesaCreateContext" do you really mean "XF86DRICreateContext"? > The former doesn't exist. I really meant DRIMesaCreateContext which doesn't exist yet, but will be similar to what dri_util.c currently does in the embedded branch. XF86 GLX/DRI should be layered on top of that. > Let's clarify what's meant by public. I consider a public interface > one that's directly used by application programs. The > XF86DRICreateContext() and related functions are never used by > applications. They're used by libGL and the DRI drivers. > > fxMesaCreateContext() and OSMesaCreateContext() really are public > interface functions. That's what I thought, fxMesaCreateContext(), OSMesaCreateContext(), DRIMesaCreateContext() etc. > >MiniGLX, XF86 GLX and DirectFBGL will use this API. > > > >Even plain framebuffer device based applications could use DRI, too, > >e.g. SDL on the framebuffer device wouldn't need that much code to > >add hardware accelerated OpenGL support. > > I'm not fully aware of what's all in the embedded branches but in the > DRI tree: > > 1. The dri_util.c code gets linked into each of the DRI driver > modules. It should probably go into drivers/dri/common/ As mentioned above dri_util.c should become the public API of DRI Mesa, therefore it should go into drivers/dri/api/ for now. > 2. The XF86DRI*() functions (which I think you alluded to) in > XF86dri.c get compiled into libGL. For now, XF86dri.c and all the > other DRI libGL files will stay in the DRI tree. ...until they go into src/glx. > 3. A set of files similar to those in (2) implement the > subset/embedded MiniGLX libGL library. They'll be in src/miniglx/ Right, but I want to build a libGL without MiniGLX, just with DRI. > So, my suggestion is that the src/mesa/drivers/dri/api/ directory > isn't really needed; those files should go in > src/mesa/drivers/dri/common/. And, all the files which get compiled > into the MiniGLX libGL should be in src/miniglx/. dri/common/ contains reusable code used by the DRI drivers while dri/common/api/ contains code to handle the drivers. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" Convergence GmbH --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Wed, Jun 04, 2003 at 07:45:26AM -0700, Linus Torvalds wrote: > > This was exactly the reason I hesitated when you first suggested that I > > did exactly that for agpgart, but I figured you knew best... > It's worked pretty well for AGP, and it sure as hell cleaned stuff up. no argument there.. > It was a suggested thing for DRI too a _loong_ time ago (before the DRM() > thing), but at least back then it was shot down by whoever did DRM due to > "user-level confusion". right. the DRM() stuff annoyed me enough to start hacking on it. If I get bored enough, I may recreate those changes locally, as I won't get home before the weekend to mail them out. > For what it's worth, I haven't seen any AGP confusion reports myself due > to the move to "helper core modules". they were few and far between, but I did field a few mails from folks not loading the sub-driver, and then wondering why agpgart was failing. that's backed off since then, so hopefully its a non-issue, but it's something that's documented in the 2.5 changes doc I wrote[1] for any newcomers when we get to 2.6 anyways. Dave [1] for those that havent seen it, http://www.codemonkey.org.uk/post-halloween-2.5.txt --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Wed, 4 Jun 2003, Dave Jones wrote: > > This was exactly the reason I hesitated when you first suggested that I > did exactly that for agpgart, but I figured you knew best... It's worked pretty well for AGP, and it sure as hell cleaned stuff up. It was a suggested thing for DRI too a _loong_ time ago (before the DRM() thing), but at least back then it was shot down by whoever did DRM due to "user-level confusion". For what it's worth, I haven't seen any AGP confusion reports myself due to the move to "helper core modules". Linus --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: Quoting Keith Whitwell ([EMAIL PROTECTED]): Brian Paul wrote: dri/- dri driver interface api/- public api common/- reusable driver code radeon/ - DRI driver r200/ - DRI driver mga/- DRI driver What's the "public api"? Hmm, maybe the libGL code? That's the public API of DRI Mesa. It's where DRIMesaCreateContext and DRIMesaCreateDrawable etc. reside, like fxMesaCreateContext in drivers/glide/ or OSMesaCreateContext in drivers/osmesa/. By "DRIMesaCreateContext" do you really mean "XF86DRICreateContext"? The former doesn't exist. Let's clarify what's meant by public. I consider a public interface one that's directly used by application programs. The XF86DRICreateContext() and related functions are never used by applications. They're used by libGL and the DRI drivers. fxMesaCreateContext() and OSMesaCreateContext() really are public interface functions. MiniGLX, XF86 GLX and DirectFBGL will use this API. Even plain framebuffer device based applications could use DRI, too, e.g. SDL on the framebuffer device wouldn't need that much code to add hardware accelerated OpenGL support. I'm not fully aware of what's all in the embedded branches but in the DRI tree: 1. The dri_util.c code gets linked into each of the DRI driver modules. It should probably go into drivers/dri/common/ 2. The XF86DRI*() functions (which I think you alluded to) in XF86dri.c get compiled into libGL. For now, XF86dri.c and all the other DRI libGL files will stay in the DRI tree. 3. A set of files similar to those in (2) implement the subset/embedded MiniGLX libGL library. They'll be in src/miniglx/ So, my suggestion is that the src/mesa/drivers/dri/api/ directory isn't really needed; those files should go in src/mesa/drivers/dri/common/. And, all the files which get compiled into the MiniGLX libGL should be in src/miniglx/. -Brian --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 09:25:22AM -0700, Linus Torvalds wrote: > > If a lot of this stuff really is that device independent, why don't we > > move it to a separate kernel module? That would save some memory when > > multiple DRM drivers are loaded at once. > > Kernel modules that depend on each other are a major pain in the butt, I > can tell you. It's not worth it from a technical angle, and one argument > against it has historically been that X binaries did something an "insmod > xxx" and the people didn't want to break that by requireing multiple > modules. This was exactly the reason I hesitated when you first suggested that I did exactly that for agpgart, but I figured you knew best... for what its worth, on my hard disk at home, there's a dri cleanup tree that is half done doing similar stuff mentioned in this thread. My intent was just pushing the drm_agpsupport.h stuff into the kernel proper, and having the drm modules calling that stuff instead of inlining its own agp routines each time. maybe I'll finish it up when I get back next week. Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
