/tech/ - Technology

Where proprietary software comes to die

Posting mode: Reply

Name
Email
Subject
Comment
Password
Drawing x size canvas
File(s)

Remember to follow the rules

Max file size: 350.00 MB

Max files: 5

Max message length: 4096

Manage Board | Moderate Thread

Return | Catalog | Bottom

Expand All Images


(187.43 KB 1920x1080 dhkq63pki5wkts1ej.jpg)
Gallium Nine Anonymous 04/17/2017 (Mon) 14:05:12 [Preview] No. 8339
Can anyone here explain gallium nine to me please? I have been looking it up but the information is somewhat vague.
From what I gather, it passes data from directx emulation straight to the GPU via a mesa function, without translating it to OpenGL. Essentially a passthrough of some kind for wine.

Are all d3d9 capable radeon cards compatible? Is this the standard Mesa shipped with most distros or do you get a special version from somewhere?
More complicated: How can Mesa (an opengl implementation) pass direct information like that? Doesn't that go against what OpenGL does by design? Shouldn't this technically be for Vesa or whatever driver actually interacts with the hardware?


Anonymous 04/19/2017 (Wed) 05:02:03 [Preview] No. 8355 del
Gallium nine is a linux native implementation of the directx9 api. No translation required. Any radeon or Nvidia card is compatible as long as it's using their open source drivers and Mesa is compiled with gallium enabled.

Mesa is no longer just an opengl implementation. For example, it also contains a vulkan implementation (radv).


Anonymous 04/19/2017 (Wed) 13:48:32 [Preview] No. 8357 del
>>8339

Gallium Nine is a state tracker implementation for the Gallium3D infrastructure presenting a Direct3D 9 API. As >>8355 says it's a "native" implementation, no emulation, no translation. It can work in other kernels too, not just Linux.

>Are all d3d9 capable radeon cards compatible?
"d3d9 capable" is marketing speak directed at windoze customers. Irrelevant. The smart question to ask is: is the GPU supported by a Gallium3D Mesa driver?

>Is this the standard Mesa shipped with most distros or do you get a special version from somewhere?
Gallium Nine was merged into upstream Mesa back in the 10.4 release (I think). So it should be available in all Gallium drivers shipped by current distros.

However, making use of Gallium Nine from Wine requires cooperation from Wine itself: it needs to know that it should look for, find, and prefer the native implementation provided by the DRI driver instead of the translation to OpenGL normally done by Wine. As of late 2016 the upstream Wine maintainer has refused merging the patches implementing this functionality. AFAIK, this hasn't changed in the last few months. Therefore, while you most likely can use your distro-supplied Mesa drivers, you will probably need to either compile your own Wine with the patches applied, or grab pre-patched binaries from somewhere (PPA, OBS, Copr, whatever).

>More complicated: How can Mesa (an opengl implementation)
Mesa hasn't been "just" an OpenGL implementation for a long time. Mesa is more like a software laboratory, or culture medium, or factory, for experimenting with, growing, and assembling (the userspace parts of) graphics-acceleration drivers.

>pass direct information like that? Doesn't that go against what OpenGL does by design? Shouldn't this technically be for Vesa or whatever driver actually interacts with the hardware?
What information? What is "like that"? What do you think "OpenGL does by design"? Vesa? I don't think you understand many of the words you use...

In any case, Mesa drivers talk to the kernelspace part of DRI, DRM, in order to reach the hardware.


Anonymous 04/20/2017 (Thu) 08:12:31 [Preview] No. 8363 del
>>8357
>>pass direct information like that? Doesn't that go against what OpenGL does by design? Shouldn't this technically be for Vesa or whatever driver actually interacts with the hardware?
>What information? What is "like that"? What do you think "OpenGL does by design"? Vesa? I don't think you understand many of the words you use...
Because OpenGL is designed to go via the kernel rather than interface directly with the hardware, unlike directx. Vesa for example, a graphics driver, would though. By information, I'm only making a vague guess about what that actually is as I don't know anything about directx but I have read "d3d" data is passed direct to hardware by directx and in my ignorance I assumed that Mesa must also somehow do the same. This is also why I asked if a card had to be d3d9 capable, because I assumed it received the data directly, which I still assume it does rather than being translated in some way?

>>8357
>>8355
Thank you both btw.


Anonymous 04/20/2017 (Thu) 15:56:08 [Preview] No. 8365 del
>>8363
>Because OpenGL is designed to go via the kernel rather than interface directly with the hardware, unlike directx.
this is pure nonsense
first: directx != direct3d
second: of course both apis "go via the kernel"!
and nobody had to spend much thought to "design" them that way, because what else would you expect? that's what a os kernel does, it multiplexes access to hardware! (which is why dos doesn't count as a real os btw)

>Vesa for example, a graphics driver, would though.
"vesa" is not a graphics driver
you don't know what you're saying

>By information, I'm only making a vague guess about ........
a gpu, even one that only advertises "direct3d capable" is not a "magical direct3d box"

a gpu is at its heart a collectionm of processors (mostly vector/superscalar/superpipelined architectures), some of them are fixed-function, some special-purpose, some general-purpose

a gpu driver will literally program those processors (the ones that are programmable anyway) in order to perform the intended "graphics processing", although it doesn't have to be "graphics"

these are not quite "direct3d" processors or "opengl" processors, they have their own architectures, isas, features, and limitations, much like a in a cpu

if the gpu vendor claims to support some particular api then it's natural for the hardware to be particularly well-suited to that api, but that does not mean one cannot use them to program and run other stuff (unless it's being artificially restricted, for example through firmware, because they have frmware, and can have nonvolatile memory, and of course can dma straight to your ass, plus gpu drivers are ridiculously complex, and humans don't know how to write secure programs... really, if you are running gigabytes of proprietary binary shit, aka vidya, just use windoos, you're hosed in either case)

anyway, every gpu driver (that i know about, and i'm talking about graphics accelerators , not random video/display hardware) will lower opengl/vulkan/direct3d/opencl/cuda/whathaveyou into so form of code+data to feed the gpu's processors

so what's gets "sent to the hardware" depends mostly on the driver, and what can actually be done with it depends on the hardware characteristics, the firmware, documentation... well, the same as a cpu


Anonymous 04/21/2017 (Fri) 14:27:52 [Preview] No. 8374 del
>>8365
That was informative, ty. Clearly I had no idea how directx functions, not sure how I got the idea d3d data was passed direct to the driver. I think I read it once in a directx to opengl comparison forum post, blind leading the blind I guess.

Also, just as a side note, vesa is a driver.



Top | Return | Catalog | Post a reply