Announcement

Collapse
No announcement yet.

Lightspark May Work Towards A Gallium3D State Tracker

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Xake
    replied
    Originally posted by V!NCENT View Post
    Now give me Coreboot and I'll jump through the roof
    I second that, my friend.

    Leave a comment:


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

    OK, let's see. Let me do the AtomBIOS part first, it's shorter. There have always been debates in the driver development world (both open and closed source) about


    Originally posted by jakubo View Post
    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.

    Originally posted by jakubo View Post
    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.

    Leave a comment:


  • V!NCENT
    replied
    Originally posted by NoEffex View Post
    Then I wouldn't use flash LOL
    Fair enough

    Leave a comment:


  • NoEffex
    replied
    Originally posted by V!NCENT View Post
    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

    Leave a comment:


  • V!NCENT
    replied
    Originally posted by NoEffex View Post
    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!

    Leave a comment:


  • NoEffex
    replied
    Originally posted by V!NCENT View Post
    @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.

    Leave a comment:


  • jakubo
    replied
    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...

    Leave a comment:


  • V!NCENT
    replied
    @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.

    Leave a comment:


  • wirrbeltier
    replied
    Maybe it's a foolish thing to ask, but did anybody actually bother to read the blogpost?
    I got the impression that this is just a quick notation of an idea of one of the developers, looking for a less overkill way to get the drawing actions to the GPU.
    Perhaps a Gallium state tracker isn't the best idea (the comments were quick to propose something like letting the cairo GL backend do the work); but it would be definitely easier than using openGL anyway.

    But i guess the trolls here are up to something: with Gallium being the buzzword in open-source graphics, more developers are going to consider writing their own state trackers, custom-tailored to their needs.
    My 2 cents: when the API has become relatively stable, why not let the people have their own state trackers? If this is easier to write (thus easier to maintain) than OGL or GL ES or RandomToolkitBackend, and works rasonably stable, it should be worth a try.

    Leave a comment:


  • V!NCENT
    replied
    Originally posted by fabiank22 View Post
    Troll on bro. Haters gonna hate...

    I also love how you simply quote random strawman fanfiction, heck you even managed to get Hurd in there. Five thumbs up from me
    You must have never heared about the chaos theory, but that's OK; it's merely and indication for how fucking stupid you are.

    BTW you'd all be crying like cry babies if Gallium3D was never created, simply because of the fact that you'd be stuck with a fixed pipeline solution from the stoneage.

    Same goes for PulseAudio and D-bus; without it the best the Linux desktop was to pull of was surround sound and that'd be pretty much it. However ignoring that a great working audio card costs only 15 dollars max, you keep whining about the fact that it doesn't work, but then turn around to spend 250 dollars on an nVidia card because it all works so fucking great.

    And now I am the troll. Tell that to AMD who moves towards Gallium3D. Maybe, instead of my sorry ass that you can lick you mutherfucker, they know better than you.

    End of fucking story.

    Leave a comment:

Working...
X