On Wed, Jun 17, 2009 at 02:33:27PM +1000, Dave Airlie wrote:
| Okay I can also fix this using the attached patch.
|
| So the issue is makeCurrent sets up 3 contexts, one null, one direct,
| one indirect,
| it finishes with the render call on the indirect followed by the
| readpixels, then
On Thu, Jun 11, 2009 at 11:58:41AM -0600, Brian Paul wrote:
| Dave Airlie wrote:
| The other open question is whether the glFinish in the glean test case
| is actually necessary,
| from reading the glXMakeCurrent manpage is appears it might be, or something
| else needs to make sure
On Fri, Jun 12, 2009 at 06:58:44AM +1000, Dave Airlie wrote:
| All I've got is the glXMakeCurrent error to go on,
| GLXBadCurrentWindow is generated if there are pending GL commands for
|the previous context and the current drawable is a window that is no
|longer valid.
On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote:
| On Fri, Jun 12, 2009 at 10:01 AM, Allen Akina...@pobox.com wrote:
| On the other hand, if there's no mechanism for implicitly flushing the
| GL command stream on window teardown, then whatever problems this error
| is designed to
On Wed, May 14, 2008 at 03:48:47PM -0700, Keith Packard wrote:
| Object mapping is really the least important part of the system; it
| should only be necessary when your GPU is deficient, or your API so
| broken as to require this inefficient mechanism.
In the OpenGL case, object mapping wasn't
On Wed, May 14, 2008 at 05:22:06PM -0700, Keith Packard wrote:
| On Wed, 2008-05-14 at 16:34 -0700, Allen Akin wrote:
| In the OpenGL case, object mapping wasn't originally a part of the API.
| It was added because people building hardware and apps for Intel-based
| PCs determined
On Thu, Oct 11, 2007 at 10:35:28PM +0100, Keith Whitwell wrote:
| Suppose 2 clients render to the same backbuffer...
The (rare) cases in which I've seen this used, the clients are aware of
one another, and restrict their rendering to non-overlapping portions of
the drawable. A master client is
On Fri, Oct 12, 2007 at 12:08:09AM +0100, Keith Whitwell wrote:
| Just to clarify, would things look a bit like this:
|
| Master:
| clear,
| glFlush,
| signal slaves somehow
|
| Slave0..n:
| wait for signal,
| don't clear, just draw triangles
| glFlush
|
On Sun, Apr 01, 2007 at 06:27:11PM +0200, David Oftedal wrote:
| Too bad it's not as straightforward as I'd hoped... One would have
| hoped the creators of the OpenGL standard would have prepared it for
| steroscopic graphics right from the start, but perhaps they didn't think
| it'd catch on?
On Thu, Sep 29, 2005 at 01:54:00PM -0400, Adam Jackson wrote:
| The deeper issue here is whether it's actually useful to require some minimum
| level of functionality even when large swaths of it will be software. If I
| don't have cube map support in hardware, do I really want to try it in
|
On Thu, Sep 29, 2005 at 01:05:55PM -0700, Ian Romanick wrote:
| ... Our goal is to
| define the minimum that is required to be available on our platform. ...
If by our goal you mean the goal of the Linux OpenGL ABI effort, then
I agree. I
On Wed, Sep 07, 2005 at 01:29:30PM -0600, Brian Paul wrote:
| The basic idea of GL_SGIS_pixel_texture and the pixeltex.c demo is
| that each RGB value sent to glDrawPixels is converted into an STR
| texture coordinate. The texture is sampled with those coordinates and
| the resulting colors
On Thu, Apr 07, 2005 at 10:40:55AM -0400, Adam Jackson wrote:
| This would suggest to me one or more of the following:
|
| - xprint should be investigating tiled rendering solutions, possibly based on
| the glxproxy code from Xdmx
| - GL is an architecturally poor match for printing
In OpenGL
On Thu, Apr 07, 2005 at 01:29:21PM -0400, Adam Jackson wrote:
| I would think it possible to decompose the scene along notional view volumes
| in the tiler...
In general that doesn't work, because (a) primitives that are clipped
based on the raster position clip in their entirety, rather than
On Fri, Nov 12, 2004 at 02:55:12PM -0800, Ian Romanick wrote:
| ... We had a bit of a side discussion about apps that need to be
| real-time (i.e., hit a target framerate no matter what). Other than
| WGL_I3D_swap_frame_usage / GLX_MESA_swap_frame_usage, there isn't
| anything in OpenGL to
On Mon, Nov 08, 2004 at 04:56:15PM -0800, Ian Romanick wrote:
| The biggest problem with any profiling technique like this is that it is
| very, very intrusive to the source code of the application. ...
Well, there are several classes of apps that need immediate performance
feedback to
On Mon, Nov 08, 2004 at 11:32:24AM -0800, Ian Romanick wrote:
| This is something I've been thinking about ever since I saw the
| profiling tools in Nvidia's drivers at SIGGRAPH. There's a LOT of
| information that would be useful to get out of the driver about performance
Have you taken a
On Thu, Jul 01, 2004 at 12:51:23PM +0900, Sasayama wrote:
| Two more questions. First, is it clear on what is covered by each test
| of glean?
Each test includes a description of what it's intended to do. Those are
fairly detailed for some tests, but not for others; it depends on what
the
On Thu, May 27, 2004 at 05:55:29PM -0700, Jon Smirl wrote:
| Why do you dynamically generate a dispatch for unknown functions instead of
| just returning null? ...
Since I'm one of the people who proposed that behavior, I guess I should
save Ian the trouble of explaining. :-)
There are several
On Sun, May 09, 2004 at 08:14:59PM -0700, Ian Romanick wrote:
| ... I very seriously doubt that you can halt and restart an
| in-progress shader. That would require extra logic, reduce performance,
| and wouldn't help games. What makes you think any of the current cards
| are designed
On Mon, Mar 08, 2004 at 08:28:55PM -0800, Ian Romanick wrote:
| ...
| - Implement the wait in the kernel. The driver calls a new swap ioctl
| that takes the 'target' frame as a parameter. The kernel mainains a
| queue of pending swaps that is checked each time a vblank interrupt is
| handled.
On Tue, Feb 10, 2004 at 08:41:40AM +1100, Benjamin Herrenschmidt wrote:
|
| - GL cannot be the _only_ API, simply because we don't (and may not have
| for some time) GL support on all cards, while still wanting this new console
| stuff so we don't have to keep the old cruft around
Just so long
On Wed, Feb 04, 2004 at 10:12:19AM -0800, Ian Romanick wrote:
|
| Okay, that's just weird. Normally the Nvidia extension string is about
| 3 pages long.
Just for reference, here's the direct-rendering version (table of
Visuals omitted):
name of display: :0.0
display: :0 screen: 0
direct
I waited a while but no one else replied to this one, so I'll give it
a try.
On Sat, Oct 25, 2003 at 12:08:48PM +0200, Morten Hustveit wrote:
| In the Radeon driver, TCL is currently enabled by default. However, it seems
| like there is no guarantee that the same set of vertices will be
On Fri, Oct 17, 2003 at 09:57:48PM +0100, Keith Whitwell wrote:
|
| I'm strongly against having sync-to-refresh as the default. I've been
| there with the tdfx driver and it truely sucks.
When you're using double-buffering as it was originally intended, to
ensure a smooth transition from frame
On Fri, Oct 10, 2003 at 12:24:56PM +0100, Keith Whitwell wrote:
|
| No. No preservation is done. We need to invalidate everything.
|
| That's a problem, as the only way we can do things like accelerated
| CopyTexSubImage() and single-copy textures is if the FB contents are
| guarenteed to be
On Fri, Oct 10, 2003 at 03:16:45PM -0700, Ian Romanick wrote:
|
| Since I was part of that working group, I'd like to clarify why some of
| those decisions were made. ...
Apologies if I sounded too critical -- I agree that compromise was a
reasonable thing to do in the VBO case.
|
On Sat, Aug 09, 2003 at 12:54:46AM +0200, Ove Kaaven wrote:
| I'm interested in a practical solution. Do anyone plan to implement a
| library that will perform all the measurements you suggest (with the
| keep-the-cpu-busy addition needed for being useful in practice) and
| convert them to
On Fri, Aug 01, 2003 at 05:57:14PM -0700, Ian Romanick wrote:
| ...
| If we take away the ability to add functions to the GLX function table,
| is it really useful for drivers to be able to add new extensions at all?
| That would also remove the need for the force_client parameter to
|
Be careful about how you interpret this news. The GL2 proposal has
*not* been adopted as part of the OpenGL core. (Not yet, at least.)
The shading language plus the three related extensions were approved as
ARB extensions, though.
Allen
---
On Thu, Jun 12, 2003 at 04:54:47PM -0600, Brian Paul wrote:
|
| An ARB extension for NPOT 1D, 2D, 3D and cube textures is coming.
| Parameterized texture coordinates (i.e. [0,1] range) will be used,
| rather than [0,w]x[0,h] like GL_NV_texture_rectangle.
There's interest in supporting
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
On Fri, Apr 04, 2003 at 05:13:44PM -0800, Ian Romanick wrote:
| IMHO, we'd be better to spend our time writing a highly optimized
| just-in-time compiler for ARB_vertex_program. Then we could just write
| vertex programs for the different important state vectors and let the
| compiler
On Thu, Mar 06, 2003 at 05:06:41PM +, Alan Cox wrote:
| Maybe it will be easier now MS have resigned, although that puts them in a
| nice position to avoid declaring patent interests and destroy OpenGL by
| submarine patenting games
Microsoft caught a lot of flak over their
Hi, Jens!
On Wed, Mar 05, 2003 at 09:52:58PM -0700, Jens Owen wrote:
| Allen Akin wrote:
| Microsoft bears a lot of
| the burden for D3D by collecting and maintaining the common code (as
| well as nontechnical stuff like patent licensing and sublicensing). SGI
| didn't do that for OpenGL
On Sat, Mar 01, 2003 at 06:47:26PM -0800, Linus Torvalds wrote:
| ...
| At some point that won't be true any more. And maybe it's just me, but
| with programmable vertex and pixel shaders it looks like the onus is
| shifting onto the _user_, and it's more likely that the hardware designs
| won't
On Sun, Mar 02, 2003 at 12:57:42AM -0500, Daniel Vogel wrote:
| On Sat, 1 Mar 2003, Allen Akin wrote:
|
| Once you get rid of the legacy stuff in OpenGL, drivers are pretty much
| the same level of complexity for OpenGL as for D3D.
|
| I guess you also had to take away mandatory software
On Sat, Mar 01, 2003 at 03:11:06PM -0800, Linus Torvalds wrote:
|
| ... you have to understand a
| wide range of different issues (you can't just understand hardware, you
| also have to have some understanding of OpenGL).
| ...
| Look at the size of a
On Fri, Feb 28, 2003 at 03:04:08PM +, Ian Molton wrote:
| On Thu, 27 Feb 2003 18:17:33 -0800
| Allen Akin [EMAIL PROTECTED] wrote:
|
|
| Then there are the arguments for deeper color channels based on the
| need for higher-precision intermediate results -- for transparency
On Fri, Feb 28, 2003 at 09:25:56AM +0100, Sven Luther wrote:
| On Thu, Feb 27, 2003 at 02:01:22PM -0800, Jon Smirl wrote:
|... Moore's law
| means that everyone is going to have super 3D hardware
| in a couple of years.
|
| Even Embeded or handheld
On Thu, Feb 27, 2003 at 02:01:22PM -0800, Jon Smirl wrote:
| I'm not really looking for an X alternative. I was
| just thinking about how to improve X over the next
| five to ten years. Both the Mac and Windows Longhorn
| are using new 3D enabled GUIs. This is more of a
| response to these new
On Fri, Feb 28, 2003 at 12:15:25AM +, Ian Molton wrote:
| I never understood why the 2D engine and 3D engine were ever seperate...
History. 2D techniques were well-established and beginning to be
commoditized in hardware long before 3D issues were well-enough
understood to do the same. It
On Fri, Feb 28, 2003 at 01:04:59AM +, Ian Molton wrote:
|
| The human eye cant do better than 9bpp, and thats in its most sensitive
| colour, green.
The human eye can see boundaries between colors that differ in intensity
by less than 1 part in 512, particularly at low intensities. This
Minor terminology suggestion...
On Mon, Feb 24, 2003 at 11:24:14AM -0800, Ian Romanick wrote:
| ...
| As has recently been discussed on the dri-devel mailing list, texture
| uploads in the DRI are not fully pipelined [1]...
I notice a lot of people on this list say upload when describing
On Tue, Feb 04, 2003 at 10:44:45AM -0800, Ian Romanick wrote:
| The OpenGL ARB has a test suite called conform, but it is not
| publicly available. The open-source test suite is Glean.
| http://glean.sf.net/. Both glean and conform have fallen a bit behind
| the times. Writing some new
On Thu, Jan 16, 2003 at 11:42:31PM -0800, magenta wrote:
| I'd personally take the school of thought that if the user is running a
| game which takes up 60MB of texture memory and then tries to concurrently
| launch something which takes up another 60MB of texture memory, it's their
| own fault
On Thu, Jan 16, 2003 at 10:16:30PM -0800, magenta wrote:
|
| Should it even be possible for one process to swap out other processes'
| context data?
In the same way that one process can cause the ordinary memory pages of
another process to be swapped out, I'd say yes.
As the old saying goes,
On Thu, Dec 05, 2002 at 03:28:49PM -0800, Linus Torvalds wrote:
| Let's put out some facts, instead of just arguing:
|
| - FSAA is a good idea...
Definitely.
| - FSAA _cannot_ be done by a wrapper. End of discussion.
Well, that depends on the hardware. Supersampled FSAA can be done
without
Apologies for re-ordering your comments, but I thought it might make my
reply more clear.
On Thu, Dec 05, 2002 at 05:38:41PM -0800, Linus Torvalds wrote:
|
| On Thu, 5 Dec 2002, Allen Akin wrote:
|
| Putting it in kernel guy terms, it's like sideband mechanisms for
| talking to device
On Wed, Dec 04, 2002 at 12:57:44AM -0600, D. Hageman wrote:
| This illustrates one of the bad points of using environment variables.
| Will we have to add environment variables every time a new app is pushed
| out the door? Bad approach.
In general, if a bug affects every app, then the
On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote:
| Remote indirect rendering is a problem no matter how you slice it.
Well, maybe not if you handle preference-setting at the application
level, rather than trying to do it at the library or driver levels.
Then it can be dynamic, or
On Wed, Dec 04, 2002 at 01:39:19PM -0800, Ian Romanick wrote:
|
| Now, imagine the drivers having an interface that a tool (for creating app.
| profiles) could query. The driver would send back (perhaps using XML or
| something similar?) a list of knobs that is has in the form:
|
| - Short name
On Tue, Dec 03, 2002 at 10:14:45AM -0800, Linus Torvalds wrote:
|
| Why? I don't understand this reluctance to just admit that the _user_ may
| be right.
I note your use of the word may. Sometimes the user can happily
express a simple preference, but often such a choice has consequences
that
On Tue, Dec 03, 2002 at 11:22:00AM -0800, Linus Torvalds wrote:
| ... You should look at what Windows drivers do. And they
| _all_ have user-settable preferences for things like texture quality etc.
We should look at where Windows drivers are going, not where they are
today.
On Tue, Dec 03, 2002 at 12:24:22PM +0100, Felix Kühling wrote:
| ...
| But the choice for the following internalformats also depends on the
| screen color depth in the current implementation:
|
|case GL_RGBA8:
|case GL_RGB10_A2:
|case GL_RGBA12:
|case GL_RGBA16:
|
|case
On Tue, Dec 03, 2002 at 03:42:06PM -0700, Nicholas Leippe wrote:
| I guarantee you that the only thing truly knowledgeable enough to make such
| tradeoffs is the user at the keyboard, not the programmer writing the
| application somewhere else on different hardware with different tastes.
Maybe
On Tue, Dec 03, 2002 at 04:35:49PM -0800, Linus Torvalds wrote:
|
| Depends. How much performance will I lose on my machine when I force
| anisotropic filtering on? Just because you can turn the feature on
| doesn't mean you automatically get a better user experience.
|
| But that's the
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| So if we agree on this, I would make this
| controlled by an environment variable. ...
The intent of the spec is that drivers should support whichever texture
internal formats they wish to support, and apps
On Sun, Dec 01, 2002 at 02:12:08PM -0500, Leif Delgass wrote:
| According to section 4.1.8 of the OpenGL 1.4 spec: Initially, dithering
| is enabled -- so that should always be the initial default.
Right.
Glean disables dithering in some cases (particularly when object identifiers
are encoded
On Thu, Nov 21, 2002 at 05:50:51PM +0200, Pasi Kärkkäinen wrote:
|
| Quote from the webpage (URL above):
|
| The new unified driver provides robust OpenGL® 2.0 support for many of ATIs
| award-winning graphics boards including:
|
|
| Does these drivers _really_ have OGL 2.0 support?
Couldn't
On Thu, Nov 21, 2002 at 05:50:51PM +0200, Pasi Kärkkäinen wrote:
|
| Quote from the webpage (URL above):
|
| The new unified driver provides robust OpenGL® 2.0 support for many of ATIs
| award-winning graphics boards including:
|
|
| Does these drivers _really_ have OGL 2.0 support?
ATI says
On Mon, Nov 18, 2002 at 08:14:53PM -0800, Ian Romanick wrote:
|
| How does one go about determining the (data structure / API) version of
| libGL.so?
As I understand it, there isn't a formal version number. Apps that
follow the Linux ABI shouldn't need to be aware of the libGL version,
so there
On Tue, Oct 22, 2002 at 11:56:19AM -0700, Ian Romanick wrote:
|
| After the meeting, I thought of another possible usage. A number of
| companies, most notably id Software, are using home-grown shading languages.
| Depending on the set of available hardware features, they pick a different
|
Originally on the ARB general-discussion list:
- Forwarded message from Christian Laforte [EMAIL PROTECTED] -
From: Christian Laforte [EMAIL PROTECTED]
Subject: Re: [opengl-participants] A simple extension for querying for hardware
acceleration
Date: Fri, 9 Mar 2001 13:49:26 -0500
I
On Sat, Oct 19, 2002 at 03:24:57PM +0200, Michel Dänzer wrote:
| So is this patch good to go?
I haven't followed the entire discussion, but from what I've seen, the
patch sounds good.
Allen
---
This sf.net email is sponsored by:
Access Your
On Fri, Oct 18, 2002 at 08:49:11AM -0600, Brian Paul wrote:
|
| ...(except polygon offset, IMHO).
Is the precision requirement too high, or is something more fundamental
broken?
Allen
---
This sf.net email is
On Fri, Oct 18, 2002 at 11:49:46AM -0600, Brian Paul wrote:
|
| IIRC, the test draws extremely small (subpixel) triangles.
Yeah, the original version of the test did that. The current version
uses a full-window-size quad, so I think it's much better with respect
to the problems you mentioned.
On Sat, Oct 19, 2002 at 12:03:05AM +0200, Michel Dänzer wrote:
| Attached is the output of glean -c comparing two runs, one with the
| subpixel offset for the Y coordinate, the other without. It seems if it
| makes a difference, it's for the good ...
Did the trunk pass the tests involving
On Thu, Oct 17, 2002 at 09:22:37AM -0700, Ian Romanick wrote:
| ...
| So, I asked a couple people around IBM what the accepted practice was. I
| was told that an implementation is not required to export extension strings
| for extensions that are required for its adverteised OpenGL version. I
On Thu, Oct 17, 2002 at 10:35:17AM -0700, Ian Romanick wrote:
| On Thu, Oct 17, 2002 at 10:09:28AM -0700, Allen Akin wrote:
| Also, I wouldn't want to encourage app developers to use the absence of
| an extension string to determine whether a core function is hardware
| accelerated
On Thu, Oct 17, 2002 at 01:16:13PM -0600, Brian Paul wrote:
| ...
| If we only return a true/false result from the slow/fast query it may not
| be obvious to the application writer what caused the slow path to be taken,
| or what to do about it.
Yep, it turns into a combinatorial search problem.
On Mon, Jul 15, 2002 at 02:10:06PM -0500, Stephen J Baker wrote:
| The deal though is that (presuming MS really do own these rights)
| they are talking in terms of LICENSING this IP to allow OpenGL
| to continue to exist. Who would pay them to license it for
| Linux?
There may be ways to
On Sat, Jul 13, 2002 at 12:36:53AM +0100, José Fonseca wrote:
| I would like to know your opinion about the influence this may have for
| the DRI and Mesa3D projects in particular, and for the OpenGL API in
| general.
Of course Microsoft would love to see OpenGL disappear, and has been
working
On Fri, May 17, 2002 at 02:06:02PM +0100, Ian Molton wrote:
| ...
| ...I need lists of
| supported features on various video cards.
| ...
| Please tell me if the features are:
|
| (A)ccelerated
| (U)naccelerated
| (N)ot available on that
On Sat, May 18, 2002 at 01:33:55AM +0100, Ian Molton wrote:
| ...
| Users dont care if 'feature X' has caveats or conditions as to its
| acceleration (generally speaking). They simply expect it will work in
| the 'common case'.
I think this is just as much a problem for users as for developers.
On Fri, Apr 12, 2002 at 02:43:00PM +0100, José Fonseca wrote:
|
| I've started to play with glean and I tried to check this myself, but it
| seems there is no effect in the results no matter what changes I make in
| mmx_blend.S. ...
The blend test only fails if an error is greater than one
On Fri, Apr 12, 2002 at 05:12:33PM +0100, Michael wrote:
|
| iirc, there's a bug in tblend.cpp, when it does the
| check, it doesn't increment ePix, aPix so some pixels aren't checked.
Yep, that's definitely a bug. Why haven't I heard a bug report before
now? :-)
Fix is checked in.
Allen
On Fri, Apr 12, 2002 at 07:01:08PM +0100, José Fonseca wrote:
| ... Although doing (p*a+q*(1-a)) 8 can
| introduce up to 1 LSB error and worst, it doesn't obey to the rule of
| 255*255 = 255 as 255*255/256 = 254. I know that in Mesa's C blending code
| this special
On Fri, Apr 12, 2002 at 01:14:30PM -0600, Brian Paul wrote:
|
| One might expect that the following identities be true for blending terms:
|
| 1.0 * 1.0 == 1.0
| 1.0 * x == x * 1.0 == x
| 0.0 * x == x * 0.0 == 0.0
|
| So for 8-bit channels, in fixed point:
|
| 255 *
On Mon, Apr 08, 2002 at 06:17:59PM -0700, Raystonn wrote:
| As far as the reading of pixels from the framebuffer, this is a highly
| inefficient thing to do, no matter the hardware.
It doesn't have to be; that's just a tradeoff made by the hardware
designers depending on the applications for
This is such a hard problem...there's no simple solution, and people
have been thinking about it for over ten years.
I'd advise against a configuration file that chooses conformance or
performance on a feature-by-feature basis, for at least these reasons:
Sometimes you need to choose
On Tue, Feb 12, 2002 at 09:03:55PM +, Keith Whitwell wrote:
|
| The Utah drivers detected thrashing switched from a LRU to MRU replacement
| strategy. The dri drivers could/should but don't do the same...
I suppose it wouldn't be too hard to keep a record of the texture binds
from the
On Sun, Feb 03, 2002 at 02:23:12PM -0500, Vladimir Dergachev wrote:
| Try glean: http://glean.sourceforge.net/
|
| Tried, no luck compiling..
If you have time, please send me a note describing the problem and the
environment in which you're trying to compile, and I'll see if I can fix
it.
On Wed, Jan 30, 2002 at 08:27:49PM -0700, Jens Owen wrote:
| This is no joke. We absolutely need compatability. Large amounts of
| developer pain don't even begin to compare to the enormous number of
| headaches incompatability causes our users.
Not to mention that Linus will almost certainly
On Fri, Jan 25, 2002 at 11:42:51AM -0800, Philip Brown wrote:
|
| As a device driver writer, it feels intrinsically 'wrong' for user-space
| programs to say map the device registers into my address space, turn off
| all memory protection, and I'll take it from here.
Except for the turn off all
On Fri, Jan 25, 2002 at 01:17:43PM -0800, Philip Brown wrote:
| On Fri, Jan 25, 2002 at 12:16:06PM -0800, Allen Akin wrote:
|
| Except for the turn off all memory protection part, that's essentially
| the way most 3D drivers have to work. OpenGL *is* the hardware
| abstraction layer; you
On Fri, Jan 25, 2002 at 09:41:52PM -0800, Philip Brown wrote:
|
| Probably I misunderstood your original comment. But just as a
| clarification, libGL doesn't provide an additional interface abstraction
| for OpenGL commands; it does some things for dispatch setup, and
| thereafter OpenGL
On Mon, Jan 21, 2002 at 09:21:54AM -0500, Mike Westall wrote:
| Conversely, if MS considers OpenGL to be dead and buried,
| period, it seems that Bill would be bit silly to want to
| spend $62.5 to become the owner of said dead + buried
| technology!!
I doubt that most of SGI's patents are
On Mon, Jan 21, 2002 at 04:09:29PM +, Josef Karthauser wrote:
| You reckon? I was told by a group of games writing guys (currently
| working on Xbox) that Direct3D is getting closer and closer to OpenGL in
| functionality.
|
| Which opinion is correct?
D3D has been absorbing OpenGL
On Mon, Jan 21, 2002 at 07:45:39AM +0800, Rogelio M. Serrano Jr. wrote:
| What will happen to opengl?
| As far as I know that is already MS property.
No, OpenGL doesn't belong to Microsoft. It'll continue to exist and be
used for a long while, provided we keep it up-to-date and the
On Thu, Jan 17, 2002 at 10:08:54PM +1100, Dan wrote:
| http://www.theregister.co.uk/content/54/23708.html
Of course we don't know exactly which patents are involved, or what the
terms of the transfer were. But my guess would be that the patents
primarily involve hardware, and Microsoft is
On Tue, Nov 13, 2001 at 02:54:43AM -0800, strobe anarkhos wrote:
|
| Well if you're going to add all that you might as well develop a
| completely new API or just copy a better standard like display
| postscript.
Or use OpenGL, in many cases.
The reason I brought it up is that people *are*
It's an interesting idea. Sometimes I've been concerned that the X
world is reinventing concepts that already exist in the OpenGL world,
thus reducing the leverage that we might otherwise gain from driver
optimizations and from relationships with hardware vendors. An X server
based on an OpenGL
On Wed, Oct 03, 2001 at 12:57:55AM +, David Johnson wrote:
|... I think a major problem for Linux is forward and
| backward compatibility issues and compatibility issues between
| distributions. ...
There are (at least) two issues here: Binary compatibility for
On Sun, Sep 30, 2001 at 10:09:47PM +0200, Marcelo E. Magallon wrote:
| Is it really a pure hardware problem? Rumors on comp.graphics.opengl
| are that the vendors don't invest time optimizing that path (in the
| driver) because there's not much demand for it. ...
Most consumer-level
On Wed, Jun 06, 2001 at 11:50:37AM -0400, Mike Westall wrote:
| We have an application (``instant'' radiosity) that needs to read
| back depth information from the graphics card. ...
Ironically enough I checked-in a glean test for this just last week.
Allen
96 matches
Mail list logo
