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 destroys
On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote:
| On Fri, Jun 12, 2009 at 10:01 AM, Allen Akin 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
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.
I'
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 outstan
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 dete
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 or
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 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 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: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 i
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
| s
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 get
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 jus
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 t
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 hel
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 determine
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 look
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 autho
On Wed, Jun 30, 2004 at 11:40:27AM +0900, Sasayama wrote:
| How complete is it in regard to the OpenGL specification?
I've managed the development of a couple of OpenGL test suites
(including the official conformance test suite for the first several
years of its existence). A suite that aspires t
| > Is there any free test suite for OpenGL? We'd like to test our DRI
| > implementation, but don't need a trademark license at this time.
|
| glean.sf.net
Sure could use some fresh contributions...especially for recent
extensions.
Allen
---
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 re
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 a
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 rende
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 transfor
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 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 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 p
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 somethin
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
| __glXEna
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
---
T
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 non-norma
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 windo
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 g
On Sat, Mar 22, 2003 at 07:24:15PM +, José Fonseca wrote:
| Also, I can't help thinking that some of these tricks wouldn't be
| necessary if the OpenGL standard had chosen to pass opaque pointers
| (i.e., handles) to contexts and textures, instead of using concepts such
| as "current context" a
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 intellectual-proper
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 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 so
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 be
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 3D
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 sys
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 -- f
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
resu
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 tu
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 GUI
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
transf
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 gle
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 tha
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, "
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
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 d
On Thu, Dec 05, 2002 at 11:43:51AM +, Keith Whitwell wrote:
|
| It's also a good description of how the Chromium configuration tools work...
Yep. If I understand correctly, though, the Chromium configuration
tools are intended mostly to allow SPUs and drivers and other low-level
components t
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 nam
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 ther
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 drive
On Wed, Dec 04, 2002 at 11:12:46AM +0100, Felix Kühling wrote:
| One thing we should keep in mind about the future is indirect rendering.
| Environment variables which are only known on the client side won't work
| then. ...
Good point.
Allen
On Tue, Dec 03, 2002 at 05:02:36PM -0800, Ian Romanick wrote:
|
| ...It's the year 2002 (almost 2003) and I can actually
| choose how to operate my computer instead of having somebody else dictate it
| to me...
Let me get this straight. The lack of ability to add new features to
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 Tue, Dec 03, 2002 at 03:29:32PM -0800, Ian Romanick wrote:
|
| ... On Windows, I can go into the OpenGL tuning app for my driver and
| click 'force anisotropic filtering.' Since this extension was created AFTER
| Quake, there's NO WAY to enable it from Quake. In Linux I get tough
| cooki
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 I
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 GL_RGB
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.
There
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 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 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 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 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 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
| back-
There was good discussion of the acceleration-query extension on today's
IRC session. We didn't come to a definite conclusion, but we did flush
out a lot of the issues.
The subject of this extension has come up repeatedly, practically since
the day OpenGL was first specified. The (still most acc
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
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 PC
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 readback
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.
I
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 s
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 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
| &g
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 was
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 finesse
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 t
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, 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 hardw
On Fri, Apr 12, 2002 at 01:17:51PM -0700, Gareth Hughes wrote:
|
| Perhaps we need a "-pedantic"-like command-line option to force more
| stringent tests?
We'd still have to figure out how stringent the test should be, and in a
lot of cases that's unclear to me. (e.g. texture accuracy involves
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 * 255
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 c
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 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
lea
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 whic
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 con
On Tue, Feb 19, 2002 at 11:05:08AM -0800, Ian Romanick wrote:
|
| How about the obvious? Don't put libGL (and friends) in /usr/lib.
The Linux OpenGL ABI standard requires that libGL and libGLU be in
/usr/lib. Obviously a lot of applications will work even if that's not
true, but some apps, Mak
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 pre
Just a side comment on Ian's excellent summary...
On Tue, Feb 12, 2002 at 11:45:58AM -0800, Ian Romanick wrote:
| - If an allocation (via the memHeap_t) fails when texture space is allocated
| (radeonUploadTexImages in lib/GL/mesa/src/drv/radeon/radeon_texmem.c),
| blocks at the end of the te
On Sat, Feb 09, 2002 at 05:03:31AM +, Keith Whitwell wrote:
| ... opengl doesn't require that we get exactly the same results in these
| two cases - certainly it's desirable, but the specification specifically
| allows these types of variances.
Yes. This subject came up on opengl-gamedev
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.
All
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 t
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 Ope
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 hardwa
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 al
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 technolo
1 - 100 of 109 matches
Mail list logo
