flynnjiang has quit [Remote host closed the connection]
gonnaberemoved has joined #dri-devel
yyds has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
alane_ has quit []
alane has joined #dri-devel
sudeepd has quit [Ping timeout: 480 seconds]
<gonnaberemoved>
I worked on flattening real processors netlists back to verilog so that every signal will show up, Americans have always had the defense against every electronics based launch codes unless the chip is manufactured by third parties and gets entirely reengineered, that's possible but then they execute terror against Russian docks if such chips are authored, they are many steps ahead, Americans are very smart people.
u-amarsh04 has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
<gonnaberemoved>
There is two ways of doing it, either pulses way above the satellite frequency which would require excessive cooling and is not feasible much, or duty cycle and chip entirely redone to 50 50 and have its own transistor nodes that Americans are not aware of.
kzd has joined #dri-devel
<gonnaberemoved>
That chip is quite complex to produce that filters out the environments frequency like artificial orbiting interference object as satellite and drones are
<gonnaberemoved>
One needs to rewire almost everything
flynnjiang has joined #dri-devel
<gonnaberemoved>
So that positive edge comes in and it executed a very minor block, while continuing on negative edge 50 50 is enough there, since positive edge is at 13 and negative at 11 GHz
<gonnaberemoved>
It just never captures those signals
<gonnaberemoved>
By that time it arrives the transistors already performed
<gonnaberemoved>
From hw perspective such chip resembles the properties of mixed mode analogue digital circuit
<gonnaberemoved>
You think they detonate a nuke like this, it's not technically succeedable easily
<gonnaberemoved>
I would not be surprised that rus feds lack everything to manage this type of attack
epoch101 has joined #dri-devel
kts has joined #dri-devel
kts has quit [Quit: Leaving]
rz_ has quit [Ping timeout: 480 seconds]
<gonnaberemoved>
So 50 50 is the attack chip, until pulses do not interact, which should be the case where length of the pulse is 2ps as on pci 1ghz it's way shorter than satellites or drones pulse which is at SI units 1000/13 ps
rz has joined #dri-devel
<gonnaberemoved>
This would land attacks, if launched from glonas systems, but they do not have such chips, japanese nor Taiwan,us or Netherlands are not allies, or Germany either
flynnjiang has quit [Ping timeout: 480 seconds]
<gonnaberemoved>
It's safe to assume they have not been successful to fab such yet
<gonnaberemoved>
Is that at all possible to get such chip fabed? Yeah it is when you get the material properties and wire lengths right
<gonnaberemoved>
Very complex and in reality impossible more like
sudeepd has joined #dri-devel
Company has joined #dri-devel
<gonnaberemoved>
Israel should be hence safe and Iranian failed attack showed that, but it was known
<gonnaberemoved>
So far us people have been the smartest
<gonnaberemoved>
People of United States who made it possible for Israel though
flynnjiang has joined #dri-devel
epoch101 has quit []
<gonnaberemoved>
I expect the United States soon to discontinue supporting Israel
<gonnaberemoved>
Cause they are aware of their leader status after testings now
<gonnaberemoved>
And indeed yet another upset, it seems Elon Musk was right about Mars.
<gonnaberemoved>
So nasa has lied before
<gonnaberemoved>
But they do that all the time strategically
<dwfreed>
.
flynnjiang has quit [Ping timeout: 480 seconds]
<kode54>
so nice that they know how to register with services repeatedly
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
aravind has joined #dri-devel
<Company>
DavidHeidelberg: my biggest issue with eglinfo is that it tries to force itself into being so small, so thre's no good column grouping, so when reading "64 0 16 16 16 16 16 0 16 1" I get confused which 16 is what. So having output that is focused more on being verbose/human-readable would be nice
<Company>
like, vulkaninfo or waylandinfo are way easier to human-read, even though they're probably harder to machine-read
<HdkR>
vulkaninfo also has the -j flag which makes it very easy to machine read
agd5f has joined #dri-devel
<Company>
yeah, that would be neat - a flag that toggles between human-readable and machine-readable
bmodem has quit [Quit: bmodem]
agd5f_ has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<DavidHeidelberg>
Company: json would be nice, but you can also use the expert output or how its called
kode54 has joined #dri-devel
<Company>
oh, -v exists
<Company>
that's a bit too verbose though
<Company>
I like the table format, I just wish it had some vertical lines or wider columns to give it more space
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jsa has joined #dri-devel
jfalempe has joined #dri-devel
cascardo has joined #dri-devel
cascardo_ has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
gonnaberemoved has quit [Remote host closed the connection]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
frieder has joined #dri-devel
fab has quit [Quit: fab]
mvlad has joined #dri-devel
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
vjaquez has joined #dri-devel
kts has joined #dri-devel
<Company>
so, as you may know, GTK unstable has switched to Vulkan by default
vliaskov has joined #dri-devel
<Company>
and it turns out one of the problems for integration with other tools is drivers that don't support modifiers
<Company>
because Vulkan can't do modifier-less dmabufs
<Company>
which is both a problem with video playback as well as tools that want to use GL
<Company>
the most recent big GPUs that have that issue is AMD Gen8
<Company>
what should be the plan with that?
<Company>
should GTK keep using GL with those drivers?
<Company>
should we file bugs about adding modifier support to those drivers and stay on Vulkan for the time being?
<Company>
any other options?
warpme has quit []
<MrCooper>
Company: adding modifiers for older AMD GPUs is unlikely to happen before the next major GTK release
lynxeye has joined #dri-devel
frieder has joined #dri-devel
<Company>
good to know
<Company>
that means modifier-less is a thing we need to think about, Gen 8 is common enough still to have a big audience
<Company>
and Gen 8 runs Vulkan well, so other reasons to skip it wouldn't trigger
rasterman has quit [Quit: Gettin' stinky!]
<pq>
Company, are you thinking of special-casing based on hardware/driver or checking whether modifiers are supported?
flynnjiang has joined #dri-devel
<pq>
If that hardware/driver does not support modifiers in GL, then how is it possible to get Vulkan app on screen at all with a GL-based compositor?
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
mripard has joined #dri-devel
<pq>
or is that the point that it doesn't?
fab has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
<Company>
pq: I didn't actually think about yet what the wsi is doing
gardiograph has joined #dri-devel
<Company>
but yes, I'm thinking about making modifier support a condition for choosing Vulkan over GL
<Company>
basically I'm trying to implement bool should_we_prefer_vulkan_over_gl(GdkDisplay *display)
<glehmann>
mesa wsi without modifiers has a private pNext struct that tells the driver the image is going to be used for scanout
<Company>
one of the fun things that Phoronix brought up - useful input from Phoronix comments, what a day! - is multi-gpu systems where the igpu doesn't have a Vulkan driver
<Company>
you don't want to switch GTK to the dgpu on those
flto has joined #dri-devel
<Company>
how would I go about that btw?
<Company>
what's the best way to check that Vulkan is using the default GPU?
<Company>
glehmann: that sounds a lot like we want to avoid Vulkan with no-modifier drivers, just to avoid the hassle
q66 has quit [Ping timeout: 480 seconds]
<emersion>
vulkan has explicit GPU selection
<emersion>
you can compare vulkan's GPU (there's an ext to get the major/minor dev numbers from a VkPhysicalDevice) with the GPU advertised by the compositor
<Company>
that's not what I want to compare with though, do I? I want to compare with DRI_PRIME or whatever tool is used
<Company>
so that GTK apps can run on different GPUs
<gardiograph>
It actually should show how global defense systems work yices2 solver, anything different is almost impossible to be taped out, so the level of defense is likely one level deeper with electrical suppression, such as bus compression. So i believe those news that us systems intercepted all the launched missiles. My code is very efficient but it is not designed for attacks, it does not remove hw vulns.
<Company>
I mean, the question I want to answer is not "is Vulkan supported at all?" but "is Vulkan supported on the GPU that GL would be using by default?"
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
<emersion>
DRI_PRIME doesn't work on vulkan out of the box
bolson has quit [Remote host closed the connection]
<Company>
why did it do for me?
<emersion>
there is a layer that people can install to re-order the devices
<emersion>
but that only works with naive vulkan apps that pick the first device
<Company>
a while ago I tried it accidentally and it worked
<Company>
doesn't the spec even say you should select the first device?
<Company>
first device that supports the features you want
chloekek has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jsa has quit [Read error: Connection reset by peer]
<gardiograph>
if you look at racepwn attack airlied than you should know that i know how intrusion to my hotel management was successful for australian who was in all the network with ssh, because after all i designed that though russians did design the same thing.
<Kayden>
which unfortunately pushed it just like 2-3 minutes over the 1 hour cutoff, so everything passed, but now not at the front of the marge queue...so get to rebase and run it all again. :/
rasterman has joined #dri-devel
pcercuei has joined #dri-devel
flynnjiang has joined #dri-devel
gardiograph has quit [Remote host closed the connection]
itoral has quit [Read error: Connection reset by peer]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 480 seconds]
tomeu has quit [Ping timeout: 480 seconds]
M839ty9[m] has quit [Ping timeout: 480 seconds]
tomba has quit [Ping timeout: 480 seconds]
zamundaaa[m] has quit [Ping timeout: 480 seconds]
AndreyKonovalov[m] has quit [Ping timeout: 480 seconds]
kallisti5[m] has quit [Ping timeout: 480 seconds]
EricCurtin[m] has quit [Ping timeout: 480 seconds]
colinmarc has quit [Ping timeout: 480 seconds]
fililip[m] has quit [Ping timeout: 480 seconds]
kos_tom has quit [Ping timeout: 480 seconds]
danylo1 has quit [Ping timeout: 607 seconds]
DemiMarie has quit [Ping timeout: 607 seconds]
zxrom has quit [Write error: connection closed]
zxrom has joined #dri-devel
warpme has quit []
dcbaker has quit [Ping timeout: 480 seconds]
neobrain[m] has quit [Ping timeout: 480 seconds]
kusma has quit [Ping timeout: 480 seconds]
valentine has quit [Remote host closed the connection]
Newbyte has quit [Remote host closed the connection]
<tzimmermann>
airlied, sima. hi. could i please have -rc6 in drm-next? i'd like to get the recent fix for fbdefio into drm-misc-next
<sima>
tzimmermann, yeah will look into it, iirc mairacanal also wanted a backmerge for vkms stuff and dolphin mentioned something about funny conflicts
<sima>
I'll ping when it's done, a bit busy rn still
<daniels>
Kayden: yeah, some of the racks threw a fit last night
<tzimmermann>
np, thanks a lot
<tzimmermann>
it's not really urgent
<mripard>
sima, jani: we also need to figure out what we want to do with the kconfig stuff
<jani>
mripard: if this is the same kconfig stuff we're talking about
<mripard>
it's what I was talking about :)
epoch101 has quit []
<mripard>
so we should just merge the reverts then?
<jani>
seems to me that would make more people happy than unhappy :/
<jani>
but I'm more persuaded by arnd's arguments than geert's "just always select all the dependencies of the target symbols"
<jani>
so, I guess ack for the reverts, and apologies for all the extra work for nothing I persuaded you to do :(
guludo has joined #dri-devel
itoral has quit [Remote host closed the connection]
sukuna has joined #dri-devel
kts_ has quit [Ping timeout: 480 seconds]
kts_ has joined #dri-devel
kts_ has quit []
<mripard>
tzimmermann: should we open drm-misc-next-fixes?
<tzimmermann>
mripard, yes
<tzimmermann>
why do you ask?
<mripard>
I've been busy with other things so didn't really follow this cycle, and I need it to merge the patches we were discussing with Jani
<tzimmermann>
i thought that maarten takes care of d-m-next-fixes. shall I do it?
feaneron has joined #dri-devel
<tzimmermann>
it might be worth waiting for -rc6 to land in drm-next
<mripard>
tzimmermann: oh, no, sorry, I got confused and thought you were in charge of drm-misc-next this cycle...
<mripard>
... like I said, I didn't really follow :)
<tzimmermann>
no problem, i'll update -misc-fixes soon anyway. if i find -misc-next-fixes lagging behind, i'll update that as well.
alyssa has joined #dri-devel
<alyssa>
Company: I expect on apple platforms, we'll want to prefer gl over vk
<alyssa>
just because there are some significant performance problems inherent to doing vk on this broken gpu, that are worked around much more efficiently in our gl driver
<alyssa>
(this is the same reason we won't be shipping zink on current hw)
<alyssa>
Is there a way to communicate that in the gl or the vk side?
<alyssa>
or does gtk just need to hardcode vendor IDs or something?
<alyssa>
[N.b.: for gtk specifically, vk performance is probably still "good enough", but battery life is a thing.]
M839ty9[m] has joined #dri-devel
<alyssa>
adding a VK_MESA_gimme_minced_fruit ext to opt into nonconformant speedhacks is also an option, I guess, but that's more work for both of us
<emersion>
hm, i want to switch wlroots to vulkan as well sometime…
<emersion>
would be nice to have a way to find out whether GL or Vulkan should be preferred
Calandracas_ has joined #dri-devel
warpme has joined #dri-devel
kts_ has joined #dri-devel
kts_ has quit []
derr has joined #dri-devel
<derr>
hello. i was here yesterday having some troubles with my nvidia card and mesa drivers. i resolved dependency error. Wondering if anyone dare to take on the challange of downgrading or fixing my mesa drivers .. ?
fab has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
yyds has quit [Remote host closed the connection]
fab has quit [Ping timeout: 480 seconds]
hansg has quit [Quit: Leaving]
cphealy has joined #dri-devel
koike has joined #dri-devel
<koike>
hello all, after drm-misc migrated to gitlab, now I'm having issues to push to it with dim tool, I receive a message saying dim is outdated, but it is not, I just pulled the latest version
dliviu has quit [Quit: Going away]
dliviu has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<Company>
alyssa: I'd like to avoid vendor hardcoding, because it's a mess and because it's not forwards-compatible
<Company>
so if there's some feature-based method, that would be much preferred
<Company>
alyssa: also, there are terminal benchmarks where Vulkan is a lot faster because vte makes us switch shaders a lot and that is slow with GL
<alyssa>
Company: Interesting. In general, I'd expect on our platform that VK has lower CPU overhead but GL has lower GPU overhead
<Company>
and I want to get to rendering gnome-maps on the GPU so I can live-zoom, and that's gonna require some GPU fanciness - no idea how much is on the VUlkan/GL layer for that though
<Company>
why would GL have lower GPU overhead?
<alyssa>
13:17 alyssa | just because there are some significant performance problems inherent to doing vk on this broken gpu, that are worked around much more efficiently in our gl driver
<dj-death>
Company: host based upload of mipmaps etc...
<dj-death>
non-bindless model also potentially?
<Company>
we currently have a Vulkan 1.0 and Vulkan 1.2 mode, the old one is probably going to turn into one that juggles tons of descriptorsets and then new one does just one
<alyssa>
non-bindless + no separate texture/samplers
<Company>
I originally wanted to play with bindless on GL, too, but if we switch to Vulkan anyway, that's not worth it
<dj-death>
iris doesn't support bindless
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
<FLHerne>
#]
<Company>
oh, was bindless radeon only?
<Company>
then I should totally get to working on it, so that I only have half the issues as with usual stuff!
<dj-death>
it's an extension, not sure how supports it
<dj-death>
zink supports it ;)
<Company>
zink on anv, too?
<dj-death>
there might be caveat there
Surkow|laptop has joined #dri-devel
<dj-death>
zmike would be able to answer
<dj-death>
I think it might be disabled until DG2+
<dj-death>
it requires 2 descriptor buffers and we can only support one on Gfx9/Gfx11/Gfx12.0
<dj-death>
the HW heap is too small (64MB)
<zmike>
if you don't use descriptor buffers it works fine
<derr>
hello. anyone want to help me downgrade or fix my mesa drivers ? i even buy new video card today , upgrade from nvidia quadro 370 to nvidia quadro 570. i still have same issues. -ubuntu user
<zmike>
you should probably try ubuntu support channels
<zmike>
this is a driver development channel
<Company>
oh yeah, descriptor buffers
<derr>
its mesa driver dev channel ? its ,, very mesa related i think
<Company>
to me "bindless" on Vulkan just means I create 1 descriptorset that's large enough to hold all the textures
<zmike>
it's ubuntu-related, not mesa related
<dj-death>
Company: it means you can update it after it's bound actually
<zmike>
Company: zink will automatically choose the most optimal mode, which should be the one that enables bindless
<karolherbst>
derr: you'll only get support here for upstream supported mesa versions, which are 24.0.6 or newer
<Company>
right, I don't need that because I write a new set every frame
<derr>
:) im trying to downgrade...
<derr>
its only for the upstream huh
<derr>
ok
<derr>
this server have ubuntu help channels ? #ubuntu ?
<zmike>
no idea
<zmike>
try google
<FLHerne>
nouveau should support that alright? It's an nv50
<karolherbst>
I mean.. you can read yourself into `git bisect` and use that to pin point what might have broken it, but if you just want to install an older mesa you should probably figure out how to do that in your distribution, because we can't really give you any advise on how to install it without also breaking your system
<Company>
(and you can't even do it yourselves, because llvm)
<karolherbst>
there is of course `meson devenv` to run a single application with your self built mesa, but if you e.g. need to run your entire desktop in it, we'd rather not want to risk you breaking your system
<karolherbst>
FLHerne: yes, but anything older than 24.0 isn't supported here anyway
<karolherbst>
_but_
<derr>
just wanted to play my cs.. im prepeared to break my stuff if anyone want to try help in privmsg
<karolherbst>
derr: but anyway, we are happy about figuring out how to fix your issue if it happens on mesa 24.0.6 or newer
<karolherbst>
just downgrading is a hariy topic
<karolherbst>
*hairy
<derr>
if i upgrade to 24
<derr>
and its still buggy
<derr>
i can come and cry ?
<karolherbst>
yes
<zmike>
if you build from source*
<FLHerne>
well, if there's a significant perf regression on nouveau that's probably worth knowing
zxrom_ has joined #dri-devel
<karolherbst>
well.. I'm not so strict on the building from source part
<karolherbst>
because most distributions aren't really causing that many bugs by patching things
<FLHerne>
I had a Quadro FX 400 perhaps 12 years ago, £5 out of a parts bin :p
<zmike>
the problem has been repeatedly stated as "my driver install is broken"
<zmike>
if distro packages are what's broken, that's not a mesa issue
<FLHerne>
it was a decent card after I found a second one to get one set of non-buggy VRAM chips :p
<karolherbst>
yeah.. but anyway, that's not the point here. If a user has an issue on upstream supported drivers it's something worth looking into
<karolherbst>
zmike: "my driver install is broken" can also mean I just use mesa and it's causing bugs
<zmike>
but mesa has no bugs
<derr>
for the record,, my fps was good before 22.x mesa update,,
<karolherbst>
ahh..
<karolherbst>
so it's a FPS regression?
<derr>
fps was 99 fairly stable before update,, now down to,, 10-20 -30 ,, sometimes 50
<derr>
only cs 1.6..
<karolherbst>
mhhh
<karolherbst>
I think I know what it could be
<derr>
.. i still need to upgrade to 24 before i can cry ?
<FLHerne>
that's between 22.0.1 and 23.2.1 according to the logs earlier, fwiw
<derr>
*look*
<karolherbst>
FLHerne: I suspect the multi threading fixes I've landed as they did some cursed stuff to workaround driver architecture
<karolherbst>
and the _proper_ way would have been to write a new driver
<karolherbst>
anyway... I should prolly go to bed because of my headache...
<derr>
i should maybe know what perf is but, i do not
<derr>
no no
<derr>
ill paypal u
<derr>
if u just tell me
<karolherbst>
perf = performance
<derr>
how to reverse this
<derr>
... oh
<derr>
=)
<derr>
i can do something,, not university education needed operation to fix this ?
zxrom has quit [Ping timeout: 480 seconds]
<karolherbst>
not really sadly... just downgrading your mesa, or well.. build from an old branch and run steam/cs through meson devenv
coldfeet has joined #dri-devel
<derr>
i can bother you , perhaps in msg , to guide me to downgrade mesa ? no responsebility,,, ill pay u even if u got paypal if u name a fair price :)
<karolherbst>
but if you have no experience with any of that, might be a bit problematic anyway
<karolherbst>
could throw you a script or something tomorrow
<derr>
i tried some meson stuff yesterday ,, got in some trouble but,, ill take a look
<derr>
ill hang around here trying to bother people as politely as i can waiting for u tomorrow =) thankyou
<soreau>
the problem is they have broken system packages, so it will likely take some work to install the deps from apt
<derr>
soreau: hi again, nono,, i fixed that,, i just deleted the file it complained about,, was some var/blabla/copywritght
<derr>
just rm -rf stuff = fix
worldlabels has joined #dri-devel
<derr>
now system think it have v23 again,, and actually have 23,,, i think,, unless meson hidden something somewhere from apt
<derr>
libglx-mesa0/mantic-updates,now 23.2.1-1ubuntu3.1 amd64 [installed,automatic] free implementation of the OpenGL API -- GLX vendor library
<derr>
soreau: do you dare the argous horrible task of helping me downgrade to 21 ? feel free to break anything policy...
<soreau>
well it's pretty straightforward, just follow the link and install and missing deps that are needed, then run with that version of mesa
<derr>
looking at the meson build howto now
<derr>
dont look like voodoo
<worldlabels>
anyways i can not remember the specification but i remember i had suspicion about the 50 50 duty cycles, and flattening the netlists it revealed a long positive clock and short negative edge, and vice versa without external signalling. which i interpreted as interference signalling was accounted on the rails, in other words satellites can take over the voltage rails and clock rails cause it is in the signalling of aggregated clock voltage
alyssa has left #dri-devel [#dri-devel]
<daniels>
mairacanal, sima: hey, any chance of getting some review on the configfs-for-vkms series at https://lore.kernel.org/all/20230829053201.423261-1-brpol@chromium.org/ please? it'd be really useful to have for compositor/libliftoff testing - there's also a link from mvlad below to a series which adds support for it to igt
xroumegue has quit [Ping timeout: 480 seconds]
<derr>
soreau: i can pass u something in msg ? my log from apt get ? to ask u if u agree that its the library at all that needs upgrading or fixing ? maybe its something else obvious ?
<derr>
that its the mesa library at all*
<derr>
got a list of 5-6 packages
jsa has joined #dri-devel
<soreau>
derr: you can pm me, but typically for more than a few lines on IRC, better to post them to a pastebin service and share the link
<derr>
just a very few ones :)
<derr>
could compile on 1 line but
<derr>
second
rasterman has joined #dri-devel
<worldlabels>
since they talk few about gravity of the earth it is very likely that satellite signal is way faster to arrive than anything generated on the chip as defending the bus lines with chips pulling them in low or high impedance than with software this can not be fixed.
<worldlabels>
which means that the defense is permanent
<worldlabels>
in other words FPGA internal very fast units on my algorithms are unlikely to succeed on bypassing any of such defense, since the microcontroller on power lines is not as fast locally than the wireless decibels to arrive.
rasterman has quit [Quit: Gettin' stinky!]
pepp has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
<worldlabels>
than why i stated that mixed mode analog digital would work on 50 50 duty cycle power lines, cause it is very likely it would, but is very hard to build.
jernej_ is now known as jernej
fab has joined #dri-devel
<worldlabels>
the biggest thing i realized is that miniPOL system amplifiers or diodes on the power lines due to such architecture on the clock lines would end up consuming cosmic and satellite energy, but not on fpga's that have their own custom circuits, so fpga's are clearny much more low power than asics which was not what i thought considering literature.
frieder has quit [Remote host closed the connection]
f_ has joined #dri-devel
<Company>
dj-death: thinking about systems where GL is preferrable to Vulkan, does that go for the old intel systems that had flaky initial Vulkan support?
<Company>
like Broadwell or whatever it was?
<Company>
or do those not advertise Vulkan anymore?
fab has quit [Quit: fab]
bolson has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
davispuh has joined #dri-devel
fab has joined #dri-devel
<worldlabels>
but that is just my take on those things, maybe it's not entirely correct, it is just when low is in more time on complex aggregated systems where the duty cycle would not collide on the satellite, it would end up being very low poer and could not consume any of that energy but take it locally, its lienard wiechert field theory.
<worldlabels>
but the controller on the power lines would still be vulnerable and would be spotted by defense systems
jsa has quit [Ping timeout: 480 seconds]
ghishadow has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
<worldlabels>
so i decided that it is all about taping out such power controller which has so large complexity that it is almost unreal to get it done or battery controller at least by so called terrorist groups, they can not make it to be threat through the skies.
linkmauve has joined #dri-devel
<worldlabels>
it is a chip that could do it but that is very complex to get done.
Duke`` has joined #dri-devel
<worldlabels>
its some nuclear technology similar stuff such chip could be anihilation based as well that would do it for sure, but other even more complex but less efficient ways would do too, but none of this can ever me worked out by such men or groups as hamas.
ghishadow has joined #dri-devel
<worldlabels>
already when you access such pages or know how you are walking on thin line.
<worldlabels>
all this subject is hard to get brain cells at, but we see that there is some aggression involved where some do not want others to live and the market of defense against such is very large, so united states earns also money or those companies such as lockheed martin and such. it's big business .
<zmike>
DavidHeidelberg: looks like you and tpalli are getting through it
aravind has quit [Ping timeout: 480 seconds]
<zmike>
eric_engestrom: did I miss anything or was that it
warpme has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
anujp_ has quit [Ping timeout: 480 seconds]
anujp_ has joined #dri-devel
jsa has joined #dri-devel
kts has joined #dri-devel
feaneron has quit [Remote host closed the connection]
feaneron has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
rz has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
kaiwenjon has joined #dri-devel
warpme has quit []
vliaskov_ has joined #dri-devel
<worldlabels>
in reality i do not also grasp those duty cycle calculations that well due to timely resources shortage, domino clocks or what they described as 50 50 duty cycles were present in core duo range for short while, were they safer on chip from external pulsing i dunno, but they complained about northbridge tendency to ovearheat. so interrupts started to delay and timing was volatile.
jsa has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab is now known as Guest2614
co1umbarius has quit [Ping timeout: 480 seconds]
feaneron has quit [Remote host closed the connection]
Guest2614 has quit []
tomaw has joined #dri-devel
<worldlabels>
i have had couple of such and indeed there were more problems on the hubs and such things and interrupts and systems were not as reliable as SNB and equivalent amd ones.
<worldlabels>
i try to earn a little bit money with easier methods as playing sports as injured, and hope to do well, since performance and memory efficiency wise my systems work well, security wise i gave up, i can not handle malicious interference probably.
iive has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<dwfreed>
.
worldlabels has quit [Remote host closed the connection]
co1umbarius has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
jsa1 has joined #dri-devel
zxrom has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
feaneron has joined #dri-devel
columbarius has joined #dri-devel
dsrt^ has joined #dri-devel
warpme has quit []
fab_ has joined #dri-devel
fab_ is now known as Guest2616
fab__ has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
fab__ is now known as Guest2617
jhli has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
f_ has quit [Ping timeout: 480 seconds]
Guest2616 has quit [Ping timeout: 480 seconds]
carabel has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
kzd_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
<dj-death>
Company: broadwell, ivybridge are not fully compliant and they have their own driver
carabel has quit [Remote host closed the connection]
ishitatsuyuki has quit [Remote host closed the connection]
ishitatsuyuki has joined #dri-devel
<Company>
dj-death: but if GTK chose Vulkan over GL, we would pick a not fully compliant driver?
<bl4ckb0ne>
Company: correct, there's some missing features
<bl4ckb0ne>
iirc its compute shaders?
<Company>
I have no idea - I'm mainly wondering if we should pick GL over Vulkan on those
<dj-death>
Company: yeah
<Company>
how do we do that?
columbarius has joined #dri-devel
<Company>
like, do we need to hardcode the driver or is there some generic method we can use to select GL there?
<bl4ckb0ne>
check phdev/dev features maybe ?
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
chloekek has quit [Remote host closed the connection]
greenjustin has quit [Remote host closed the connection]
greenjustin has joined #dri-devel
<sima>
airlied, mairacanal, dolphin backmerge pushed to drm-next
<sima>
tzimmermann not around it seems, I guess I'll ping tomorrow
simon-perretta-img has quit [Ping timeout: 480 seconds]
<airlied>
sima: I thought I did -rc5, not that I mind -rc6 :-)
simon-perretta-img has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
<sima>
airlied, oops I missed that, but the defio reason is still valid since that's in -rc6 only
rasterman has quit [Quit: Gettin' stinky!]
sima has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
kzd_ has quit []
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
jhli_ has joined #dri-devel
warpme has joined #dri-devel
<Sachiel>
Company: you should be checking if the vulkan device you are opening supports the features you need. The hasvk driver won't be announcing support for anything the hw can't do, so if you need something they don't do, then fall back to GL.
<Company>
if it's good enough for that, that sounds good to me