<HdkR>
Feels like a wayland compositor coudl do the simple thing, detect a full screen application and do optimus magic? :D
<HdkR>
Only switches between fullscreen and not. Which is all I would care about anyway
<airlied>
but what about when my discord pops up :-P
<airlied>
can you even play games nowadays without having discord open?
igrtrrnt has quit [Remote host closed the connection]
<HdkR>
Flicker flicker flicker time?
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
nchery has quit [Quit: Leaving]
<milek7>
so it does switch output and existing applications using gpu whose output is being disabled are migrated to PRIME?
<airlied>
milek7: the BIOS setting just does it once at boot, and locks it in
<airlied>
the dynamic one tries to migrate applications (it usually sends DEVICE_LOST type signals)
<airlied>
and apps have to restart
co1umbarius has joined #dri-devel
<milek7>
if it requires app restart it doesn't sound very useful...
<HdkR>
Useful if you setup app profiles for the dGPU
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<HdkR>
Which as a gamer is what I expect to do every time in a mixed GPU system
columbarius has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<airlied>
yeah the app would just run on the dGPU always for profiled apps
<milek7>
yeah but that means starting up game will kill other applications? (except those that can deal with losing device, but I think they are a minority)
pushqrdx has joined #dri-devel
<HdkR>
Do the runtime switchable ones even work on Linux atm? It will always incur copies across to the presenting device.
<airlied>
nope they don't work on Linux, unless someone has created a new compositor to do it
<HdkR>
womp womp
co1umbarius has quit [Ping timeout: 480 seconds]
idr has quit [Quit: Leaving]
ybogdano has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Company has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
Namarrgon has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.2]
angerctl has quit [Ping timeout: 480 seconds]
ybogdano has quit [Read error: Connection reset by peer]
gpuman has quit []
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
DanaG has joined #dri-devel
<DanaG>
What would it take for AST to gain the ability to be an output for PRIME? I have a Radeon Pro WX 4100 and an ASPEED (more like ASLOW) BMC in a server machine, and I'd like to be able to offload rendering. Currently, xrandr sees both listed in listproviders, but only the radeon has any capabilities, and xrandr only shows the outputs from that device.
<airlied>
ast doesn't have any acceleration features
<airlied>
it might be possible to add kernel code to have it operate like usb scanout
<DanaG>
With Windows, depending on whether you install the WDDM driver for ASPEED, you can clone from Radeon to ASPEED, but it's incredibly slow (massively cuts the frame rate). And I can't remember whether installing the driver adds, or removes, that cloning ability.
<DanaG>
To make it usable on Linux, you'd probably have to do something like: only copy every second (or third or fourth or whatever) frame.
<DanaG>
It actually slowed down the frame rate of rendering, not just the output on the ASPEED.
<DanaG>
The ultimate goal would be to have the thing usable remotely (slowly) most of the time, and if I feel like connecting a monitor once in a while, I can use that.
<DanaG>
Also odd: this board seems to have the AST configured to pass through a fixed 1024x768 EDID instead of whatever's actually attached externally.
<airlied>
yeah it would be horribly slow to try to use as an offload
<DanaG>
I wish somebody would make a new version of the old Radeon-based BMCs. Keep the 2D stuff, ditch the 3D stuff, and allow offload. I once tried putting a Radeon in a machine with such a BMC, but the BIOS didn't like it, so I couldn't see if offload worked.
<HdkR>
Why try to offload through aspeed? Just to get the rendered visuals through the ipmi/BMC?
<DanaG>
I'd like to have BMC be primary, but still be able to connect a monitor to the Radeon occasionally, and at least be able to switch on the fly, even if not showing both at once.
<airlied>
DanaG: the problem is the CPU has to do a lot of copies over PCIe which pretty much kills the idea of it being useful
<DanaG>
Right now, desktop environments seem to see either only the AST, or only the Radeon. So right now, SDDM won't draw on the BMC.
<airlied>
if you switch the monitor to the radeon, you could use an xorg.conf to run on it
<DanaG>
I think it's probably rendering on the Radeon. Give me a minute and I'll move my monitor's cable...
<DanaG>
Weird, seems like SDDM isn't drawing on either one.
<DanaG>
Okay, after rebooting with monitor connected, now SDDM draws on the Radeon.
DanaG_ has joined #dri-devel
DanaG_ has quit []
DanaG_ has joined #dri-devel
DanaG_ has quit [Remote host closed the connection]
DanaG is now known as Guest2959
Guest2959 has quit [Ping timeout: 480 seconds]
DanaG has joined #dri-devel
camus has joined #dri-devel
<airlied>
mripard: I'm feeling uneasy about the vc4 fixes in misc fixes at this point, what would be the problem leaving them until 5.16?
camus1 has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
jewins1 has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
camus has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
camus has joined #dri-devel
jewins1 has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
lemonzest has joined #dri-devel
Duke`` has joined #dri-devel
dviola has quit [Quit: WeeChat 3.3]
f11f13 has joined #dri-devel
f11f12 has quit [Read error: Connection reset by peer]
dviola has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
unsolo has quit [Ping timeout: 480 seconds]
f11f12 has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
f11f13 has quit [Ping timeout: 480 seconds]
itoral has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
<mareko>
PRIME costs power and adds latency, but not necessarily decreases performance
<imirkin>
mareko: when the CPU has to do the copying?
<airlied>
imirkin: if the CPU is doing the copy you are toast :-P
<imirkin>
airlied: which would be the situation for AST, no?
<HdkR>
But `Fast REP MOVSB` is supposed to be fast :D
<airlied>
HdkR: over a PCIex1 link uncached? :-P
<HdkR>
It has fast in the name. It can't be wrong
<airlied>
you get write combining if you are lucky and ast hasn't screwed up
<imirkin>
HdkR: i think they were just skimping on letters ... they meant "fast*er* rep movsb"
<HdkR>
Dang, ruined
<imirkin>
trying to control printing costs on those manuals...
<HdkR>
Obviously we need to move to the newest ARM platforms since they also have dedicated memcpy and memset instructions now
rasterman has joined #dri-devel
tzimmermann has joined #dri-devel
DanaG has quit [Ping timeout: 480 seconds]
shashank1202 has joined #dri-devel
achrisan has quit []
<mripard>
airlied: they are fixing system-wide, silent, stalls in some corner-cases
<mripard>
but it's not like it's a regression or something I guess, they've been there for a while
<mripard>
as long as I don't get bullied because of it, I'm fine either way
<airlied>
mripard: yeah at this point not fixing regressions is mostly the cut off esp for larger things
<airlied>
let's get them queued into next, once they are rebased out of fixes
unsolo has joined #dri-devel
<airlied>
yay CL test_api all passing with images enabled, but some hacks
<airlied>
and I think test_basic will also pass
<airlied>
dang I see no failure there, ah well next week
<airlied>
ah CL_BGRA 8-bit image writes
<mareko>
imirkin: the improvements we're making for PRIME with radeonsi should close the gap with non-PRIME
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
lynxeye has joined #dri-devel
rgallaispou has joined #dri-devel
frieder has joined #dri-devel
vivijim has joined #dri-devel
pcercuei has joined #dri-devel
mlankhorst has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
Ahuj has joined #dri-devel
dongwonk has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
jcline has quit [Quit: Bye.]
jcline has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
vivijim is now known as Guest2982
vivijim has joined #dri-devel
Guest2982 has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
<pepp>
zmike: thanks for the reminder, I'll take a look soon
JohnnyonFlame has joined #dri-devel
boistordu has joined #dri-devel
<hikiko>
hi, I have some newbie questions: I am trying to change something in kernel side drm (to experiment). It's in i915 and the only intel hardware I have is my laptop (BDW GPU) that doesn't have a serial port! so I wonder if there's any setup or instructions for how to debug the kernel remotely to avoid rebooting all the time.
<hikiko>
but specific to drm
<hikiko>
:s/only/only available
<hikiko>
and that doesn't require serial port so that I can use it with my laptop
<hikiko>
(I am not sure if serial->usb adaptors can work well in this case :s)
tursulin has joined #dri-devel
pnowack has quit [Quit: pnowack]
<FLHerne>
If it's built with CONFIG_USB_SERIAL_CONSOLE=y (and the driver for whichever USB<->serial chip) it should work fine
<FLHerne>
If you're not hanging the whole system, you can use whatever you want over ssh
<FLHerne>
[i.e. if it's just display output that's not working]
<hikiko>
thank you FLHerne! I'll try to enable config_usb_serial_console first :) atm I am not hanging the whole system but I might do so when I start changing more things :D
mlankhorst has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
tursulin has quit [Remote host closed the connection]
itoral has quit []
X-Scale has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
X-Scale has joined #dri-devel
tursulin has joined #dri-devel
frieder has quit [Remote host closed the connection]
Company has quit [Read error: No route to host]
Company has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
nuh^ has joined #dri-devel
nsneck has joined #dri-devel
jewins has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
nsneck has quit [Remote host closed the connection]
The_Company has joined #dri-devel
nsneck has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
<gawin>
is it possible to force tgsi/nir to use only one const per instruction?
<gawin>
background: it's another hardware limitation of r300, actually r300g is rewriting all instructions with 2 const to 2 instructions with one const, but sometimes it can explode.
<gawin>
not sure if implementing optimizations for best variable management (on r300) is worth it, aka code which is doing this can be already somewhere in tgsi/nir
elongbug has quit [Ping timeout: 480 seconds]
<zmike>
pepp: I updated the branch
<imirkin>
gawin: no, tgsi does whatever it wants. the compiler needs to sort those things out...
gouchi has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
Terman has joined #dri-devel
_alice has quit [Quit: irc_error]
_alice has joined #dri-devel
sdutt has joined #dri-devel
fxkamd has joined #dri-devel
_alice has quit []
_alice has joined #dri-devel
MrCooper_ has joined #dri-devel
camus has quit []
camus has joined #dri-devel
nchery has joined #dri-devel
MrCooper has quit [Ping timeout: 480 seconds]
nuh^ has quit [Remote host closed the connection]
nuh^ has joined #dri-devel
kmn has quit [Ping timeout: 480 seconds]
fxkamd has quit []
unsolo has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
<jekstrand>
jenatali: Had to make a couple last-minute changes for bindless yesterday to get it through CI
<jekstrand>
THen someone added a new piglit test that was failing and prevented my attempted merge last night
<jenatali>
Hah of course
<zmike>
so you're saying bindless is broken now
sdutt has quit []
camus has quit []
<jenatali>
Now? :P
sdutt has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
mbrost has joined #dri-devel
aissen_ has quit []
mbrost_ has joined #dri-devel
aissen has joined #dri-devel
camus has joined #dri-devel
hansg has quit [Quit: Leaving]
<mareko>
why does ldconfig create the link libGL -> libGLX_mesa? I thought glvnd had its own version of libGL
mbrost has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
<pepp>
mareko: I don't have a libGL link in my mesa install folder
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
<ajax>
mareko: something about your build setting its soname to libGL.so.1 maybe
<ajax>
not that that should happen, but if it did, it might explain the symlink
mlankhorst has quit [Ping timeout: 480 seconds]
<mareko>
building Mesa with -Dglvnd=true fixed that
illwieckz has quit [Read error: Connection reset by peer]
macromorgan is now known as Guest3016
Guest3016 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<mriesch>
what could DRM_FORMAT_NV12_10 be for a format? i saw it in the rockchip drm downstream driver, it does not seem to be supported by mainline drm.
<mriesch>
(there are also DRM_FORMAT_NV16_10 and DRM_FORMAT_NV24_10)
<jekstrand>
dj-death, bnieuwenhuizen: Queue submit threads need to be common code.
<jekstrand>
I don't know how we're going to do it but it needs to happen
<jekstrand>
If dj-death and I couldn't get it right, my faith in all the other drivers to get it right is weak.
mlankhorst has joined #dri-devel
<jekstrand>
And given that it's required for 1.2, that's a problem
ybogdano has joined #dri-devel
dongwonk has joined #dri-devel
<bnieuwenhuizen>
jekstrand: also time for fences and semaphores to be common code?
<jekstrand>
bnieuwenhuizen: Yup, that'll be a prerequisite
<bnieuwenhuizen>
(challenge would probably be fitting in userspace ptrs for quick fence checking for drivers that have it)
<jekstrand>
bnieuwenhuizen: My current thought is that we'll have syncobj, timeline syncobj, and timeline of syncobj as 100% common implementations.
<jekstrand>
Then we'll have some sort of driver-internal thing
<jekstrand>
ANV still uses BOs for fences in a few cases and RADV has their internal things
<bnieuwenhuizen>
jekstrand: also what ANV queueing bug triggered this? Could check RADV :)
<bnieuwenhuizen>
oh I guess I knew about that one. Thanks!
<jenatali>
jekstrand: Don't want to put too much of a wrench in the plan, but we'd like to play in this space and we'd like to opt out for some of these common impls since Dozen won't be running on a DRM kernel stack
<jekstrand>
jenatali: I intend to keep DRM optional
<jenatali>
Oh awesome
<jekstrand>
jenatali: The tricky thing with dozen is that it doesn't need a submit thread
<jekstrand>
at all
<jenatali>
What's the need for the submit thread?
<jekstrand>
Timeline semaphore wait-before-signal behavior is implemented using a kernel primitive which tracks all the active time points and a userspace submit thread which waits for all the wait points to show up before doing the actual submit.
<jekstrand>
By "show up" I don't mean signaled. I mean some process (possibly not ours) has submitted work which will signal it in future.
<jenatali>
Oh, out of order waits, got it
<jekstrand>
Yeah
<jenatali>
And the submit thread needs to wait for them to become in-order
<jekstrand>
Yup
<jekstrand>
With DXGI monitored fence, we can just submit and let Windows sort it out
<jenatali>
Yeah
<jenatali>
If this was Win7, then you'd have to do the same thing
<jenatali>
In fact... yeah I've built this for 12on7
<jekstrand>
:)
<ajax>
i parsed that as dx12 on dx7 and got very concerned
<jekstrand>
:D
* jekstrand
too
<jenatali>
Heh, yeah, DX12 on Win7
<JoshuaAshton>
DX7 to DX12 time
<jenatali>
That one's done. 9on12 supports all D3D versions older than 10
<jenatali>
DDraw included
<JoshuaAshton>
Oh interesting, didn't know it was all one DDI
<bnieuwenhuizen>
jenatali: okay, now you have me curious, how does that deal with the older style DXGI swapchains?
<jenatali>
Yeah, I think all the old D3Ds were one DDI with just sliding version, up until 10 did a clean break
<bnieuwenhuizen>
(the ones where you can have multiple swapchains per window)
<jenatali>
bnieuwenhuizen: The code that was open-sourced for 9on12 is *slightly* different than what we ship inside Windows. D3D12 technically has support for old-style swapchains just for supporting these layering cases
<bnieuwenhuizen>
ah
<jenatali>
But it's hacky and fragile and doesn't support things like out-of-order waits (that submit thread you're talking about needs to be in kernel to make that work)
Ahuj has joined #dri-devel
<jenatali>
I guess we could do the same thing for the GLOn12 binary we ship through the Store, but right now we're not adding any patches on top of what's upstream
<jenatali>
Hopefully eventually we can figure out a way to make that GDI interop stuff not horrible and it can stop being private
<bnieuwenhuizen>
yeah, just wondering if we have any good ways forward for d9vk
<bnieuwenhuizen>
but sounds squarely into the "another extension" territory
<jenatali>
Remind me, what's wrong with d9vk?
<bnieuwenhuizen>
d3d9 on top of vulkan, vulkan having approx the same swapchain issues as d3d12
<jenatali>
Ahh, gotcha
<mareko>
bnieuwenhuizen: queue submit thread? to hide kernel overhead?
<bnieuwenhuizen>
so some games doing shared swapchain for a single window fun (especially wrt video playback) is kinda a painpoint
<bnieuwenhuizen>
mareko: for wait-before-submit of syncobj
<bnieuwenhuizen>
thread waits until the operation signalling the syncobj is submitted
<jenatali>
Yeah. Do you support flight sim?
<bnieuwenhuizen>
IIRC the new one runs reasonably well, no idea about the prev. one
<jenatali>
The new one would be vkd3d-proton I expect, the old one would be d9vk and I believe it's one of the apps that has multi swapchain issues
<bnieuwenhuizen>
the new one only requires d3d11 actually
<jenatali>
Huh. I guess I'd just assumed
<Venemo>
There is a reddit thread where some user reports a magical speedup by using dxvk on windows
<jekstrand>
Yeah, there's a few of those
<Venemo>
One of the commenters warns him that DXVK is a trojan
<bnieuwenhuizen>
Venemo: don't worry about misconceptions. They're out there about everything :)
<gawin>
iirc there's one really long topic on guru3d how radeons have low number of drawcalls in d3d9 and d3d11 (maybe some legacy stuff(?))
mbrost_ has quit []
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
<jekstrand>
cmarcelo: I kind-of want nir_var_texture now....
<jekstrand>
cmarcelo: In particular, it makes for a really good way to sort out bindless.
<jekstrand>
That's my real reason
<jekstrand>
And nir_var_sampler, of course
<jekstrand>
And nir_var_atomic
<gawin>
btw theoretically it should be possible to "implement" d3d8 using gallium nine? I heard that it kinda matches
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
<Venemo>
gawin: there are layers that implement old D3D with d3d9 and you can then run the result on ninr
<Venemo>
on nine*
<gawin>
ah, yes, there are some DLLs for this
ybogdano has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
<jenatali>
jekstrand: I'd focus in fixing the types for textures/samplers first. Having sampler either mean sampler+texture or just texture is very confusing
<jekstrand>
jenatali: Right.... That should be cleaned up too
<jekstrand>
jenatali: One option would be to get rid of combined texture+sampler in NIR. The problem, of course, is that some HW requires it.
<jekstrand>
Mostly ancient stuff because DX9 is split
kem has joined #dri-devel
<jenatali>
"Get rid of" could just mean "describe differently" :)
<jekstrand>
But like Mali 400 requires them to be combined, I think.
<jenatali>
I don't think it'd be too bad if NIR described them like SPIR-V, either combining a texture + sampler, or declaring a texture + sampler together
<jekstrand>
What would declaring a texture+sampler together look like?
<ajax>
opengl 2.0
<jekstrand>
:P
<ajax>
do you just mean what do you call the combined object?
<anarsoul>
jekstrand: Mali400 operates samplers in ISA, you bind sampler to a texture in texture descriptor
<jenatali>
jekstrand: Doesn't SPIR-V allow you to declare variables of type combined texture+sampler?
<anholt>
I didn't do desktop GL version checks for everyone because I'd have to split deqp-GL from KHr-GLES in the suite definitions, but you could just do that.
<jekstrand>
jenatali: I'm disallowing void, FYI. I hope that's ok.
<jenatali>
jekstrand: Void textures?
<jekstrand>
jenatali: CL-style void images
<jekstrand>
Ugh... No. We need to keep those. :-/
<jenatali>
Yeah, for lowering read-only (sample-able) CL images into textures
<jekstrand>
You don't want them for CLOn12 but we do for any HW driver
<jenatali>
Yeah, I add type info to them, but I think I still end up with them transiently?
<jenatali>
At some point I still need to go write up a patch to remove the static instances of glsl_type and make them lazy-initialized
<jekstrand>
oh?
camus has quit []
iive has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
mbrost has joined #dri-devel
<emersion>
hwentlan: thanks for the review!
<hwentlan>
emersion: np
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<jenatali>
jekstrand: I think I'd mentioned a while ago that when we proposed spirv_to_dxil to the WebGPU folks, they called out one of their requirements is that it can't introduce new global module constructors/destructors
<jekstrand>
jenatali: Oh, right. THat.
<jekstrand>
Yeah, that's probably fixable.
<jenatali>
glsl_type has several static glsl_type instances, and the glsl_type constructor/destructor is decidedly non-trivial
<jekstrand>
We still need the global lookup table, though.
<jenatali>
Yeah especially since you already have to explicitly refcount the GLSL type system anyway for those dynamic tables
<jekstrand>
But as long as they're fine with zero-init stuff, we should be good.
<jenatali>
Yeah zero-init's fine, just not code for constructors
<robclark>
anholt: kinda along those lines, maybe a glxinfo + diff against expectations (after stripping version) would be nice in CI.. that would detect gl/gles version changes, and also extension changes
<anholt>
I would love for that to replace features.txt. but I don't think I want to work on that.
alanc has quit [Remote host closed the connection]
<jekstrand>
Doing vulkaninfo + diff would be good too. If nothing else, it would remind people "hey, you added a feature. Update features.txt"
lynxeye has quit []
<robclark>
anholt: actually https://people.freedesktop.org/~imirkin/glxinfo/ already replaces features.txt and mesamatrix.. it just needs a convenient src of glxinfo dumps (and IIRC a slight bit of massaging glxinfo output??).. oh, and I guess a vulkan version..
<robclark>
but when I get a chance I might try to hack up glxinfo/vulkaninfo + diff.. that seems like a reasonable starting point for the "did you remember to update features.txt" job
<robclark>
(although maybe next thing I do as far as CI is try to cobble together some clover-ci for freedreno)
<anholt>
I haven't looked into the CL CTS. you're running it through piglit currently, I guess?
<airlied>
CL CTS can only be run in it's own horror show
<airlied>
for CI though test_api and test_basic might be doable in 10 minutes
<ajax>
i want enough drm-shim that i can run eglinfo surfaceless against arbitrary pci ids
<ajax>
where's my flying car
<anholt>
airlied: does cl cts do stuff in parallel?
<robclark>
anholt: even test_basic has some kernels that seem to run long enough to trip our hangcheck timer.. I'm not sure that a parallel run for cl will help.. it doesn't really help that cl-cts doesn't seem to have any sane runner
<karolherbst>
I've made some changes which I just pushed
<anholt>
I just did a big refactor that makes deqp-runner pretty easily extendable to other test types, so I'm happy to just slap another one on so we can have xfails/flakes/etc. support.
<karolherbst>
robclark: well, it's CL, the stuff can run forever
<karolherbst>
anholt: the issue is that the OpenCL CTS doesn't really give us a nice way of getting all sub tests
<karolherbst>
and test variants
<robclark>
yeah, cl cts is really just an ad-hoc collection of cl programs
<karolherbst>
yep
<airlied>
yeah it's not the most introspective test system
<robclark>
rather than something approximating sane
<airlied>
it's like here's 40 binaries, each with their own apis
<ajax>
flashbacks to glean
<jekstrand>
robclark: I'm sure if you wanted to sign up to port the CL CTS to dEQP's test running framework, Khronos would agree to take the patches. :-P
<karolherbst>
parsing the help out does work good enough though
<airlied>
I suppose in theory passing -h gives you the subtest names if you can parse it out
<karolherbst>
otherwise a lot will just return with an exit code of 0
ybogdano has joined #dri-devel
<robclark>
in an ideal world, there would be an EXIT_SKIP
<karolherbst>
yeah...
<karolherbst>
oh well
<gawin>
are there plans with CI for older hardware? I was able to obtain old terminal with r300 gpu (I can donate it and send if you're in eu)
<karolherbst>
jekstrand: for the image/texture reworks I think we might want to keep in mind what gallium nine/d3d9/... needs
<robclark>
karolherbst: anyways, looks like existing cl ci we have is using piglit.. and if piglit has enough cl tests for a sanity check, that is probably where I'll start.. mostly just want something to hit some of the codepaths that are different for clover vs mesa/st just to make sure nothing obvious breaks (once freedreno+ir3 clover stuff lands)
<karolherbst>
yeah....
<jenatali>
E.g. 16-component vectors :)
<karolherbst>
atm I am not really focusing on that part and kind of have enough other things to deal with so I don't really see me caring about CL any time soon :/
<karolherbst>
I never checked how much piglit tests though and I think it could make sense to integrate the CL CTS actually
<karolherbst>
but...
<jenatali>
CL CTS is not something you can run all of in CI, that's for sure
<karolherbst>
yeah
<karolherbst>
it takes hours
<jenatali>
Days
<karolherbst>
also on hw?
ybogdano has quit [Ping timeout: 480 seconds]
<jenatali>
Well, maybe if you're on faster hardware than I was on you could get it down to hours. But yeah CLOn12 took days even on hardware
Bennett has joined #dri-devel
<karolherbst>
oh wow
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
ever checked where most time is spent?
<jenatali>
Not really
<jekstrand>
I could easily believe NIR isn't the fastest thing ever on Windows.
<jenatali>
I don't think it was shader compilation
<jekstrand>
Well, no. I think jenatali said they link in jemalloc so it should be ok.
<jenatali>
We do not use jemalloc, not sure where you got that :)
<jenatali>
I do know that trying to run LuxMark 4 I spent forever in shader compilation, but in the CTS I'm pretty sure compilation was quick
<karolherbst>
well
<karolherbst>
the CTS also compiles like hundred times in a second :p
<karolherbst>
but that might be our fault actually
<jekstrand>
jenatali: Not sure then. :-/
<jekstrand>
In any case, Windows can be malloc()-bound in my experience and NIR doesn't do any recycling.
<jenatali>
Maybe something to look into at some point, but I'm sure we've got much lower hanging fruit for perf
<karolherbst>
I think a proper profiler should give us the answers :p
<jekstrand>
likely
<anholt>
daniels: have any collabora folks done any experimenting with simple-chrome test_decode builds? google folks say it should be reasonable to do for video testing and said it might be WIP for kernel-ci.
ybogdano has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
<emersion>
iirc he is on leave
i-garrison has joined #dri-devel
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<jenatali>
jekstrand: So I think the MR you posted for textures/samplers probably needs changes in all of the tree's VK drivers, and I think the readonly image -> texture lowering pass should produce textures instead of samplers too
<jenatali>
Guess I'll just put that in the MR
<jekstrand>
jenatali: image -> texture does produce textures now
<daniels>
anholt: not ttbomk, can check next week when I’m back
<jenatali>
Oh does it?
<daniels>
anholt: if you have a Google-side contact could you email me cc them?
<jekstrand>
jenatali: As part of the last commit
<jenatali>
Oh
<jenatali>
Don't know how I missed that
Peste_Bubonica has joined #dri-devel
<jekstrand>
Not sure what's going to be required for vk drivers, TBH.
<jenatali>
Why didn't this blow up the CLOn12 unit test, huh
<jekstrand>
no idea
<jenatali>
Looking :)
<jenatali>
Hah, awesome, I throw away the texture type info and replace it with a sampler when I add in the return type info
tursulin has quit [Read error: Connection reset by peer]
<jekstrand>
I suspect most of what we need to do after it is delete stuff
<jenatali>
I'll probably see about promoting my sampler-splitting pass to common, taking tex instructions that reference a samplerND and pointing it at a textureND and a bare sampler
<jekstrand>
Looks like I broke lavapipe....
Duke`` has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
kenjigashu has quit []
kenjigashu has joined #dri-devel
<jekstrand>
jenatali: I'm not sure if that pass would be helpful for HW drivers or not....
<jekstrand>
I mean, most HW does do separate sampler/texture
<jekstrand>
But we generally ditch variables somewhere in common GL code so the driver never sees the difference.
<jenatali>
Fair enough
<jekstrand>
But that doesn't mean it can't be common
kenjigashu has quit []
<jekstrand>
IMO, the more common the better
<jekstrand>
Gets better code review and it's easier for us to help keep it working.
<jenatali>
Ah, yeah we're definitely weird in that we try to preserve variables as much as possible
<jekstrand>
It might be useful for Zink
<jekstrand>
But I suspect Zink just does VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER for everything
kenjigashu has joined #dri-devel
<jenatali>
Right, makes sense
<jenatali>
Since D3D only does separate textures and samplers, and since we're interested in supporting more than just GL through that stack, it becomes much simpler to rationalize about things when texture == texture, sampler == sampler, image == image
<jenatali>
No weird cases where sampler might be a sampler, or it might actually be a texture, or maybe it's both
kenjigashu has quit []
mlankhorst has quit [Ping timeout: 480 seconds]
kenjigashu has joined #dri-devel
<jekstrand>
Yup
<jekstrand>
IMO, that's the right call for what you're doing
<anholt>
whee. went off to lunch without having clicked play on my ci pipelines. guess I won't be working on that for the next hour.
kenjigashu has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
kenjigashu has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
vivijim has quit [Ping timeout: 480 seconds]
<jenatali>
:O hash_table_u64 silently special-cases 0 and 1
<jekstrand>
Yes
<jenatali>
That's fun. Clear doesn't clear those ones
<jekstrand>
Oops
<jekstrand>
That's a fun bug
<jenatali>
Which, I mean, it kinda shouldn't? Since they're for freed/deleted entries?
<jekstrand>
No, they're for if you use 0 or 1 as a key
<jekstrand>
because 0 and 1 in the main table are reserved for freed/deleted entries
<jenatali>
Oh I see
<jenatali>
So clear should still clear them
<jekstrand>
If you use the pointer version, those are straight-up disallowed as keys
<jekstrand>
yup
<jekstrand>
Should be a 2-line fix
<jekstrand>
But we should really have some unit tests...
<jenatali>
:)
Bennett has quit [Remote host closed the connection]
kenjigashu has quit []
alyssa has joined #dri-devel
<HdkR>
0 and 1 disallowed as pointers? Can't believe it would ruin my valid use case of mapping things at nullptr :P
<alyssa>
re Xorg hotplug/displayport "fun" on DCP,
<alyssa>
calling drm_connector_set_link_status_property(BAD) at the right time makes everything work :-)
<alyssa>
and since it's a displayport upstream, it's not even a lie.
<robclark>
seanpaul: looks like most of your hdcp series is a-b and/or r-b.. did you have an idea in mind for how you want to land that since it touched core + i915 + msm?
<alyssa>
...i have a similar bug with weston. ugh.
<alyssa>
works with sway at least
alanc has joined #dri-devel
<alyssa>
oh, weston hotplug works, just need to fix a WARN
gawin has quit [Ping timeout: 480 seconds]
f11f12 has quit [Remote host closed the connection]