Lightspark May Work Towards A Gallium3D State Tracker

[V!NCENT]

@Wirrbeltier,
You're using your head; I'm shocked.
The trolls are of course those standard blob users who hate to realise that their GeForce is actually going to suck to infinity when they thought what they thought to be a boundless graphics card for the Linux desktop. It's not their fault for not being able to look in the future, but it is pathetic human instinctive/standard behavior to start hating the fortunate people.

BlackStar is just a troll nontheless, but is not always wrong.

[jakubo]

hi, as was mentioned before i thought that gallium was created to make things simple, and to implement features htat might not be native to the hardware.
and talking of that. i thought that there would be a VDPAU state tracker (even for ati cards) to resolve the discussion about flash-y things.

somehow gallium starts sounding to me like another mesa version.
why are there so many other things apart from opengl and directX. are they not up to the task?
what is gallium? what is mesa then? why DRI and DRM...??? which one adresses to the hardware directly?
sounds like a lot of redundancy to me...

[NoEffex]

@Wirrbeltier,
You're using your head; I'm shocked.
The trolls are of course those standard blob users who hate to realise that their GeForce is actually going to suck to infinity when they thought what they thought to be a boundless graphics card for the Linux desktop. It's not their fault for not being able to look in the future, but it is pathetic human instinctive/standard behavior to start hating the fortunate people.

BlackStar is just a troll nontheless, but is not always wrong.

I paid 100 bucks for my GeForce and it's working out for me

I figure it'll be done in a few years from when I bought it (Though it's already been two), so yeah. Worked out fine.

[V!NCENT]

I figure it'll be done in a few years from when I bought it (Though it's already been two), so yeah. Worked out fine.

And if a good FLOSS Flash replacement (in some areas) were to act a State Tracker, where would that leave your GeForce?


---


BTW Gallium is not a Mesa replacement, but I'm tired of explaining again... and again... and again... what it is and what it's for. We should make a Gallium3D sticky!

[NoEffex]

And if a good FLOSS Flash replacement (in some areas) were to act a State Tracker, where would that leave your GeForce?


---


BTW Gallium is not a Mesa replacement, but I'm tired of explaining again... and again... and again... what it is and what it's for. We should make a Gallium3D sticky!

Then I wouldn't use flash LOL

[V!NCENT]

Then I wouldn't use flash LOL

Fair enough

[bridgman]

There is a sticky... I just can't edit the damn thing any more

http://www.phoronix.com/forums/showthread.php?t=7032

hi, as was mentioned before i thought that gallium was created to make things simple, and to implement features htat might not be native to the hardware.
and talking of that. i thought that there would be a VDPAU state tracker (even for ati cards) to resolve the discussion about flash-y things.

Gallium3D is a new low-level API to encapsulate the functionality of a modern shader-based GPU and allow the same functionality to be shared by multiple high-level APIs (state trackers). First step is to get the existing high level APIs running over Gallium3D drivers.

somehow gallium starts sounding to me like another mesa version. why are there so many other things apart from opengl and directX. are they not up to the task? what is gallium? what is mesa then? why DRI and DRM...??? which one adresses to the hardware directly? sounds like a lot of redundancy to me...

Mesa implements an OpenGL-like API and has an existing HW driver layer. For each GPU, common mesa code makes up 90-95% of the "Mesa driver" while the HW-specific driver code provides the other 5-10%. Gallium3D drivers replace the HW driver layer (only used for Mesa) with a new driver layer useable by other state trackers, but does not replace the other 90-95% of Mesa.

3D graphics operations used to go through the X server, then the X server would call Mesa. Running 3D calls through the X server allowed X to manage windows and Mesa to draw into those windows, but with some overhead. The Direct Rendering Infrastructure (DRI) was developed to let applications call Mesa directly and have Mesa check with the X server to see if the target window had moved since the last call. The Direct Rendering Manager (DRM) is the kernel driver which makes up part of the Direct Rendering Infrastructure.

DRI is a protocol; DRM is a driver component.

[Xake]

Now give me Coreboot and I'll jump through the roof

I second that, my friend.