John Bridgman wrote :
> OK, file this under "be careful what you wish for"...
>
> It turns out that while the programming model of Evergreen is
> very similar to 7xx, the register offsets are totally
> different, which has been causing a bunch of header file pain
> trying to merge Evergreen sup
> On Tue, Apr 13, 2010 at 11:47 PM, Keith Whitwell
> wrote:
..
> Hmm, on gmail this is threaded as if a comment on John's "be careful
> what you wish for" post - which wasn't the intention. My own fault
> for top-posting.
Probably my fault - I subscribed to the list midway through the discussi
On Tue, Apr 13, 2010 at 11:47 PM, Keith Whitwell
wrote:
> I'm much more relaxed about the future of Gallium these days. I don't
> think there's any sense in pushing people or projects towards it -
> people are welcome to evaluate it on its merits and make their own
> decisions on that basis.
Hmm
I'm much more relaxed about the future of Gallium these days. I don't
think there's any sense in pushing people or projects towards it -
people are welcome to evaluate it on its merits and make their own
decisions on that basis.
The project itself is clearly on a strong footing. We've shown we c
JB>>The reality is that we don't have a conveniently timed architectural break
to force the writing of an all new driver, and I imagine you don't either, so
we're all going to have to "ooze" across to Gallium3D.
OK, file this under "be careful what you wish for"...
It turns out that while the p
>No, it was true even as the first Gallium code was landing in the
>repo. Rewriting everything is always painful, and we already had
>plenty of other tasks to keep us busy (see Dave's mail) and cause pain
>for everyone. In hindsight, maybe it wouldn't have been any worse than
>what we went throug
[snip'd]
Two observations:
1) I wrote most of a Gallium driver. By myself. It took OVER 9000
lines of code, but it happened. I'd say that an interface that permits
one mediocre coder armed with docs to craft a working, simple driver
in a couple months (effectively three man-months, by my estimate
On Tue, Apr 13, 2010 at 6:01 AM, José Fonseca wrote:
> On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
>> No offence to gallium, but I don't think its been mature enough to
>> ship a driver for as long as Intel have had to ship drivers. I'm not
>> even sure its mature enough to ship a driver
On Tue, 13 Apr 2010 09:36:13 +0200
Michel Dänzer wrote:
> > Moving to Gallium would be a huge effort for us. We've invested a lot
> > into the current drivers, stabilizing them, adding features, and
> > generally supporting them. If we moved to Gallium, much of that effort
> > would be thrown aw
On Tue, Apr 13, 2010 at 4:23 AM, Luca Barbieri wrote:
> Has Intel or anyone else considered open sourcing their Windows
> DirectX 10 user mode DDI drivers, porting them to Gallium and filling
> in the missing GL-specific functionality from the GL drivers?
AMD considered opening it's at least part
On Tue, 2010-04-13 at 03:52 -0700, Dave Airlie wrote:
> On Tue, Apr 13, 2010 at 8:01 PM, José Fonseca wrote:
> > On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
> >> No offence to gallium, but I don't think its been mature enough to
> >> ship a driver for as long as Intel have had to ship dr
>> As I said SVGA doesn't count its not real hw, it relies on much more
>> stable host drivers yes, and is a great test platform for running DX
>> conformance, but you cannot use it as a parallel to real hardware.
>
> Why not? It looks like a GPU. It acts like a GPU. (Maybe it even smells
> like a
On Tue, Apr 13, 2010 at 9:08 PM, Michel Dänzer wrote:
> On Tue, 2010-04-13 at 20:52 +1000, Dave Airlie wrote:
>> On Tue, Apr 13, 2010 at 8:01 PM, José Fonseca wrote:
>> > On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
>>
>> > Also, the closed drivers that you decided not to count were as s
On Tue, 2010-04-13 at 20:52 +1000, Dave Airlie wrote:
> On Tue, Apr 13, 2010 at 8:01 PM, José Fonseca wrote:
> > On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
>
> > Also, the closed drivers that you decided not to count were as stable as
> > they could be in the allocated time. When we w
On Tue, Apr 13, 2010 at 8:01 PM, José Fonseca wrote:
> On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
>> No offence to gallium, but I don't think its been mature enough to
>> ship a driver for as long as Intel have had to ship drivers. I'm not
>> even sure its mature enough to ship a driver
On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
> No offence to gallium, but I don't think its been mature enough to
> ship a driver for as long as Intel have had to ship drivers. I'm not
> even sure its mature enough to ship a driver with yet. I know you guys
> have shipped drivers using it,
2010/4/13 Dave Airlie :
> No offence to gallium, but I don't think its been mature enough to
> ship a driver for as long as Intel have had to ship drivers. I'm not
> even sure its mature enough to ship a driver with yet. I know you guys
> have shipped drivers using it, but I don't count the closed
On Tue, Apr 13, 2010 at 6:23 PM, Luca Barbieri wrote:
> Has Intel or anyone else considered open sourcing their Windows
> DirectX 10 user mode DDI drivers, porting them to Gallium and filling
> in the missing GL-specific functionality from the GL drivers?
>
> That might prove easier than porting t
Has Intel or anyone else considered open sourcing their Windows
DirectX 10 user mode DDI drivers, porting them to Gallium and filling
in the missing GL-specific functionality from the GL drivers?
That might prove easier than porting the GL drivers (the DirectX 10
design is much closer), and allows
2010/4/13 Michel Dänzer :
> On Mon, 2010-04-12 at 10:12 -0700, Jesse Barnes wrote:
>> On Mon, 12 Apr 2010 09:00:57 +0200
>> Michel Dänzer wrote:
>>
>> > On Mon, 2010-04-12 at 08:00 +0200, Luca Barbieri wrote:
>> > > The Intel drivers also appear to be in the same situation, with
>> > > classic dri
On Mon, 2010-04-12 at 10:12 -0700, Jesse Barnes wrote:
> On Mon, 12 Apr 2010 09:00:57 +0200
> Michel Dänzer wrote:
>
> > On Mon, 2010-04-12 at 08:00 +0200, Luca Barbieri wrote:
> > > The Intel drivers also appear to be in the same situation, with
> > > classic drivers not being dropped in favor
On Mon, 12 Apr 2010 09:00:57 +0200
Michel Dänzer wrote:
> On Mon, 2010-04-12 at 08:00 +0200, Luca Barbieri wrote:
> > The Intel drivers also appear to be in the same situation, with
> > classic drivers not being dropped in favor of Gallium ones, also
> > indicating possible Gallium shortcomings
On 04/12/2010 02:00 PM, Keith Whitwell wrote:
> On Mon, Apr 12, 2010 at 9:55 AM, Christoph Bumiller
> wrote:
>> On 04/12/2010 10:22 AM, Luca Barbieri wrote:
>>
> 4. More powerful and better defined clear interface with scissor/MRT
> support
I'm not sure how scissors fit in, othe
On Mon, Apr 12, 2010 at 9:55 AM, Christoph Bumiller
wrote:
> On 04/12/2010 10:22 AM, Luca Barbieri wrote:
>
4. More powerful and better defined clear interface with scissor/MRT
support
>>>
>>> I'm not sure how scissors fit in, other than that you probably have to
>>> hax them on your HW
FWIW, thinking about it a bit more, my opinion is that it might be
best to add both a flag to respect scissors and also explicitly pass
the MRT buffer/component writemask as well to clear().
Drivers can probably disable/enable scissors and change writemasks, if
necessary, in a faster way than the
Sorry, I didn't see it: seems like something went wrong for me in the
list switchover to freedesktop.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 04/12/2010 10:22 AM, Luca Barbieri wrote:
>>> 4. More powerful and better defined clear interface with scissor/MRT support
>>
>> I'm not sure how scissors fit in, other than that you probably have to
>> hax them on your HW to work with clears, but this isn't really a
>> problem any longer. If y
>> Well, there are a lot of things that Gallium doesn't do well compared
>> to other APIs, mostly OpenGL:
>> 1. Support for fixed function cards in some way, either:
>> 1a. (worse) New Gallium interfaces to pass fixed function pipeline
>> states, along with an auxiliary module to turn them into sha
On Mon, Apr 12, 2010 at 12:04 AM, Luca Barbieri wrote:
> Well, there are a lot of things that Gallium doesn't do well compared
> to other APIs, mostly OpenGL:
> 1. Support for fixed function cards in some way, either:
> 1a. (worse) New Gallium interfaces to pass fixed function pipeline
> states, a
> Do what r300g does: Delay VBO submission, and make a choice at render
> time as to whether immediate mode is going to pay off in performance.
nv50 and unpushed work on nvfx already do that, but that only works
well when the user specifies a pointer to an array of vertex
attributes.
If instead t
> You've kind of sparked my curiosity, though. What "larger class of
> features" are you wanting to address, specifically? Some things are
> simply not well-designated in the docs, like multisampling; others are
> intentionally not part of Gallium, like non-GL_RENDER modes.
Well, there are a lot o
On Mon, 2010-04-12 at 08:00 +0200, Luca Barbieri wrote:
>
> This includes all pre-R300 Radeon hardware, and since Radeon
> development hasn't yet moved to Gallium exclusively, maybe there are
> also some shortcomings in the Gallium interface affecting R300+ that
> are preventing r300 and r600 to
On Sun, Apr 11, 2010 at 11:00 PM, Luca Barbieri wrote:
>> If you believe that it is easier to implement features on your hardware by
>> straying from Gallium or Mesa interfaces, you are welcome to do so.
>
> I don't understand what you mean.
> As far as I know, the classic Mesa interfaces cover al
> If you believe that it is easier to implement features on your hardware by
> straying from Gallium or Mesa interfaces, you are welcome to do so.
I don't understand what you mean.
As far as I know, the classic Mesa interfaces cover all OpenGL
features, since they don't abstract much.
The discuss
If you believe that it is easier to implement features on your hardware by
straying from Gallium or Mesa interfaces, you are welcome to do so.
Posting from a mobile, pardon my terseness. ~ C.
On Apr 11, 2010 6:53 PM, "Luca Barbieri" wrote:
> include this deprecated GL feature
While it is depre
> include this deprecated GL feature
While it is deprecated by Khronos, I'm not sure it will every go away.
nVidia explicitly states they have no intention to drop the
compatibility profile and even intend to keep it performing optimally.
While I couldn't find any statement from ATI, it seems unli
36 matches
Mail list logo
