02:39mareko: Frogging101: you can ask Felix
03:56Hazematman: Has anyone tried the nir backend on a radeon hd 4xxx gpu? I was just testing it with a hd 4890 and I was expecting to get higher than OpenGL 3.3 support reported, but glxinfo is reporting Max core profile version: 3.3. I built the latest mesa from source which afaik shouldn't require the R600_DEBUG flag anymore. Is this GPU limited to 3.3?
04:01airlied: hd4xxx should be GL3.3 afaik
04:06Hazematman: airlied: darn, do you know if its because of hardware limitations?
04:07airlied: pretty sure
04:08airlied: 4xxx can't do tessellation
04:33Hazematman: Looks like there is a quite a bit more features missing for GL4+ support https://pastebin.com/UCAR2sh7. Not sure how many of them are hardware limitations though. Thanks for answering my question airlied! :)
14:41FLHerne: Hazematman: compare "TODO" vs "N/A" in the table here https://www.x.org/wiki/RadeonFeature/#featurematrixforfreeradeondrivers
14:43FLHerne: (4890 is R700)
14:43FLHerne: the table might be a bit outdated, but the hardware capabilities haven't changed
14:53Hazematman: Thanks FLHerne! Any idea why OpenCL is listed as "TODO" on r600/r700 but Compute Shaders are listed as "N/A"
15:14Hazematman: On the gallium compute (https://dri.freedesktop.org/wiki/GalliumCompute/) page it says this for r700 "6 Only partial OpenCL support is possible, support through vertex shaders. " So I guess that's why :P still weird that OpenCL is listed as TODO for r600/r700
17:49FLHerne: Hazematman: nope :p
17:51FLHerne: it's quite an old table, people were more naïve about OpenCL back then I guess
17:51FLHerne: I'll be absolutely astonished if someone tries to make rusticl work on HD4000
18:09Remco: FLHerne: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7420
19:13FLHerne: huh
19:21Remco: I think the major thing is that those cards have clover support. They want to remove clover, but that means having opencl support another way. Which means rusticl
19:21Remco: It'll take a while though
19:50agd5f: Hazematman, you could implement CL using the GFX pipe so it's basically just a passthrough to one of the shader stages
19:51agd5f: that's basically what we did for OpenCL on r7xx
19:55Hazematman: Hey agd5f yeah I saw something like that in the evergreen/cayman docs (http://developer.amd.com/wordpress/media/2013/10/evergreen_cayman_programming_guide.pdf) they say you can use export shaders (which I understand to just be the vertex shader) as compute shaders on r7xx. I'd like to see if I could get `GL_ARB_compute_shader` working on r7xx following this approach :P
19:57airlied: Hazematman: I don't think it'll work for that extension, like CL 1.0 was very limited on purpose to allow hacks like that
20:01Hazematman: Do you have any ideas on what specifically wouldn't work?
20:02airlied: at a guess shared memory
20:08Hazematman: could you not (ab)use one of the other memory types for shared memory in r7xx? Like scratch, stream, ring, or export? I don't really know what I'm doing, but just wanted to see what's possible?
20:09airlied: maybe you could do something with scratch as a fake slow shared
20:09airlied: but also for compute you want ssbo which I don't think the hw can do either
20:13airlied: also wsi seems to say everyone supports present
20:14airlied: vkGetPhysicalDeviceSurfaceSupportKHR lacks any info