Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 51

Thread: R600 Gallium3D LLVM Shader Compiler Hooked Up

  1. #21
    Join Date
    Oct 2011
    Location
    Toruń, Poland
    Posts
    160

    Default

    Quote Originally Posted by V!NCENT View Post
    Just curious... Is r600 simply not very OpenCL friendly (needing some wierd and ugly hacks?)?

    (I roll on Evergreen for now)
    Huh? All I can see here are difficulties with alignment of two project's schedules. Nothing of concern for end users.

  2. #22
    Join Date
    Jun 2009
    Posts
    1,121

    Default

    Quote Originally Posted by Qaridarium View Post
    yes yes i know i need to buy new hardware

    "the new opensource hacker slogan "buy new hardware" instead of "write better code""

    buy new hardware is always the solution you don't need to write any code you can buy new hardware all the time!

    and if you do have a bug? buy new hardware!

    new hardware is really to cheap no one write software anymore they all buy new hardware to fix there problems.
    don't be an ass if you don't have the knowledge to backup your attitude plz, first educate yourself and then whine. now to topic

    opencl Support in the HD 4XXX and below is just halfway done in hardware(no driver or conspiracy HARDWARE) which means is not impossible ofc but require some really nasty hacks
    and emulations (massive hit in performance). evergreen and superior on the other hand offer full support in hardware for gpu computing(no hacks or conspiracy the HARDWARE pieces just are there).

    so it makes a LOT of sense to start where the hardware fully support opencl and once finished and tested THEN start to think in how to get done the horrible hacks needed to support previous generations

    so for now it won't appear on the todo list since the performance hit is massive enough to be more effective to do opencl on the cpu than in most of the 4xxx cards (maybe excepting the 4870/90 OC cards)

    so is not conspiracy or evil corporate agenda is just too hard for a very small gain, so if you need opencl performance an 5700 evergreen card will trash you cpu and hd 4890 together in opencl, so in this case it makes sense to suggest to get a bit better card that offer full hardware support so you can have a noticeable performance gain.

    if you can't upgrade or won't upgrade then just wait until clover matures and someone decide to create the infrastructure needed to emulate the missing hardware pieces in the 4000 series GPU(and maybe other GPU's)

  3. #23
    Join Date
    Oct 2009
    Location
    Brisbane, Queensland, Australia
    Posts
    154

    Default

    In related news, the The Khronos WebCL Working Group has announced the availability of the first WebCL public working draft - see https://cvs.khronos.org/svn/repos/re...est/index.html

    The abstract reads:
    This Working Draft defines WebCL (Web Computing Language). WebCL is a JavaScript binding to the Khronos OpenCL standard for heterogeneous parallel computing. It enables web applications to harness GPU and multi-core CPU parallel processing from within a Web browser, enabling significant acceleration of computationally intensive applications, such as image and video processing and advanced physics for WebGL games.

  4. #24
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    506

    Default

    Quote Originally Posted by Pontostroy View Post
    I use trank LLVM-3.2_svn20120421

    Lightmark warning message:
    warning: failed to translate tgsi opcode F2I to LLVM
    warning: failed to translate tgsi opcode F2I to LLVM
    et:qw
    pure virtual method called
    terminate called recursively
    terminate called recursively
    pure virtual method called
    terminate called recursively
    pure virtual method called
    Segmentation fault
    Compiling mesa git master, along with LLVM git release_31 branch, got me this errors:
    /gpgpu-test is where I will put new LLVM and MESA, so I will not break existing environment. Any clues?

    mklib: Making Linux shared library: r600_dri.so.tmp
    g++ -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0301 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp -L../../../../lib -Wl,-R/gpgpu-test/lib/dri -ldricore -lglsl -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon -L/gpgpu-test/lib -ldl -lpthread;
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::SelectionDAGISel'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetInstrInfoImpl'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MachineModuleInfoImpl'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetPassConfig'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MCAsmInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetELFWriterInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetSubtargetInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::LLVMTargetMachine'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MachineFunctionInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetFrameLowering'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MachineFunctionPass'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetIntrinsicInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetRegisterInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetLowering'

  5. #25
    Join Date
    Feb 2011
    Location
    Ukraine
    Posts
    132

    Default

    Quote Originally Posted by Drago View Post
    Compiling mesa git master, along with LLVM git release_31 branch, got me this errors:
    /gpgpu-test is where I will put new LLVM and MESA, so I will not break existing environment. Any clues?

    mklib: Making Linux shared library: r600_dri.so.tmp
    g++ -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O2 -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0301 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp -L../../../../lib -Wl,-R/gpgpu-test/lib/dri -ldricore -lglsl -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon -L/gpgpu-test/lib -ldl -lpthread;
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::SelectionDAGISel'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetInstrInfoImpl'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MachineModuleInfoImpl'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetPassConfig'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MCAsmInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetELFWriterInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetSubtargetInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::LLVMTargetMachine'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MachineFunctionInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetFrameLowering'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::MachineFunctionPass'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetIntrinsicInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetRegisterInfo'
    r600_dri.so.tmp: undefined reference to `typeinfo for llvm::TargetLowering'
    I use shared llvm and --with-llvm-shared-libs for mesa

    Code:
    make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/mesa/src/gallium/targets/dri-r600'
    gcc -c -I. -I../../../../src/mesa/drivers/dri/common -Iserver -I../../../../include -I../../../../include/GL/internal -I../../../../src/mapi -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/winsys -I../../../../src/mesa -I../../../../src/mesa/main -I../../../../src/mesa/math -I../../../../src/mesa/transform -I../../../../src/mesa/shader -I../../../../src/mesa/swrast -I../../../../src/mesa/swrast_setup -I../../../../src/egl/main -I../../../../src/egl/drivers/dri -I/usr/include/libdrm    -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0302 -fvisibility=hidden -DGALLIUM_RBUG -DGALLIUM_TRACE -DGALLIUM_NOOP target.c -o target.o
    /bin/sh ../../../../bin/mklib -o r600_dri.so.tmp -noprefix -linker 'g++' -ldflags ' -L/usr/lib  -lpthread -ldl -lm ' \
    	target.o ../../../../src/mesa/drivers/dri/common/utils.o ../../../../src/mesa/drivers/dri/common/dri_util.o ../../../../src/mesa/drivers/dri/common/xmlconfig.o   ../../../../src/gallium/drivers/r600/libr600.a ../../../../src/gallium/state_trackers/dri/drm/libdridrm.a ../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a ../../../../src/gallium/drivers/trace/libtrace.a ../../../../src/gallium/drivers/rbug/librbug.a ../../../../src/gallium/drivers/noop/libnoop.a \
                    -Wl,--start-group ../../../../src/mesa/libmesagallium.a ../../../../src/gallium/auxiliary/libgallium.a -Wl,--end-group \
                      -L../../../../lib -Wl,-R/usr/lib/dri -ldricore -lglsl  -ldrm   -lexpat -lm -lpthread -ldl -ldrm_radeon -lLLVM-3.2svn
    mklib: Making Linux shared library:  r600_dri.so.tmp
    g++ -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0302 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp  -L../../../../lib -Wl,-R/usr/lib/dri -ldricore -lglsl  -ldrm   -lexpat -lm -lpthread -ldl -ldrm_radeon  -L/usr/lib  -lpthread -ldl -lm ;
    mv -f r600_dri.so.tmp r600_dri.so
    /usr/bin/install -c r600_dri.so ../../../../lib/gallium

  6. #26
    Join Date
    May 2009
    Location
    Richland, WA
    Posts
    134

    Default

    This paper might be interesting for people involved in OpenCL for single precision GPUs. Its about using single precision math in a GPU to get a close answer and then using double precision in the CPU to correct for the error. They were able to get full double precision accuracy with a 2X speed up over CPU alone.
    http://www.mpi-inf.mpg.de/~strzodka/...Tu05double.pdf

    So I guess someone could write a wrapper doing the same thing for some of the OpenCL double precision functions.

  7. #27
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by jrch2k8 View Post
    don't be an ass if you don't have the knowledge to backup your attitude plz, first educate yourself and then whine. now to topic

    opencl Support in the HD 4XXX and below is just halfway done in hardware(no driver or conspiracy HARDWARE) which means is not impossible ofc but require some really nasty hacks
    and emulations (massive hit in performance). evergreen and superior on the other hand offer full support in hardware for gpu computing(no hacks or conspiracy the HARDWARE pieces just are there).

    so it makes a LOT of sense to start where the hardware fully support opencl and once finished and tested THEN start to think in how to get done the horrible hacks needed to support previous generations

    so for now it won't appear on the todo list since the performance hit is massive enough to be more effective to do opencl on the cpu than in most of the 4xxx cards (maybe excepting the 4870/90 OC cards)

    so is not conspiracy or evil corporate agenda is just too hard for a very small gain, so if you need opencl performance an 5700 evergreen card will trash you cpu and hd 4890 together in opencl, so in this case it makes sense to suggest to get a bit better card that offer full hardware support so you can have a noticeable performance gain.

    if you can't upgrade or won't upgrade then just wait until clover matures and someone decide to create the infrastructure needed to emulate the missing hardware pieces in the 4000 series GPU(and maybe other GPU's)
    no conspiracy you say? i know better than you the nvidia GTX8800 do have full openCL support 100% full and its the same age like the "hd2900"

    thats because apple let nvidia make the openCL spec this means nvidia build all nvidia spezific buffers into the spec this means the hd2900 do not have 2 buffers. the hd4000 do have both buffers but one of them are to smal/wrong implemenation because of wrong information from nvidia.

    in the end it is a conspiracy from nvidia to hurt ATI/AMD hardware users!

    because of this nvidia cards like the gtx8800 are full compatible without any hacks and the amd cards need software emulations of 2 buffers in the vram means slow slow slow. the hd5000 series is 3-4 years later than the gtx8800.

    great success to nvidia to hurt ati/amd users.

  8. #28
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    506

    Default

    Quote Originally Posted by Pontostroy View Post
    I use shared llvm and --with-llvm-shared-libs for mesa

    Code:
    make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/mesa/src/gallium/targets/dri-r600'
    gcc -c -I. -I../../../../src/mesa/drivers/dri/common -Iserver -I../../../../include -I../../../../include/GL/internal -I../../../../src/mapi -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/winsys -I../../../../src/mesa -I../../../../src/mesa/main -I../../../../src/mesa/math -I../../../../src/mesa/transform -I../../../../src/mesa/shader -I../../../../src/mesa/swrast -I../../../../src/mesa/swrast_setup -I../../../../src/egl/main -I../../../../src/egl/drivers/dri -I/usr/include/libdrm    -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0302 -fvisibility=hidden -DGALLIUM_RBUG -DGALLIUM_TRACE -DGALLIUM_NOOP target.c -o target.o
    /bin/sh ../../../../bin/mklib -o r600_dri.so.tmp -noprefix -linker 'g++' -ldflags ' -L/usr/lib  -lpthread -ldl -lm ' \
    	target.o ../../../../src/mesa/drivers/dri/common/utils.o ../../../../src/mesa/drivers/dri/common/dri_util.o ../../../../src/mesa/drivers/dri/common/xmlconfig.o   ../../../../src/gallium/drivers/r600/libr600.a ../../../../src/gallium/state_trackers/dri/drm/libdridrm.a ../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a ../../../../src/gallium/drivers/trace/libtrace.a ../../../../src/gallium/drivers/rbug/librbug.a ../../../../src/gallium/drivers/noop/libnoop.a \
                    -Wl,--start-group ../../../../src/mesa/libmesagallium.a ../../../../src/gallium/auxiliary/libgallium.a -Wl,--end-group \
                      -L../../../../lib -Wl,-R/usr/lib/dri -ldricore -lglsl  -ldrm   -lexpat -lm -lpthread -ldl -ldrm_radeon -lLLVM-3.2svn
    mklib: Making Linux shared library:  r600_dri.so.tmp
    g++ -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0302 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp  -L../../../../lib -Wl,-R/usr/lib/dri -ldricore -lglsl  -ldrm   -lexpat -lm -lpthread -ldl -ldrm_radeon  -L/usr/lib  -lpthread -ldl -lm ;
    mv -f r600_dri.so.tmp r600_dri.so
    /usr/bin/install -c r600_dri.so ../../../../lib/gallium
    I didn't provided `--with-llvm-shared-libs` to Mesa, but this type information tells something else. Any other flags you may passed to LLVM or MESA. Enabling RTTI or something else?

  9. #29

    Default

    Quote Originally Posted by Qaridarium View Post

    thats because apple let nvidia make the openCL spec this means nvidia build all nvidia spezific buffers into the spec this means the hd2900 do not have 2 buffers. the hd4000 do have both buffers but one of them are to smal/wrong implemenation because of wrong information from nvidia.

    And a whole lot of other stupid and misspelled shit.
    If that where the case Apple would be backing CUDA, not OpenCL. CUDA is Nvidia exclusive, had Nvidia written the OpenCL spec they'd have done all they could to gimp it so that everyone would ignore in completely and use CUDA which only works on Nvidia hardware.

  10. #30
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,044

    Default

    So I checked llvm out from http://llvm.org/svn/llvm-project/llv...ELEASE_31/rc1/ and compiled mesa with it.

    The first thing I tested was kwin "opengl2 shaders". With luck it seems to work but mostly it looks like this:

    and crashes plasma.

    struntrally cannot start a map:
    Code:
    LLVM ERROR: Cannot select: target intrinsic %llvm.AMDGPU.kill
    xonotic... well....


    Maybe it would be good to only whitelist cards where it at least kind of works.

    I tried on HD 6550M.
    Last edited by ChrisXY; 04-25-2012 at 07:18 AM.

Posting Permissions

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