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
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
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
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
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 Sun, 2010-04-11 at 01:23 -0700, Jose Fonseca wrote:
> Module: Mesa
> Branch: master
> Commit: 21780adc2ed1b10c5c4c71427b8212b8464d065d
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=21780adc2ed1b10c5c4c71427b8212b8464d065d
>
> Author: José Fonseca
> Date: Sat Apr 10 02:44:52
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,
From: Chia-I Wu
It has no user after the removal of st_public. Plus, it has never been
implemented by a pipe driver or winsys.
---
src/gallium/auxiliary/util/u_simple_screen.h |5 -
src/gallium/include/pipe/p_screen.h |7 ---
2 files changed, 0 insertions(+), 12 deletio
On Mon, Apr 12, 2010 at 12:37:10PM -0400, Kristian Høgsberg wrote:
> I've been looking into the GLES1/2 support in mesa and trying to
> figure out how to make it work for DRI drivers as well. The current
> approach only works for gallium, and it works by compiling mesa core
> as different state tr
On Tue, 2010-04-13 at 02:12 -0700, Michel Dänzer wrote:
> On Sun, 2010-04-11 at 01:23 -0700, Jose Fonseca wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 21780adc2ed1b10c5c4c71427b8212b8464d065d
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=21780adc2ed1b10c5c4c71427b8212
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 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 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
>> 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
Looks good to me.
Keith
On Tue, Apr 13, 2010 at 11:22 AM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> It has no user after the removal of st_public. Plus, it has never been
> implemented by a pipe driver or winsys.
> ---
> src/gallium/auxiliary/util/u_simple_screen.h | 5 -
> src/gallium/in
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
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, 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 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
[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
>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
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
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
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
> 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
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
It's using normalized texcoords, but not setting it in the sampler state.
How can this possibly work with r300g though?
Am I missing something?
Perhaps r300g compensates with another bug that causes it to ignore the
request to use unnormalized texcoords?
---
src/gallium/auxiliary/util/u_blitter.
So I've finished the r300g point sprite code and this test fails,
fglrx fails the exact same way.
http://people.freedesktop.org/~airlied/piglit/fglrx/fglrxr500/test_glean__pointSprite.html
It appears the point size where the texture sampler decides to use the
next mipmap is different than the swr
28 matches
Mail list logo
