Page 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: OpenGL 4.4 ARB_buffer_storage Comes To Radeon Gallium3D

  1. #21
    Join Date
    Nov 2012
    Location
    France
    Posts
    459

    Default

    Quote Originally Posted by przemoli View Post
    Not entirely true.

    Getting code to be opensourced would be hard. But they could and did, release their binaries for GPUs.

    Look at /lib/firmware/radeon. There should be plenty of files there.
    These files don't seem to be readable.

  2. #22
    Join Date
    Mar 2012
    Posts
    218

    Default

    Quote Originally Posted by Calinou View Post
    These files don't seem to be readable.
    cause they are binaries and not available as source code. they remain closed source.

  3. #23
    Join Date
    Jan 2013
    Posts
    906

    Default

    Quote Originally Posted by tomtomme View Post
    yeah thanks, I forgot about those.
    However, do you know if those binaries much work? They seem to be small compared to mesa. So rewriting those as FOSS would not have added much further delay (ignoring the fact that AMD does not want to open source those).
    They are required for everything 3d.
    Its not clear of the intent of not getting rid of microcode the way nouveau did it.
    Security risk is present.

  4. #24
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,280

    Default

    Microcode is required for pretty much everything these days. Even the memory controller.

    This is no different than HW from other vendors. The only difference is that you can *see* AMD microcode binaries, so they bother you more

  5. #25
    Join Date
    Mar 2012
    Posts
    218

    Default need more information on microcode :)

    Quote Originally Posted by bridgman View Post
    Microcode is required for pretty much everything these days. Even the memory controller.

    This is no different than HW from other vendors. The only difference is that you can *see* AMD microcode binaries, so they bother you more
    Dear Mr. Bridgman,

    if we would better understand what this "microcode" means and does and why its needed - and why in contrast its not needed for noveau - we maybe would not be bothered that hard. Myths can only dispel through education. So maybe you have the time and the rights to tell us some more details? Or at least post a link with further readings? That would be very nice!

    sincerely, tomme

  6. #26
    Join Date
    Jul 2010
    Posts
    440

    Default

    Microcode is a binary that doesn't run on the system's CPU, your computer just dumps it straight onto the hardware. The hardware then executes it.

    Some hardware has the microcode permanently burned-in, on the one hand this means that there are no microcode files to worry about, on the other hand, the same code is still running, but it can never be updated. Obviously that can be problematic if a bug is found later (it would require a workaround in the driver, which runs on the system CPU).

    As far as I'm aware nouveau also needs microcode, but generates said microcode itself.

    Mr. Bridgman has posted details about microcode before, somewhat more eloquently than I have here, searching will probably get you a better explanation.

  7. #27
    Join Date
    Oct 2008
    Posts
    2,904

    Default

    Quote Originally Posted by tomtomme View Post
    Dear Mr. Bridgman,

    if we would better understand what this "microcode" means and does and why its needed - and why in contrast its not needed for noveau - we maybe would not be bothered that hard. Myths can only dispel through education. So maybe you have the time and the rights to tell us some more details? Or at least post a link with further readings? That would be very nice!

    sincerely, tomme
    Nouveau does need it, and so does tons of other hardware.

    As for what it is - here is the wikipedia entry:

    Microcode is a layer of hardware-level instructions or data structures involved in the implementation of higher level machine code instructions in central processing units, and in the implementation of the internal logic of many channel controllers, disk controllers, network interface controllers, network processors, graphics processing units, and other hardware. It resides in special high-speed memory and translates machine instructions into sequences of detailed circuit-level operations. It helps separate the machine instructions from the underlying electronics so that instructions can be designed and altered more freely. It also makes it feasible to build complex multi-step instructions while still reducing the complexity of the electronic circuitry compared to other methods. Writing microcode is often called microprogramming and the microcode in a particular processor implementation is sometimes called a microprogram.

    Modern microcode is normally written by an engineer during the processor design phase and stored in a ROM (read-only memory) or PLA (programmable logic array)[1] structure, or a combination of both.[2] However, machines also exist which have some (or all) microcode stored in SRAM or flash memory. This is traditionally denoted a "writeable control store" in the context of computers. Complex digital processors may also employ more than one (possibly microcode based) control unit in order to delegate sub-tasks which must be performed (more or less) asynchronously in parallel. Microcode is generally not visible or changeable by a normal programmer, not even by an assembly programmer. Unlike machine code which often retains some compatibility among different processors in a family, microcode only runs on the exact electronic circuitry for which it is designed, as it constitutes an inherent part of the particular processor design itself.

    More extensive microcoding has also been used to allow small and simple microarchitectures to emulate more powerful architectures with wider word length, more execution units and so on; a relatively simple way to achieve software compatibility between different products in a processor family.

    Some hardware vendors, especially IBM, use the term as a synonym for firmware, so that all code in a device, whether microcode or machine code, is termed microcode (such as in a hard drive for instance, which typically contains both).
    Last edited by smitty3268; 02-27-2014 at 02:23 PM.

  8. #28
    Join Date
    Oct 2008
    Posts
    2,904

    Default

    Quote Originally Posted by brosis View Post
    They are required for everything 3d.
    Its not clear of the intent of not getting rid of microcode the way nouveau did it.
    Security risk is present.
    Just to clarify, nouveau did not get rid of microcode. They just reverse engineered it out of the blob, so that they had their own copy that was redistributable.

    It's not like they translated it into c code or anything readable (the nature of microcode makes that impossible), it's still a big unreadable blob. If there was a security bug in the original nvidia blob it will still be there in nouveau too, and it's likely not going to get updated if nvidia ever finds something and fixes it in their upstream drivers.

  9. #29
    Join Date
    Jan 2013
    Posts
    16

    Default

    Amd and Intel CPUs use microcode blobs that are encrypted and get uploaded by the BIOS and/or the OS during boot.
    But from my uneducated reading, the radeon drivers seem to contain a lot of magic numers in the source.

  10. #30
    Join Date
    Jan 2013
    Posts
    16

    Default

    Wanted to play around with ARB_buffer_storage the days, but then noticed no AMD support on the closed driver. :*(

    Quote Originally Posted by AnonymousCoward View Post
    FGLRX and Windows have AMD_Pinned_Memory as an alternative, which essentially does the same thing as ARB_buffer_storage. Although the implementation has some differences I believe.
    As far as I understand the AMD_Pinned_Memory is always system memory and not vram. Therefore it has to go over the bus for every draw call (or for whatever you may use the buffer). But you control the syncing! And this may already be the best option for APUs that share system memory and cache.
    ARB_buffer_storage may give you raw read and write access to vram and you also control all of the syncing! (But the standard does not guarantee that you get raw vram access and can fall back using system memory or may even use an in-between buffer like you currently get wiht uploads to buffer objects :[ )

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •